Subject: Re: rc.d (Was Re: run levels (was Re: The new rc.d stuff...))
To: NetBSD-current Discussion List <>
From: Greg A. Woods <>
List: current-users
Date: 04/27/2000 03:13:22
[ On Wednesday, April 26, 2000 at 12:42:23 (-0700), Greywolf wrote: ]
> Subject: Re: rc.d (Was Re: run levels (was Re: The new rc.d stuff...))
> Good.  init's config file list consists, currently of ttys.

Actually it's not that simple.  /etc/ttys is really just a list of
identifiers and the comands to run with those names given as arguments,
and a flag to note if the entry should be ignored or not, plus other
gunk not used by init (more flags and such).  Init itself doesn't really
know that those identifiers are the names of ttys with /dev/ stripped
off (well internally actually it does, though it doesn't need to and it
spends a lot of unnecessary effort adding the prefix and then stripping
it off again or ignoring it -- it doesn't even pass the prefix to

>  Every other
> config file that you might currently associate with init is really run
> by the shell that init calls, and so is not really directly associated
> with init.

Which is really just another reason why those "other things" (I presume
you're talking about /etc/rc) should be abstracted in the config file
instead of being hard-coded in.

> 2.  inittab is ugly as all f[^a-tv-z]ck already, both in name (antiquated)
> 	and in format (one line for everything that init is expected to
> 	handle).

I won't comment on the choice of names (other than to point out that
"*tab" files are "tables"), but I will note that the standard SysV
/etc/inittab format seems to be derived from the /etc/passwd format, and
I haven't heard anyone complain about that in a *long* time!  Are you
saying you don't like tables being stored in one-line records with ':'
field separators?

I wouldn't mind a block-structured syntax (ala bind8), or even a
getcap(3) format, I guess, though I don't much like the latter (it's
common enough though that one can use consistency as a valid argument
for choosing it).

>            Now that wouldn't be horribly bad, but when you have to
> 	have one line for pty that you expect to be serving, that
> 	convolves an init.conf file more than it needs.

Ah, it's /etc/ttys that needs an entry for every pty.  I suggested that
/etc/inittab could solve the hackishness of utmp/utmpx tagging by doing
something the same.  However I'd just as soon avoid having to store an
index from ttys/inittab in session accounting records (but that might
mean changing the format of utmp! ;-).

>            Init should
> 	at least delegate the tty info to a lower level than init.conf
> 	(ne inittab).

I won't disagree with that, but if I understand what you're thinking it
does mean inventing something akin to ttymon!  ;-)

> 	In short, init.conf should handle events in as efficient a manner
> 	as possible, iff it's going to exist at all.  And that's a big IFF.

I'm not sure what you might mean by that.  What "events"?  What would
make their handling "efficient"?

> 3.  ttys serves its purpose, although it could stand to advance in design,
> 	i.e., allow wildcards, assign certain perms to certain ttys,
> 	etc.  (the latter is arguably better suited to a login.conf type
> 	of arrangement).

Well it serves a number of purposes, and it crowds into the domain of
a bunch of probably more suitable configuration files, as I've already
mentioned.  I.e. it's already a big hack -- why make it worse?

If you really want /etc/ttys to do what you seem to be saying you want
it to do then you probably should revert to the original V7 format and
thus avoid being tempted into having it do things it's not intended to
do!  ;-)

TTYS(5)                                                   TTYS(5)

       ttys - terminal initialization data

       The  ttys  file  is read by the init program and specifies
       which terminal special files are to have a process created
       for  them  which will allow people to log in.  It contains
       one line per special file.

       The first character of a line is either `0'  or  `1';  the
       former causes the line to be ignored, the latter causes it
       to be effective.  The second character is used as an argu-
       ment  to  getty(8), which performs such tasks as baud-rate
       recognition, reading the login name,  and  calling  login.
       For  normal  lines, the character is `0'; other characters
       can be used, for example, with hard-wired terminals  where
       speed  recognition  is  unnecessary  or which have special
       characteristics.  (Getty will have to  be  fixed  in  such
       cases.)  The remainder of the line is the terminal's entry
       in the device directory, /dev.


       init(8), getty(8), login(1)


							Greg A. Woods

+1 416 218-0098      VE3TCP      <>      <robohack!woods>
Planix, Inc. <>; Secrets of the Weird <>