compiling parts of kernel in userland

[K. Macy]

On Jun 10, 2015 11:57 PM, "Garrett Cooper" <yaneurabeya at gmail.com> wrote:
>
> On Jun 10, 2015, at 23:56, K. Macy <kmacy at freebsd.org> wrote:
>
> > On Jun 10, 2015 11:53 PM, "Garrett Cooper" <yaneurabeya at gmail.com>
wrote:
> > >
> > > (Adding -testing because this pertains to testing)
> > >
> > > On Jun 10, 2015, at 23:48, K. Macy <kmacy at freebsd.org> wrote:
> > >
> > > > I started work on something I called libukern which allows you to
run
> > > > essentially all non platform code in user adding a PCI passthrough
driver
> > > > so one can run unmodified drivers in user. Libuinet is great as far
as it
> > > > goes, but it's just the network stack. If you want something other
than
> > > > just networking you'll have to do something else.
> > >
> > > If I had enough time and interest I’d look at investing my efforts in
porting RUMP from NetBSD to FreeBSD and going about it that route, but I’m
busy with other efforts so I can’t dedicate my time here yet. It seems like
RUMP is the direction we should be going in…
> >
> > I looked at that first before starting a predecessor to uinet. You'll
just have to trust me: no, it's not.
>
> Why/how is it deficient?

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. Before you push this any
further, download RUMP and just make it *compile* with FreeBSD sources. And
at least when I was looking there was no thought given to device
passthrough.

At least the rubbish that is COMPAT_MACH they had the sense to put in
Attic. I effectively ended up starting over again with OSFMK sources.
Speaking from experience on many "science projects", one "science project"
doesn't necessarily make a good foundation for another.

-K