Date: Wed, 23 Sep 1998 19:24:39 +0800 From: Peter Wemm <peter@netplex.com.au> To: Alfred Perlstein <bright@hotjobs.com> Cc: current@FreeBSD.ORG Subject: Re: Current is Really Broken(tm) Message-ID: <199809231124.TAA14644@spinner.netplex.com.au> In-Reply-To: Your message of "Wed, 23 Sep 1998 05:42:45 EST." <Pine.BSF.4.02A.9809230534030.8011-100000@bright.fx.genx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Alfred Perlstein wrote: > On Wed, 23 Sep 1998, Jordan K. Hubbard wrote: > > > > (if you are involved with devfs, libdisk or CAM it's important that you > > > read this imo) > > > > If you want to test 3.0-current as it relates to 3.0-RELEASE, please > > do not use DEVFS. It will not be the default in 3.0-RELEASE nor is it > > even recommended for general use at this time. It's there the same > > way that things like LFS and NFSv3 are there - available for people to > > play with but not considered robust enough to use in anything but > > purely experimental setups. There's lots of experimental code in > > FreeBSD and we already know it blows up if you push on it, that's why > > it's experimental. :-) Far better to work with the set of options > > in GENERIC (or a subset thereof) and report problems you encounter > > there. Those would be true priority issues for 3.0-RELEASE. > > > > - Jordan > > ok, but DEVFS is mmm mmm gewd. i would like to test it, it's going off my > work machine, can't loose another day rebuiling a box again, but i'll > continue to play at home with it. The main problem with DEVFS is inherent in the way that it creates and removes nodes on the fly for things like disk partitions that actually exist. The problem is that DEVFS doesn't know if /dev/wd1s1e (for example) exists until the disklabel is read. The disk label isn't read until the device is opened. To open the device, you have to read the /dev/wd1s1e node.. Catch-22. (Opening /dev/wd1s1 also causes the disklabel to be read, but that's not the name of the device in /etc/fstab) One way around it is to simply have DEVFS create all possible nodes for slices and partitions regardless of whether or not they exist. This is probably a step backwards though. Another other way is to do what the SLICE code did. It proactively probed the disks after it was safe to do so, and used that information to populate (correctly) the devfs image for the slices that were really there. The SLICE code could be brought back, but certain people have made it pretty clear that they don't like the implementation, and I'm not sure that I disagree that much with them as it is quite a heavy impact on the drivers. Under the SLICE code, drivers have to do a different IO request mechanism, arrange a callback so they can probe themselves for partitioning and geometry information later in the boot and handle removeable media etc by communicating with devfs for each diskchange etc. A hack solution is to hack fsck, mount, etc so that if you have /dev/wd0s1e intended to be mounted on /home, and /dev/wd0s1e doesn't exist, then have them first open/close /dev/wd0s1 to cause the disklabel to get read. Maybe this is OK since we've already got something like this to handle the /dev/wd0a -> /dev/wd0s1a transition problem. This might actually be an acceptable compromise to get something useful working for 3.0. And then there's the automount of /dev at boot time.. That's easy, as long as it's got a useful /dev :-). I think that's about the size of the situation.. There isn't all that much wrong with DEVFS, just that it's got some pretty hairy gotchas. There are/ were problems with it's vnode usage, but I think they've been covered. > thanks for the feedback, > Alfred Cheers, -Peter 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?199809231124.TAA14644>