Date: Wed, 15 Dec 1999 13:37:20 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Warner Losh <imp@village.org>, current@FreeBSD.ORG Subject: Re: MAKEDEV (Re: Speaking of moving files (Re: make world broken building fortunes ) ) Message-ID: <Pine.BSF.4.05.9912151321260.22090-100000@semuta.feral.com> In-Reply-To: <12359.945292429@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9912151321260.22090-100000>