Step 1.5 needs review
Julian Elischer
julian at elischer.org
Wed Sep 3 16:10:34 UTC 2008
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
More information about the freebsd-virtualization
mailing list