Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 03 Sep 2008 09:10:36 -0700
From:      Julian Elischer <julian@elischer.org>
To:        Robert Watson <rwatson@FreeBSD.org>
Cc:        "Bjoern A. Zeeb" <bz@freebsd.org>, FreeBSD virtualization mailing list <freebsd-virtualization@freebsd.org>
Subject:   Re: Step 1.5 needs review
Message-ID:  <48BEB6FC.1070605@elischer.org>
In-Reply-To: <alpine.BSF.1.10.0809031101060.74719@fledge.watson.org>
References:  <20080828185639.P66593@maildrop.int.zabbadoz.net> <20080902000516.GA48622@lor.one-eyed-alien.net> <48BCED8E.5030109@elischer.org> <20080902141245.GB48622@lor.one-eyed-alien.net> <alpine.BSF.1.10.0809031101060.74719@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote:
> 
> On Tue, 2 Sep 2008, Brooks Davis wrote:
> 
>>> I suggest that we eventually replace:
>>>
>>>     VNET_ITERLOOP_BEGIN
>>>     stuff
>>>     VNET_ITERLOOP_END
>>>
>>>
>>> with (eventually)
>>>
>>>     FOREACH_VNET(vnet) {
>>>         stuff
>>>     }
>>>
>>> but that would require that the entire contents of "stuff"
>>> would appear in the diff.
>>
>> Thinking about it more, at a minimum, I think we should do:
>>     VNET_ITERLOOP_BEGIN
>>         stuff
>>     VNET_ITERLOOP_END
> 
> FWIW, I think we should make the change to FOREACH_VNET(vnet() { } 
> sooner rather than later -- especially if there's no semantic change 
> going on currently, now would be the time to do the indentation change.
> 
>>> I'm not sure I want to actually include the contents directly into 
>>> if.h or any other place.. I think keeping a separate vnet.h and 
>>> vinet.h seems ok to me.
>>
>> The #ifdef _KERNEL is a strong hint that it belongs in if_var.h if 
>> it's going to be included in another header (IMO, the vnet/vinet.h 
>> files aren't a good idea in the long term).
> 
> My views on this one are a bit mixed -- if the goal is to get, in the 
> medium term, to a case where we do explicit dereferencing rather than 
> macros, we may find we do need more globally visible types than we had 
> before, which may require us to have new globally included headers.  
> That said, in.h might be as good a place as any for global inet stuff, 
> and as long as we have piles of pointers rather than nested structs, the 
> type issue shouldn't get too bad.

thats' where vinet is, but what about vnet.. (non inet stuff)
I have it off if.h right now..

> 
> Robert N M Watson
> Computer Laboratory
> University of Cambridge




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48BEB6FC.1070605>