Date: Wed, 20 Mar 1996 12:33:42 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: scrappy@ki.net (Marc G. Fournier) Cc: current@FreeBSD.org Subject: Re: DEVFS vs "regular /dev" Message-ID: <199603201933.MAA27577@phaeton.artisoft.com> In-Reply-To: <Pine.BSF.3.91.960319232652.255B-100000@ki.net> from "Marc G. Fournier" at Mar 19, 96 11:28:40 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Just curious, but what is the advantage (and disadvantage, if any?) > of using devfs vs "regular /dev"? My first thought would be that its > memory based instead of file system based, giving better performance, but > that's just a guess. 1) You don't need to make most things work when porting to a new platform to get a minimally running setup. 2) Devices which don't probe as being there don't get nodes; all the device files in a devfs are "live". 3) When you add a new device, you don't have to MAKEDEV. 4) You can remote boot from systems other than FreeBSD that don't understand > 16 bit minor device numbers (since otherwise you couldn't make a FreeBSD /dev on those boxes and it would be impossible). 5) When you load a kernel module, the device for it is automatically there. 6) When you unload a kernel module, the device for it automatically goes away (no more stale devices). 7) It provides a framework which allows cloning devices (like pty's) which require automatic node generation. No more configuring fixed numbers of the things into the kernel. 8) It provides a framework for "miniport drivers". This means that physical to logical device mapping can be handled on a case by case basis. This "magically" provides: A) The ability to dedicate a whole device to a single FS. B) The ability to dedicate a partition to a single FS. C) The ability to disklabel a whole device. D) The ability to disklabel partitions. E) The ability to dedicate an extended partition to a single FS. F) The ability to disklabel an extended partition. G) The ability to recognize foreign disklabels (OSF, Sun, etc.) H) The ability to recognize foreign partitioning schemes and/or artition ID's. I) The ability to interpose media perfection at any logical device by using layering. This means, for instance, that you could have a BAD144 type sector sparing that "knew" how to avoid the 1024 cylinder limit and "knew" how to work on the disklabel as well as the slices. J) The ability to interpose compression in the same way. K) The ability to interpose volume spanning the same way, including disk concatenation, striping, mirroring, and soft RAID implementations. It is a *SERIOUS* enabling technology. The sooner it is standard, the better, IMO. This assumes that the file system abstractions currently in place change as well, since the /dev FS can't be mounted *after* the / FS has been mounted as an inferior FS -- the /dev has to be there as an overlay mount (translucent FS), and that means FS changes to allow translucence and to divorce volume mappings from the need for a mount point (basically, a shadow / and /dev on which the devfs /dev is mounted and the real / is mounted over top of the shadow /). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603201933.MAA27577>