[ On Wednesday, April 26, 2000 at 13:44:53 (-0400), Andrew Brown wrote: ]
> Subject: Re: rc.d (Was Re: run levels (was Re: The new rc.d stuff...))
>
> 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.
 
> the inittab that solaris has fulfills the second purpose, and also an
> "unnamed" third.

?

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

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?

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

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

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

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>