Date: Tue, 23 Jun 1998 22:37:31 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: hackers@FreeBSD.ORG Subject: Re: Heads up: block devices to disappear! Message-ID: <Pine.BSF.3.95.980623222522.19683A-100000@current1.whistle.com> In-Reply-To: <199806240432.VAA23173@kithrup.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Part of tthe reason is just SIMPLICITY. having two differnt sets of things that are a LITTLE different, all over the place is pain and I have been planning this for a LONG time. It seems that poul has decided to just go-ahead with it rather than my "softly-softly" approach. but I'm not going to complain.. If you look in DEVFS there are THREE types of devices. BDEV, CDEV and DDEV my plan has always been.... BDEV and CDEV are present devices feeding through a [bc]devsw entry. DDEV is where devices should end up.. A DDEV device would supply a set of VFSOPS which would be associeated with their vnodes directly, short circuiting the whole devsw entries. The idea was that I would migrate everything to CDEVS with SLICE supplying compatibility devices (also CDEVS) that act like BDEVS (they would only be disks or similar) The kernel would then be cleaned of dev_t and the cdevsw[] table removed, with each device's devfs node holding a direct pointer to it's devsw entry, (so that the table isn't needed). major numbers would then be totally meaningless. The way to identify a device would be to reference its vnode (with a reference count too). Once everything was CDEVS and the kernel was cleansed of dev_t then the drivers could be switched one by one to supply a set of vnops instead of devsw entries. As each driver was completed it's nodes would be switched to be DDEV rather than CDEV. When all CDEVS were gone, we are done. don't know how others (e.g. Poul-henning) think about that, but it's where I've been heading. julian On Tue, 23 Jun 1998, Sean Eric Fagan wrote: > In article <Pine.BSF.3.96.980623185331.13456F-100000.kithrup.freebsd.hackers@orkan.canonware.com> you write: > >Whoa, I'm confused now. Sean, you appear to be saying that by removing > >block devices from FreeBSD, it is no longer possible to do direct, > >un-cached (i.e. raw) accesses. > > Actually, I should have followed up myself - a big question is: will all of > the benefits of block devices still be present? If so, fine. > > If not, this should be more carefully thought out. I admit that the benefits > are fairly small -- but there are some advantages of block devices over > character devices. > > Ideally, really, with DEVFS, there are only special files, not "block special" > or "character special" files. (Better people than I have debated the merits > of having them at all, far more completely than I am willing or able to, so I > won't bother ;).) > > I am not automatically opposed to this change... but I do question its worth. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" 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.980623222522.19683A-100000>