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

[Matt Thomas <matt%3am-software.com@localhost>]

On Dec 14, 2010, at 12:22 AM, Antti Kantee wrote:

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

But it's an extremely ugly one.  If rump causes us to have to change
our sources, then I think it's failed.  If it isn't transparent, then
IMO it's failed.

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

We have now changes from having POSIX compliant sources to something
that isn't.  In your example it's a high VOC paint that causes cancer
in long term exposure.

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

You could just make it fail ...