Date: Fri, 19 Oct 2007 00:44:58 +0200 From: Marko Zec <zec@icir.org> To: Julian Elischer <julian@elischer.org> Cc: Perforce Change Reviews <perforce@freebsd.org> Subject: Re: PERFORCE change 127639 for review Message-ID: <200710190044.59319.zec@icir.org> In-Reply-To: <4716BB87.1040004@elischer.org> References: <200710172258.l9HMw33S061205@repoman.freebsd.org> <4716BB87.1040004@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 18 October 2007 03:48:55 Julian Elischer wrote: ... > > + INIT_VPROCG(TD_TO_VPROCG(curthread)); > > > > + INIT_VNET_NET(TD_TO_VNET(curthread)); > > might not they be further macroised as: > > #define VNET_FROM_TD(_td) INIT_VNET_NET(TD_TO_VNET(_td)) > #define VPROCG_FROM_TD(_td) INIT_VPROCG(TD_TO_VPROCG(_td)) In general I think we should avoid as much as possible to resolve vnet context from curthread whenever possible, i.e. where we have a socket or ifnet or inpcb at hand this should be our primary source of vnet context instead. Some people have already expressed concerns about the extensiveness of curthread macro use in vimage branch and it may happen that at some point we might wish to abandon such an implicit method of vnet context passing along the function call graph alltogether. Introducing a macro that resolves vnet from thread directly might encourage programmers to take that path as granted, i.e. let one think that this is something OK to do, which it is probably not. Hence, I wouldn't rush with introducing such a macro (or a whole family of macros)... Cheers, Marko > etc. > > not a requirement.. just a comment.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200710190044.59319.zec>