From owner-freebsd-arch Wed Jan 15 4:38: 0 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F004A37B405 for ; Wed, 15 Jan 2003 04:37:57 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id B37B543F81 for ; Wed, 15 Jan 2003 04:37:55 -0800 (PST) (envelope-from phk@freebsd.org) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id h0FCbX9O014716 for ; Wed, 15 Jan 2003 13:37:33 +0100 (CET) (envelope-from phk@freebsd.org) To: arch@freebsd.org Subject: HEADSUP: DEVFS and GEOM mandatorification timeline. From: Poul-Henning Kamp Date: Wed, 15 Jan 2003 13:37:33 +0100 Message-ID: <14715.1042634253@critter.freebsd.dk> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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