Date: Sat, 26 Sep 1998 14:28:27 +0000 From: Niall Smart <rotel@indigo.ie> To: Terry Lambert <tlambert@primenet.com> Cc: current@FreeBSD.ORG Subject: Re: DEVFS & SLICE? Message-ID: <199809261328.OAA00354@indigo.ie> In-Reply-To: <199809240047.RAA15840@usr07.primenet.com>; Terry Lambert <tlambert@primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 24, 12:47am, Terry Lambert wrote: } Subject: Re: DEVFS & SLICE? > > > > I tried DEVFS for the first time today and thats about what I see > > too. What exactly is its purpose -- to replace a shell script? Am > > I missing something or is this a solution looking for a problem? > > 1) To never have the possibility of the /dev directory having > out-of-date contents. Fair enough. This has never been a killer issue AFAIR though its still useful. > 2) To allow NFS booting from systems that don't support the 32 > bit minor device numbers required by FreeBSD. Eh? > 3) To move the maintenance of the MAKEDEV into the same source > file as the device being maintained, such that coherency is > automatic. MAKEDEV should probably be built from a file which describes kernel devices, maintanence of this would be so easy as to be a non-issue and would have the side effect of a database of device major and minor numbers which the DEVFS approach doesn't seem to afford. > 4) To allow for dynamic creation of devices as a result of > hot insertion or hot swap. I don't think that this is a problem with MAKEDEV, one usually has only a small number of hot pluggable devices. > 5) To allow for daemon-select/poll of the /dev directory to > allow for scanning to actually *do* something when a > device "arrives" (like mount an FS on a Flash, bring a > network link up when a PCMCIA net card is inserted, etc.). Are you talking about opening /dev and then selecting on the fd? I don't believe this requires DEVFS - Perhaps an even better approach would be to select on /dev/pcmcia for example, from which a structure describing the new device could be read from. > 6) To reduce the number of kernel drivers that have to be > working to get FreeBSD minimally functional on a new > piece of hardware. I don't understand what you are saying here, when you say drivers are you talking about device drivers? It can be a pain when a boot disk doesn't include a device file you need which is why I always make sure MAKEDEV is on mine. :) > 7) To allow the creation of sub-instances of /dev in chroot > environments, but to omit "dangerous" or "undesirable" > devices. > > 8) To prevent the use of ad-hoc created devices (via mknod) > as gateways for security exploits. These two issues seem more or less the same, using DEVFS simply moves the checking from mknod code to DEVFS code. Any general framework implemented in DEVFS for controlling device visibility in chroot environments could just as easily be provided for mknod. > 9) To get rid of "specfs" and the promiscuous knowledge of > "specfs" in other areas of the kernel. > > 10) To aid in the murder of "struct fileops", such that vnodes > actually point to VFS devices. If you say so. :) > 11) To allow advisory locking to be applied to device files, > just like it applies to ordinary files. Why can't this happen without DEVFS? > 12) Because it's cool. Heh, I will add another reason: 14) To allow special file addition and removal when the underlying resource such as pseudo terminals, packet filters etc can dynamically resize. (Of course this is not possible right now.) (13 is an unlucky number) Regards, Niall -- Niall Smart, rotel@indigo.ie. Amaze your friends and annoy your enemies: echo '#define if(x) if (!(x))' >> /usr/include/stdio.h 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?199809261328.OAA00354>