Date: Sat, 07 Jun 2008 09:51:28 -0700 From: Julian Elischer <julian@elischer.org> To: James Gritton <jamie@gritton.org> Cc: freebsd-virtualization@freebsd.org Subject: Re: R_xxx counterparts to the V_xxx macros Message-ID: <484ABC90.9070301@elischer.org> In-Reply-To: <484A23EE.8080308@gritton.org> References: <484A23EE.8080308@gritton.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to > "freebsd-virtualization-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?484ABC90.9070301>