Re: Rump makes the kernel problematically brittle

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> Since you're just using an #ifndef that should be all that's needed,
> for this issue anyway.

Yes, the build is now up to some 80 megs of logfile.  Since the
previous failure was before 50 megs, I think this issue is fixed.

Thank you all very much!

As for the 5.2 issue, I checked out the tree just before I cut rump out
of the build and test-built it.  It failed with "warning: pointer
targets [...] differ in signedness" during the rump build of
uipc_syscalls.c, a warning which does not occur during a real kernel
build, probably because the real build passes -Wmo-pointer-sign but the
rump build does not.

I'm not sure what I think of that.  The types in question are unsigned
char * and char *, which complicates it in that character types have a
bunch of semi-magic properties.  Further complicating it is that the
actual argument CMSG_DATA(...), which IMO should be void * (well,
actually, IMO CMSG_DATA() should not exist, at least not in its current
form, but that's a separate kettle of rants).

>> Is this documented anywhere?
> You're putting documented and rump into the same thought space?

Since it affects building the world after making kernel changes not
directly related to rump, yes, I think it should be documented, even if
only in the form of "if rump gets uppity, build with -no-rump" or
whatever, instead of having to touch some 15 or 20 files (my removal
touched 252 files, but that includes entirely removing a lot of
rump-specific files).  Alternatively, and maybe preferably, a failure
in rump should not fail a build, at least not unless such failures were
specifically requested.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B