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 14:22:50 +1100, Simon Burge wrote:
> > 
> >     src/usr.sbin/envstat: Makefile envstat.c
> > Added Files:
> > 
> >     src/usr.sbin/envstat: envstat_hostops.c envstat_rumpops.c prog_ops.h
> > 
> > Log Message:
> > 
> > RUMP_ACTION -> RUMPPRG
> 
> This doesn't appear to be a very scalable or usable solution.  Lots
> of nearly but not quite the same *hostops.c and *rumpops.c files are
> appearing over the source tree.  Random syscalls now gain a prog_ prefix
> which adds no readability to the code, for example:
> 
> -       (void)close(sysmonfd);
> +       (void)prog_close(sysmonfd);
> 
> So now someone adding code to any RUMPPRG'd program now needs to
> effectively check each syscall individually to see if it needs a prog_
> wrapper?

Yes.  It's not really a very difficult rule.  I can understand the "I
forgot" vector, though.  I seriously doubt it'll be a problem, but just
in case, see below.

> What is the effect of a direct call to the original system
> call, eg close() above, in these situations?

Undefined behaviour will happen if a program does undefined things.
In that particular case a file descriptor from the host kernel will
be closed (*).  Note that this happens only rump clients, so even if
someone makes the mistake, the host kernel version of the utility will
work perfectly fine.

> How will these changes be
> audited/verified so that mistakes won't occur?

How are any mistakes verified against?  /usr/tests with a healthy pinch
of source-changes

> 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.

*) i once had some code which offsetted rump kernel fd's by N (say,
1024) from the host kernel fd's.  it worked, but dup2 was a gray area,
so I gave up on it.

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


Home | Main Index | Thread Index | Old Index