compiling parts of kernel in userland

[K. Macy]

On Jun 11, 2015 7:53 PM, "Craig Rodrigues" <rodrigc at freebsd.org> wrote:
>
>
>
> On Thu, Jun 11, 2015 at 12:10 AM, K. Macy <kmacy at freebsd.org> wrote:
>>
>>
>> It's a horrible unmaintainable steaming pile. There are of course no
>> objective metrics for such a statement without my wasting hours to go
back
>> and look through it to come up with a comprehensive explanation. So I
>> imagine you'll want to debate this endlessly.
>
>
> No, I'm not interested in debating endlessly.
>
> However, if you had some rough data points as to the downsides
> of rump kernels, it would be very useful for others to know what the
> problems are.  You have a lot of knowledge, so it is nice to share
> your experiences with others.
>
> I've read the whitepapers on rump kernels, and seen some of the
> presentations on it.  On the surface, the NetBSD developers who
> have worked on rump seem like reasonable and smart folks who put a lot of
> hard work into their project.  If I didn't know any better, I would say
their
> stuff is good.
>
> If rump is hard to compile on FreeBSD, that is one valid point.
> If you have other points besides, "it's a steaming pile", it would be nice
> to hear your thoughts.  Otherwise it sounds like "not invented in
FreeBSD, so it sucks".
>
> I recently asked a similar question about xhyve (bhyve for OS X),
> and got a simple succinct answer:
>
https://lists.freebsd.org/pipermail/freebsd-virtualization/2015-June/003624.html
>
> That's really all that is needed.  If it will take hours to gather that
info,
> then I agree, that is a waste of your time.  I'd rather see you contribute
> stuff to FreeBSD, possibly using this Github pull requests
> using this workflow:
>
> https://lists.freebsd.org/pipermail/freebsd-current/2015-April/055551.html

The idea behind RUMP is of course sound and useful. And the implementation
may well have improved dramatically since I last looked. However, my
personal experience with much of NetBSD outside of the core kernel (xen,
mach, SPARC, and perhaps RUMP) is that the code is really unpleasant to
work with and not any sort of reusable framework beyond, perhaps, answering
specific questions. Dillon had some sort of toy user space kernel a while
back. If he he has maintained that it is very likely a better starting
point.

-K

> :)
>
> --
> Craig
>
>
>
> --
> Craig
>