compiling parts of kernel in userland
kmacy at freebsd.org
Thu Jun 11 07:10:02 UTC 2015
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>
> > >
> > > (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
> > > > essentially all non platform code in user adding a PCI passthrough
> > > > so one can run unmodified drivers in user. Libuinet is great as far
> > > > 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