tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Rumpification (was Re: CVS commit: src/usr.sbin/envstat)



On Tue Dec 14 2010 at 21:42:25 +0000, Christos Zoulas wrote:
> In article <20101214145158.GG22653%cs.hut.fi@localhost>,
> Antti Kantee  <pooka%netbsd.org@localhost> wrote:
> >On Tue Dec 14 2010 at 15:27:38 +0100, Joerg Sonnenberger wrote:
> >> On Tue, Dec 14, 2010 at 10:22:34AM +0200, Antti Kantee wrote:
> >> > On Tue Dec 14 2010 at 14:22:50 +1100, Simon Burge wrote:
> >> > > Was this change (including the scope of it) discussed anywhere before
> >> > > you committed it?
> >> > 
> >> > Do you have an objection (apart from the one in the beginning of the
> >> > mail where you indicated you don't like the new outlook of the code)?
> >> > If not, consider it a fun experiment where you gain a ton of features
> >> > for the cost of a bucket of paint.
> >> 
> >> It is quite clear that more than one person objects to random changes to
> >> a lot of programs just for the sake of RUMP. Trying to be more
> >> productive, why can't you take the route of either libc's namespace.h OR
> >> explicit rump annotations using symbol renaming in the include files?
> >
> >As already mentioned in the thread, with that solution you cannot define
> >the granularity per-call.
> 
> Rump can because it can look at the arguments.

I used that as the very first example in this thread.  How can it possibly
tell apart two calls to socket(PF_INET, SOCK_DGRAM, 0) where one needs
to be handled by the rump kernel and another by the host?

-- 
älä karot toivorikkauttas, kyl rätei ja lumpui piisaa


Home | Main Index | Thread Index | Old Index