Date: Thu, 25 Jun 1998 04:20:38 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: phk@FreeBSD.ORG Cc: current@FreeBSD.ORG Subject: Re: BDEVS going away Message-ID: <Pine.BSF.3.95.980625035724.21270A-100000@current1.whistle.com>
next in thread | raw e-mail | index | archive | help
I've been working on this for a couple of weeks now. I have quite a bit done (it's part of making cdevsw and bdevsw go away anyhow) THAT is a harder problem, but I basically have the bdevsw table removed.. (well as of tonight it's still there, but it's not really being used.) both block and char devices are going through the cdevsw table at the present time, so the bdevsw could be removed.. I've still got a bit to do but my aim is to have dev_t gone by the end of the fortnight. Using devfs allows me to have the same major numbers for the char and block devices. Some time in the next few days I will switch the mounting code over to use the char device and the block devices will be unused. Regarding removing dev_t, It will be replaced by different things depending upon what it is being used for. In cases where it's being used to identify a subdevice (minor) it will be replaced by a cookie that the driver gives the devfs on creating the device. In cases where it is being used to identify the driver (major) then there will either be a direct reference to the devsw entry in question, or in a few cases the appropriate strategy routine is already known and no added data is needed. this implied removing rawread() and rawwrite() and puting them in each driver so that the dev_t there was no longer needed (for example). In some cases it will be replaced by a vnode pointer, but I haven't got them all worked out yet. I still need to track down some users of dev_t to decide what the correct answer is for them. The trick is to convince myself that the vnode pointer in b_vp in struct buf, is always valid when needed for various device's strategy routines, so that the appropriate information can be extracted without needing to go to the devsw[]. so far this is not the case, so I still need a devsw table, in some cases. (I'm bypassing it in others) I have all the specfs vnops running directly in devfs and bypasing the devsw, except for strategy, because it doesn't get the vnode as an argument, and I'm not yet convinced that b_vp is always valid and pointing to the correct device. (I'm writing this mail on a kernel with SOME of these changes..) 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.980625035724.21270A-100000>