I'm writing a Solaris systems programming book that will be published
by Addison Wesley next year some time. Although I have a good idea of
the topics I want to cover, I thought I'd take this opportunity to ask
the potential buyers of my book what they'd like to see in it.
Althought it will be Solaris-centric, there will be lots of material
for other Unices, given that most of them adhere to the same standards
(POSIX, etc.). It's aimed at intermediate to advanced programmers.
It will sort of be like Rich Stevens' highly regarded book, Advanced
Programming in the UNIX Environment, but will be up to date, and have
a Solaris bias. The book will only cover user-land stuff: kernel
programming and device drivers will be left for another project. I
plan to cover all releases of Solaris from 2.5[.1] to 9.
Please CC me on any replies (I do read these newsgroups frequently,
but I'd like to keep a local copy of replies).
Many thanks in advance,
Rite Online Inc.
> It will sort of be like Rich Stevens' highly regarded book, Advanced
> Programming in the UNIX Environment, but will be up to date, and have
> a Solaris bias. The book will only cover user-land stuff: kernel
> programming and device drivers will be left for another project. I
> plan to cover all releases of Solaris from 2.5[.1] to 9.
PAM (maybe, don't know if it fits the scope of your book)
Perhaps detailed coverage on TLI/TPI (or whatever they call it
nowadays) because it's done so much in Solaris
32- vs 64-bit programming
tty programming (see my article
http://www.prairienet.org/~rmasoner/serial.html for ideas)
Must Have: Security issues (e.g. avoiding buffer overflows, sanity
check all input)
. . .
Solaris vs Posix threads
Something about development process, project organisation, file/directory
layout, cvs etc.
Keeping one eye on efficiency eg locality of references, madvise() etc.
How shared libraries work (many people seem confused about what happens with
eg function pointers or static variables)
: Solaris vs Posix threads
/proc and /usr/proc/bin commands [man proc; man -s 4 proc]
libaio (asynchronous I/O library) [man libaio]
POSIX Realtime Extensions library [man libposix4]
Ie. termios and including understanding of how SAF and SAC
work now (ie. no more getty)! I am having a very difficult
time porting (I have it compiling and running but it doesn't
stop/restart worth a damn!) the freebie wx200d for the
Oregon Scientific or Radio Shack WX200 weather
sensor kit from Linux to Solaris 7/8.
When you kill off the daemon
something blocks the serial device access on
the next attempt to start it up again. 'fuser /dev/cua/a'
sees nothing but all attempts to open(/dev/cua/a) again
fail with "wx200d: bind: Address already in use"
I suspect it is because some STREAMS module is hosed
but I cannot find enough information about the whole
SAF/SAC architecture, tools, &c to figure out what
the heck is going down. Like is there something you
have to do to reset the serial device when your app
gets killed (something akin to Sockets "shutdown()")
that you need to hang in a sig handler for all terminating
signals or what? Is there a user-land command-line app to
run to flush/close/reset a "hung" serial port w/o rebooting?
Rebooting in fact does not even clear this port once I
get it in a hosed state so something strange is happening.
Also, it is not clear whether you need to do a
# pmadm -r -p zsmon -s ttya
if you are going to setup the serial port with termios
C code and "manage" (if that is the right terminology) the
danged port yourself because Solaris by default hangs
zsmon on both /dev/term/a and /dev/term/b initialized
for Sun graphics terminals (you even have to reconfigure
them for yer basic vt100 terminal!). Do I have to kill
the port monitor if I am using /dev/cua/a to read the
wx200d? In the old days if you were going to "manage"
a serial port yourself you just commented out the getty
startup line in /etc/inittab, so is "removing" the zsmon
port monitor with pmadm as I show above equivalent to that?
If I wanna just read (open with O_RDONLY) do I use
/dev/term/a|b or /dev/cua/a|b? Lottsa questions like
these need to be cleared up and dealt with IMHO.
Please look into this for us aging UNIX hacks who last
dealt with userland serial devices back when there were
just getty's, inittab, and uucp and things made sense (SVR3.2.2)!!
Until then, if anyone knows of a good user-land Solaris asynch
programmer's manual, guide, tutorial, example code, whatever
please point me to it [please Cc replies to: ccro...@halcyon.com
or crow...@home.com]. TIA.
regards, cal <ccro...@halcyon.com>
I'm really not sure it's even worth bothing to get to know
SAF/SAC nowdays. If you do know it, by all means use it
(the management is covered on the Advance Admin course in
quite some detail), but otherwise, just disable it and
either run ttymon in getty look-a-like mode (as is done
on the console), mgetty (freeware) if you need its extra
facilities, or nothing if you just want a dedicated port.
SAF was a feature which was designed to solve a problem,
which by the time SVR4 came out, had been solved by better
means. Namely, how do you connect 1000 or more VDU terminals
to a unix system without running 1000 gettys? Well, by
1989/1990, the answer had become 'Terminal Concentrators'.
It's very rare nowdays to find a unix system with so many
directly connected serial ports that the number of gettys
running would be a problem.
>When you kill off the daemon
>something blocks the serial device access on
>the next attempt to start it up again. 'fuser /dev/cua/a'
>sees nothing but all attempts to open(/dev/cua/a) again
>fail with "wx200d: bind: Address already in use"
This sounds more like a bind to a TCP port is failing,
because the daemon doesn't use SO_REUSEADDR. An open
can't fail with "Address already in use". Check with truss.
Consultant Software Engineer
Not tcpdump (or ethereal). They have *nothing* to do with Unix systems
Paul Floyd http://paulf.free.fr (for what it's worth)
Mail as URL, replace 1st . with @
If more is better, are double standards better than single ones?
> Not tcpdump (or ethereal). They have *nothing* to do with Unix systems
I agree (if they were, I'd write about snoop; after all, it's not a Linux book!)
It's times like this that I really miss Richard Stevens.
This post siimply contains some of my personal opinions.
> A new Solaris programming book, eh?
> It's times like this that I really miss Richard Stevens.
I miss him too (I was one of the reviewers of UNP 2e, V2).
My book will hopefully be as good as Rich's. I use the
same tools (vi, groff, tbl, gpic), and my book has the same
look and style as Rich's. Imagine a new edition of APUE,
which is up to date, and has a (fairly significant) Solaris
bias: that's how I envision my book.
A lofty goal, I freely admit. Time will tell if I'm up to
[Wow, humility from me: now THERE'S a first!]
Rich> Imagine a new edition of APUE, which
Rich> is up to date, and has a (fairly significant) Solaris bias:
Rich> that's how I envision my book.
One of the great things about APUE is that it does not have an OS
bias. Instead, it explains the differences between Unix versions and
how to write portable code, even for cases where OSs differ. This is
much more useful than any OS-specific book.
> One of the great things about APUE is that it does not have an OS
> bias. Instead, it explains the differences between Unix versions and
> how to write portable code, even for cases where OSs differ. This is
> much more useful than any OS-specific book.
I see where you're coming from, and that's something I'm already taking
into account. My book will highlight stuff that's not portable.
Most of the book will be applicable to most Unices, as they tend to adhere
to the same standards (I'm think POSIX, UNIX 98, etc.). In other words,
my book will not only cover the generic stuff that's applicable to just
about any UNIX, but will also cover Solaris specific stuff, like doors,
PAM, the KVM interfaces, etc.