>> i think my point was a little softer than that.  i just figured that
>> the ttys file should remain a file for ttys (and the things that init
>> runs on them) and another file (whatever it be called) would be for
>> things that init ran that *didn't* get attached to ttys.
>
>If one attaches ultra-special meaning to ttys then perhaps this makes
>sense, but with inetd+{rlogind,rshd,telnetd,etc.,etc.,etc} all providing
>similar services these days the special significance is mostly gone.  On
>a modern system with TCP/IP networking the 'getty' process is just
>another daemon.  The fact that it has to be tied to a specific tty port
>is really just an implementation detail as the SysVr4 ttymon and portmon
>daemons clearly show.

yes, that's true.  whereas ttymon effectively muxes gettys over
multiple "hard-wired" ports, so does inetd mux telnetd/rshd/rlogind
over network ports, which, in turn, mux getty over multiple
connections to the same port.

i'm just somewhat attached to the concept of "a config file for each
purpose", do defining the purpose of each tty in a file seems to me to
be a separate and distinct facilty from "programs that should always
be running, and should be restarted if they die".  this is not to say
that each program should read as many config files as possible...even
though that's certainly preferable to the monolithic registry beast
that windows uses.

>> the inittab that solaris has fulfills the second purpose, and also an
>> "unnamed" third.
>
>?

the dreaded run-levels that some people are so vehemently opposed to.

>> >Have you not ever wondered why /etc/ttys has to list all the pseudo-tty
>> >entries?  That's more of an accident than a design I think.
>> 
>> i thought it was just someone being ana^Wpedantic...
>
>Mostly its because of the antiquated way that session accounting is
>done, though there's also the over-loading done by specifying attributes
>that don't necessarily belong together in there too, such as the
>"secure" flag (which should probably be set in /etc/login.conf when
>proper full compatability with the FreeBSD login.conf is added), and
>various other device-specific flags that should now be moved to
>/etc/ttyaction anyway (and ttyflags should be done away with...).

oh yeah...ttyflags uses /etc/ttys as well.  that's probably a good
reason for leaving *out* information about processes not attached to
ttys.  although they could just be "attached" to /dev/null...

>I don't know how many people still use any form of system accounting to
>justify the existance of their systems, but I think you'd agree that
>pseudo-ttys are probably a much "cheaper" resource than physical ports
>(eg. if you've got a general-purpose computing server that's accessed by
>many users by several means).  What does it mean if someone occupies an
>X11 terminal but doesn't login to your local server, especially when you
>have a limited number of such terminals shared amongst many users?

...that your accounting methods haven't kept up with technology.  it
will always be easier to build something than to build it and regulate
it.

>In general though I think "session" accounting has to be divorced from
>being tied to some entry in /etc/ttys.  That doesn't even work right in
>SysVr4 any more even though much more can be specified in /etc/inittab
>than just getty lines (though I don't think they ever tried putting all
>the pseudo-ttys in inittab and just setting them to "off").

inittab doesn't seem to have much to do with ttys...more with just
making sure something is running.  the fact that the process that died
was using a tty seems to be beside the point.

>> i was thinking of sendmail and bind, apache, our ftpd, sshd, inetd,
>> etc.  they all read multiple files over their lifetimes in order to
>> perform exactly as desired.
>
>Well, just to be pedantic, you said "config files" so I definitely would
>have to disqualify any of the common database files that are usually
>shared with multiple programs (eg. passwd, services, protocols, etc.) in
>that light.  So named, sendmail, and inetd only have one config file
>(yes for named and sendmail that file then can specify additional files
>which might be used).  Apache used to have three config files but the
>trend is towards one, and it doesn't come bundled with NetBSD anyway.
>The NetBSD ftpd really only has one configuration file, though if you
>wanted to be really picky I guess it's one of the very few that might
>qualify as a daemon that has multiple "config" files (esp. since you can
>only specify the directory where config files live and you can't really
>change the name of any of the other "database" files it uses either from
>the command-line or from the primary configuration file.  Sshd is
>another odd-ball, but then it doesn't come bundled either.

yep.  it's all a matter of semantics.  some people say the daemon has
one config file, some people say it has more.  some people say run
levels are "evil!  pure and simple from the eighth dimension!" and
some people say they're useful and maybe even ignorable.

>Generalisations are of course dangerous but generally speaking I don't
>think it makes much sense to add one or more new config files to any
>existing daemon, especially 'init'.

that's fair.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."