[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 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_
> 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 ...
Main Index |
Thread Index |