New Solaris programming book - soliciting subject ideas

6 views
Skip to first unread message

Rich Teer

unread,
May 3, 2001, 12:00:00 PM5/3/01
to
Hi all,

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,

--
Rich Teer

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-online.net

Richard Masoner

unread,
May 3, 2001, 12:53:46 PM5/3/01
to Rich Teer
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


. . .

John L

unread,
May 3, 2001, 2:16:37 PM5/3/01
to
"Richard Masoner" <richard...@sun.com> wrote in message
news:3AF18D1A...@sun.com...

Doors
Solaris vs Posix threads
LWPs
mmap()

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)

John.


br...@nospam.panix.com

unread,
May 3, 2001, 3:18:38 PM5/3/01
to
In comp.unix.solaris John L <j...@interx.com> wrote:
: "Richard Masoner" <richard...@sun.com> wrote in message

: news:3AF18D1A...@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()

/proc and /usr/proc/bin commands [man proc; man -s 4 proc]
truss command
libaio (asynchronous I/O library) [man libaio]
POSIX Realtime Extensions library [man libposix4]

--
For the spam-bots: tos...@aol.com ab...@aol.com ab...@yahoo.com
ab...@hotmail.com ab...@msn.com ab...@sprint.com ab...@earthlink.com

CROWLEY CAL

unread,
May 4, 2001, 10:28:00 PM5/4/01
to
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: ccro...@halcyon.com
or crow...@home.com]. TIA.

regards, cal <ccro...@halcyon.com>

Andrew Gabriel

unread,
May 5, 2001, 7:40:59 AM5/5/01
to
In article <3AF364F2...@home.com>,

CROWLEY CAL <crow...@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.

--
Andrew Gabriel
Consultant Software Engineer

David Peter

unread,
May 8, 2001, 10:10:00 AM5/8/01
to
DLPI/libpcap/tcpdump/ethereal

Paul Floyd

unread,
May 9, 2001, 4:47:50 PM5/9/01
to
On Tue, 08 May 2001 15:10:00 +0100, David Peter
<dave....@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?

Rich Teer

unread,
May 9, 2001, 5:08:28 PM5/9/01
to
On Wed, 9 May 2001, Paul Floyd wrote:

> Not tcpdump (or ethereal). They have *nothing* to do with Unix systems
> programming.

I agree (if they were, I'd write about snoop; after all, it's not a Linux book!)

Richard

unread,
May 9, 2001, 7:02:59 PM5/9/01
to
A new Solaris programming book, eh?

It's times like this that I really miss Richard Stevens.

--
This post siimply contains some of my personal opinions.
ObURL: http://home.earthlink.net/~huddler

Rich Teer

unread,
May 9, 2001, 10:34:37 PM5/9/01
to
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...

[Wow, humility from me: now THERE'S a first!]

Bas de Bakker

unread,
May 11, 2001, 5:10:00 AM5/11/01
to
>>>>> "Rich" == Rich Teer <ri...@rite-group.com> writes:

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.

Bas.

Rich Teer

unread,
May 11, 2001, 6:56:22 PM5/11/01
to
On 11 May 2001, Bas de Bakker wrote:

> 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.

Reply all
Reply to author
Forward
0 new messages