On Wed Dec 12 2007 at 21:31:01 +0200, Elad Efrat wrote:
> Antti Kantee wrote:
> 
> > ic.  I'd like to fix this another way and get rid of LFS_KERNEL_RFW
> > completely since seems it's runtime-controlled.  Or nuke the code if it
> > doesn't work.  YASI (Yet Another Stupid Ifdef)
> 
> I think it raises some interesting questions, some may have already been
> answered --

nope, I've been asking them myself as well.

> How does rump interact (if at all) with kernel options?

It doesn't.  I'm not quite sure yet where all this is going yet and
haven't considered it too critical yet.  Maybe I should talk with cube
while he's revamping anyway.  Eventually it would be nice to use rump
for things like makefs instead of having to maintain a duplicate hacked
copy of the file system code.  This theoretically works already, except
for the build process.

Currently kernel options are handled by manually adding some necessary
stuff to librump/rumpkern/opt and CPPFLAGS+=-DFOO in makefiles.  Not very
elegant, but has done the job so far.

> How does rump interact with sysctl-controlled features in kernel code?

No.  There is no link from sysctl back to userspace.  I don't know for
sure OTTOMH, but I don't think you can tell sysctl "hey, actually you
need to change this integer in a different domain".  Of course you can
modify the vars manually, but I guess that's not the same.

Maybe something like "do sysctl for this process instead of the kernel"?
Well, just mumbling, like I said, I don't know where it's going yet ;)

> do the linksets Just Work?

Apparently, file systems are vfs_attach()ed that way ;)

-- 
Antti Kantee <pooka@iki.fi>                     Of course he runs NetBSD
http://www.iki.fi/pooka/                          http://www.NetBSD.org/
    "la qualité la plus indispensable du cuisinier est l'exactitude"