> But lets say you add a pccard on which you want a getty, so devd will
> have to tell init to run a getty on that port wouldn't it ?
Of course- but this lays out very clearly where breakage
could occur and leads to be better flexibility. Let's assume this is devd
and leave to the side whether devfs would or would not be better.
a. insert card
b. card recognized (8 new tty ports)
c. devd awakened
d. (re)makes /dev nodes
e. updates /etc/ttys [ this is a debatable step ]
f. notifies init (kill(1,1))
g. init awakens
h. rescans /etc/ttys
i. spawns new gettys, kills dead ones (the old rmut hat dance)
Groups a-b, c-f, g-i, are separable steps with pretty clear audit trail
stops as to how things could go.
Let's take another more complicated example:
a. SAN Fabric SCN (change notify) is received by Qlogic FC-AL driver.
b. Fabric Nameserver rescanned- 32 new disks arrived, 8 disks left.
c. ASYNC notification upcall to CAM is made [ this is as yet an
undesigned area, but assume that does like what a camcontrol
rescan now does (or is supposed to)- new disks get assigned new
instance numbers, dead disks are either safely removed of pack
invalidation occurs if they were still open ]
d. devd awakened
e. (re)makes /dev nodes
f. [ VARIABLE HOOK HERE- POLICY LEFT OPEN ]
g1. vinum awakened, yatta yatta yatta
g2. VxVM (Veritas Volume Manager) awakened, yatta yatta yatta
g3. Specified perl script activated, (auto disklabel, newfs, mount)
...
Again, Groups a-b and d-f are separable steps with pretty clear audit
trail stops. It's not quite clear what step G should be, or whether it
should be left to 3rd party hooks, but it's pretty clear to me that
putting volume management in init makes no sense whatsoever. For things
like what init itself manages (tty lines), sure it does. Otherwise, no.
-matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
