Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 19 Jan 2003 00:04:15 +0100
From:      phk@freebsd.org
To:        arch@freebsd.org
Cc:        Sam Leffler <sam@errno.com>
Subject:   Re: HEADSUP: DEVFS and GEOM mandatorification timeline. 
Message-ID:  <36671.1042931055@critter.freebsd.dk>
In-Reply-To: Your message of "Sat, 18 Jan 2003 14:27:13 PST." <20030118222713.GI70151@dragon.nuxi.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <20030118222713.GI70151@dragon.nuxi.com>, "David O'Brien" writes:

>Let me preface this by saying I highly value and respect your opinions.
>The problem is making only the minimal change before the RELENG_5 branch
>point will really make MFC'ing harder.  We had a disaster with 4-CURRENT
>and RELENG_3 in which we could not MFC critical kernel fixes.  The
>Project (as we operate) learned a hard lesson, and I would just like to
>remind people of that.

I agree on this.  We need to decide which ABI/API's we want to support
in that branch before we branch it.

>I would like to see a patch from PHK that implements his preference.
>Some of us could run that to gain some insight into this issue.

Well, you probably are runing that already:  As long as you don't have
the NODEVFS and NO_GEOM options in your kernel, you are running the
code base which I want to see in all our releases after 5.0-RELEASE
irrespective of when the RELENG_5 branchpoint is.

The removal of NODEVFS and NO_GEOM options means that about 700-1000
lines can be mechanically unifdef(1)'ed, but it is not to me important
to do this before the next release, because this can be painlessly
MFC'ed later.

Subsequently, after then RELENG_5 branch, the non-trivial fallout
of removing NODEVFS and NO_GEOM can be worked on, there are some
simplifications in the vnode layer and some devices clone routines
etc, but these needs shaken out in -current before the will be
MFC'ed.

-- 
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?36671.1042931055>