warning of pending commit attempt.

Julian Elischer julian at elischer.org
Tue Feb 26 22:35:05 UTC 2008


Peter Jeremy wrote:
> Overall, vimage sounds very useful.  Are there changes to public
> kernel interfaces?  (ie could it potentially be MFCd)

potentially it could..

in the "compiled out" mode (i.e. you decide to not compile vimage in 
your kernel) the public kernel interfaces are unchanged. At least
that is the aim.

> 
> On Mon, Feb 25, 2008 at 09:31:40PM -0800, Julian Elischer wrote:
>>>> The current version referred to in the code is implemented in
>>>> a manner that allows it to be COMPILED OUT.
> 
> Since even things like INET and INET6 are "compiled in" rather than
> "compiled out" on request, why is vimage defaulting to "compiled in"
> by default?


eh?
After importing, it would be compiled out by default.

as in, you'd only get it if you ask for it..
> 
>> No. There are some minor reorganisations of where some variables are, and 
>> some minor changes but they are pretty easy to  confirm as being 
>> "functionally equivalent".  Macros are used to do a lot but there are some 
>> places where it was not possible to hide it behind a macro, so small 
>> re-orgs were required.. they really are small in comparison to
>> the whole work though, and as I said. quite "provable".
> 
> How much will impact on the ease with which networking stack changes
> can be MFCd back to 7.x?

minimal change.. In the worst case we could define the vimage
macros in 7.0 and make then do the right thing. (if you needed
no diffs at all).


> 
>> I say the next few weeks because we need it to happen NOW and
>> not "just before 8.0"
> 
> Agreed but I can understand Brook's reluctance to have yet another
> roto-tilling of the network stack whilst there still appear to be
> a few issues remaining from the last roto-tilling.  IMHO, it would
> be reasonable to get input from re@ as to whether they would like
> the stack left alone for a while to simplify the resolution of any
> issues that may crop up once 7.0 is released.

I agree that we need to wait for 7.0 but 7 and 8 are already 
diverging, and the whole point of the 7 branch is to isolate 7 from 
-current.


> 



More information about the freebsd-current mailing list