compiling parts of kernel in userland

K. Macy kmacy at
Thu Jun 11 07:10:02 UTC 2015

On Jun 10, 2015 11:57 PM, "Garrett Cooper" <yaneurabeya at> wrote:
> On Jun 10, 2015, at 23:56, K. Macy <kmacy at> wrote:
> > On Jun 10, 2015 11:53 PM, "Garrett Cooper" <yaneurabeya at>
> > >
> > > (Adding -testing because this pertains to testing)
> > >
> > > On Jun 10, 2015, at 23:48, K. Macy <kmacy at> wrote:
> > >
> > > > I started work on something I called libukern which allows you to
> > > > essentially all non platform code in user adding a PCI passthrough
> > > > 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
> > > > 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

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.


More information about the freebsd-testing mailing list