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).
Rich Teer wrote: > 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.
pthreads
PAM (maybe, don't know if it fits the scope of your book)
IPC
Perhaps detailed coverage on TLI/TPI (or whatever they call it nowadays) because it's done so much in Solaris
> > 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.
> pthreads
> PAM (maybe, don't know if it fits the scope of your book)
> IPC
> Perhaps detailed coverage on TLI/TPI (or whatever they call it > nowadays) because it's done so much in Solaris
In comp.unix.solaris John L <j...@interx.com> wrote: : "Richard Masoner" <richard.maso...@sun.com> wrote in message : news:3AF18D1A.1B932458@sun.com...
:> Rich Teer wrote:
:> :> > 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. :> :> pthreads :> :> PAM (maybe, don't know if it fits the scope of your book) :> :> IPC :> :> 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) :> :> Performance issues :>
: Doors : Solaris vs Posix threads : LWPs : mmap()
User-land Asynchronous Comms Programming on Solaris 2.x
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: ccrow...@halcyon.com or crowl...@home.com]. TIA.
> 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).
In article <3AF364F2.29741...@home.com>, CROWLEY CAL <crowl...@home.com> writes:
>User-land Asynchronous Comms Programming on Solaris 2.x
>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.
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.
> > > 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.
> > pthreads
> > PAM (maybe, don't know if it fits the scope of your book)
> > IPC
> > Perhaps detailed coverage on TLI/TPI (or whatever they call it > > nowadays) because it's done so much in Solaris
On Tue, 08 May 2001 15:10:00 +0100, David Peter <dave.pe...@eu.citrix.com> wrote:
>DLPI/libpcap/tcpdump/ethereal
Not tcpdump (or ethereal). They have *nothing* to do with Unix systems programming.
A bientot Paul -- 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?
On Wed, 9 May 2001, Richard wrote: > 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 the task...