Date: Wed, 19 Apr 1995 13:02:53 -0500 (CDT) From: Mike Pritchard <pritc003@maroon.tc.umn.edu> To: davidg@Root.COM Cc: bde@zeta.org.au, julian@ref.tfs.com, hackers@FreeBSD.org Subject: Re: [DEVFS] your opinions sought! Message-ID: <199504191802.NAA05091@mpp.com> In-Reply-To: <199504191017.DAA00268@corbin.Root.COM> from "David Greenman" at Apr 19, 95 03:17:04 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >>I personally have always prefered the flat scheme of /dev (with possible > >>exceptions for /dev/fd/*). This is a religious issue, I have spoken my > >>religion. > > > >I like it fairly flat. There certainly shouldn't be subdirectories for > >pieces of one device. > > I agree with Bruce. I would have agreed with Rod, but the simple fact is > that our /dev directory is getting very large and bloated, and this will only > get worse. Perhaps /dev/disks/* and /dev/ttys/*, etc, might be a way to > organize things (in other words, by device class). I prefer to not minimize > the number of levels as much as possible, while still providing some > organization. > > -DG I've used systems in the past that were setup like: /dev/rdsk/*, /dev/dsk/*, /dev/tty/*, /dev/pty/*, etc... Only a handfull of oddball devices were left in /dev. E.g /dev/null, console, mem, kmem, etc... My only problem with it was if I forgot which type of machine I was on and was looking for a /dev/xxx file instead of a /dev/rdsk/xxx file. >> it also means that disk slices can be shown only when they >> actually exist on the disk.. > > Well, it's perfectly feasible (and adds less kernel bloat) to query > the kernel at boot time for attached devices and build up the /dev > directory based on the information. This IMHO is a better solution > than the devfs. > > Simon I've also seen some system that was able to generate /dev by reading information out of the kernel at run time. -- Mike Pritchard pritc003@maroon.tc.umn.edu "Go that way. Really fast. If something gets in your way, turn"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504191802.NAA05091>