Date: Mon, 21 Sep 1998 15:33:22 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: current@FreeBSD.ORG Subject: Re: DEVFS & SLICE? Message-ID: <Pine.BSF.3.95.980921144452.11176D-100000@current1.whistle.com> In-Reply-To: <199809211223.OAA23471@sos.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 21 Sep 1998, S?ren Schmidt wrote: > In reply to Andrzej Bialecki who wrote: > > > > Soren, you said you used DEVFS without SLICE on regular basis. Tell me > > then, please, what for, because I can't see what (significant) added > > functionality over standard /dev/* it offered... > > It doesn't give me anything but an emptier looking /dev with only those > devices in it that I actually have :) > Addressing a few emails in this sequence... (I missed it as I wasn't reading email over the weekend) The problems with DEVFS and booting is really quite simple. The root filesystem is mounted from the non-devfs /dev. It therefore has a vnode that is of type "UFS" and "BLK". /dev on the other hand only has nodes that are type "DEVFS" and "BLK" When you try to do a 'mount -u' to come up from single user mode, you can't, because the existing vnode doesn't match the vnode in the mount command. To get arou d this you need to either mount / from another source or mount the disks from / and THEN mount /dev, covering the old one. A further problem is that the existance of derived nodes (such as wd1s3d) depends on the primary node (wd1) having being openned, as the code that reads the disklabel is only read in during the open(). So you can't just open /dev/rwd1s2e, you have to first touch /dev/rwd1. which is a pain. SLICE was designed to solve a different problem. It only solved the two above problems as a bonus. SLICE was supposed to be a generic disk-like device handler. on the bottom layer you had a basic interface that was supported by drivers. They know how to do nothing but read and write blocks. Each layer took the simple interface below, and transformed it in some way, exporting above an interface the same as that below it. Layers were therefore stackable. In theory, layers could include arbitraily complicated functions including striping, error mapping and mirroring etc. SLICE required DEVFS because it could theoretically have to allocate completely arbitrary subdevices and no pre-caluculated bit patterns could be used to describe the nesting of partitions. DEVFS hoverver only needed SLICE to boot with a devfs root. If you are booting some other way, (e.g. NFS or MFS) then devfs should still work. Despite what was said here, I still think that something like SLICE is the right way to go as it allowed a very simple physical disk driver and broke up functionality between modules. Poul has a similar system that he showed me but I could never understand. Hopefully people will have learned and the next try will be better. I don't see why SLICE was bad, as it was a great improvement over the exising code, but I really don't have the emotional energy to fight about it now. It's always easier to delete than to write. julian 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?Pine.BSF.3.95.980921144452.11176D-100000>