R_xxx counterparts to the V_xxx macros

Julian Elischer julian at elischer.org
Sat Jun 7 16:51:29 UTC 2008

James Gritton wrote:
> There are places where a variable has been replaced with a V_ macro, 
> only to be set explicitly to the "virtual" data from thread0 or the 
> like.  For example, I know of a few places where V_hostname is set like 
> this.
> It would make sense to have an R_hostname as well, an easy shortcut the 
> the real hostname instead of the virtual one.  You'd need either a 
> static "vprocg0" structure, or a pointer somewhere to the main entry 
> (could be thread0 again, I suppose).  Likewise with the other structures 
> where other globals may live.
> Perhaps many (most?) variables will only ever be referred to in their 
> fully virtual state.  But for those where the intention is to use the 
> machine's "true" parameter, it would be more clear if that was made 
> explicit in the macro.

It's an interesting idea, however what is the "real" hostname?

what makes one vimage the 'real' one?

theoretically you can get it via:

INIT_VNET_INET(thread0.td_vnet)  as you noted..

a macro that does that could be done I guess..
#define R_hostname ...

I wouldn't do it for all variables however..

let us keep it in mind and when we have vimage in we'll see how useful 
it is.

> - Jamie
> _______________________________________________
> freebsd-virtualization at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
> To unsubscribe, send any mail to 
> "freebsd-virtualization-unsubscribe at freebsd.org"

More information about the freebsd-virtualization mailing list