Date: Wed, 15 Jan 2003 13:37:33 +0100 From: Poul-Henning Kamp <phk@freebsd.org> To: arch@freebsd.org Subject: HEADSUP: DEVFS and GEOM mandatorification timeline. Message-ID: <14715.1042634253@critter.freebsd.dk>
next in thread | raw e-mail | index | archive | help
I think we are now at a cross-road where it makes sense to nail down the path for making DEVFS and GEOM non-optional components. The three steps in this process will be: Remove option "NODEVFS" in sys/conf and sys/*/conf. Remove option "NO_GEOM" in sys/conf and sys/*/conf. Remove MAKEDEV and all references to it from the tree. There are _no_ sweeps over all drivers to change APIs etc. I plan to do this when 5.0-RELEASE has been out there for some weeks and I am convinced that there are no show-stopping bugs, we are probably talking march 1st or thereabout. This is simply a matter drawing a line, after which DEVFS and GEOM are standard parts and driver writers no longer will have to deal with having two different "modes" for FreeBSD device managment. Subsequently, I will start to harvest the benefits that has been sown with DEVFS and GEOM, and remove the unneeded "old-style" code, but this will be without any user-impact and neutral relative to the 5-stable branch. By removing these options before 5-stable, we make life easier for the device driver writers for the whole 5-stable cycle (2-3 years) because they will not have to deal with dual-mode APIs in their drivers. We are already at a point where very very few device drivers are tested with NODEVFS, we have a couple of platforms which only have support for their disk layouts in GEOM, we have I/O subsystems which do not work without DEVFS at all: Turning DEVFS or GEOM off at this point in time is not very viable. Keeping the negative options around for another entire relase-cycle will not gain us anything: People already do not test with those options and the code to implement them will just rot away. If we do not do this before the 5-stable branch, we will put us in a situation where a lot of the changes we will be doing to central areas like the buf/VM system will not be possible to MFC from 6-current to 5-stable because of the requirement that non-devfs and non-geom operations be maintained working in that branch. This in turns means that fixing bugs in these areas in 5-stable will be up-hill work for the developers involved and we will likely see a reduced branch lifetime like we saw it on 3.x. Finally, I would like to request that anybody who intend to argue that these options should survive for 5-stable try to run their system without DEVFS and GEOM for a week, just to make sure they know what they are talking about. Poul-Henning PS: I know that Bruce is against GEOM and DEVFS on principal grounds. All the central developers I have talked to agree that this is the direction we are going. Unless I am Terrybly mistaken, only the speed of adoption is up for discussion at this point, the direction is not. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14715.1042634253>