Date: Sun, 27 Sep 1998 20:25:39 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: rotel@indigo.ie Cc: tlambert@primenet.com, current@FreeBSD.ORG Subject: Re: DEVFS & SLICE? Message-ID: <199809272025.NAA28155@usr05.primenet.com> In-Reply-To: <199809261328.OAA00354@indigo.ie> from "Niall Smart" at Sep 26, 98 02:28:27 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 2) To allow NFS booting from systems that don't support the 32 > > bit minor device numbers required by FreeBSD. > > Eh? FreeBSD minor numbers for some devices are more bits than DEC UNIX can store on a character device node, and subsequently export via NFS. > > 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. Major and minor numbers are an artifact of the need to be able to translate a inode from an FS into a vnode for a device. If DEVFS is used, the need for this translation goes away. Add: I. It gets rid of the need to allocate mjaor numbers for new drivers. > > 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. Until one goes to Fry's, and gets the "next great pluggable device" for their laptop. 8-). > > 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. I don't think you get notification on this. For the DEVFS directory, the directory contents are modified by the automatic insertion into the directory of the new device. Admittedly, subsequently scanning the directory, instead of just being told what device arrived, is a bit of a kludge. If you can't stand the idea, then implement a kernel thread that is associated with the driver for the device. > > 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. :) No. I'm talking about porting FreeBSD to new hardware taking less work to get a minimally functional single user mode. > > 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. The first speaks to pruned instances of "/dev", while the second speaks to the existance of device nodes anywhere *but* "/dev". If you don't have "specfs" at all, then it is *impossible* for you to "mknod" a device. Basically, mknod is obsolete. > > 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. :) See the recent question on "-hackers" about the meaning of VNON, VREG, VDIR, et. al. (yes, I will respond to the guy in a while, if no one beats me to it). > > 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? Because advisory locks are hung off the in-core inode (stupid thing to do, but that's the current implementation). Even if you fixed this, and hung them off the in-core vnode (in which case, remind me again why you need VOP_ADVLOCK() for FS's other than NFS?), you would still not have a filesystem backing the object. In other words, the struct fileops for these vnode objects that have not been fully integrated into the vnode architecture is different than the standard one, and doesn't reference an object that has a VOP_ADVLOCK() call associated with it. > > 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) Ah. Thanks for reminding me: II. To allow clone device drivers for pseudo terminals and network muxes. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199809272025.NAA28155>