compiling parts of kernel in userland

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

compiling parts of kernel in userland

John-Mark Gurney-2
I'm not the only one doing this (libzpool does this w/ zfs_context.h),
but what do we need to do to make it easier/more standard to be able
to compile kernel code into a userland program for testing and other
purposes.

I know I'm now the only one to do it, but I can't seem to find any
docs on how people are doing this, and exactly what issues people have
run into when doing this.

My goal is to have documentation and integrated necessary code into
FreeBSD to make this as simple as possible.  My main goal is to make
it easier to compile kernel code into userland test harnesses.

Thanks.

--
  John-Mark Gurney Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: compiling parts of kernel in userland

Adrian Chadd-2
Hi,

please look at libuinet. I'd really like the libuinet framework to be
in freebsd-head so we can build various forms of the freebsd kernel as
userland support code.


-a


On 10 June 2015 at 15:46, John-Mark Gurney <[hidden email]> wrote:

> I'm not the only one doing this (libzpool does this w/ zfs_context.h),
> but what do we need to do to make it easier/more standard to be able
> to compile kernel code into a userland program for testing and other
> purposes.
>
> I know I'm now the only one to do it, but I can't seem to find any
> docs on how people are doing this, and exactly what issues people have
> run into when doing this.
>
> My goal is to have documentation and integrated necessary code into
> FreeBSD to make this as simple as possible.  My main goal is to make
> it easier to compile kernel code into userland test harnesses.
>
> Thanks.
>
> --
>   John-Mark Gurney                              Voice: +1 415 225 5579
>
>      "All that I will do, has been done, All that I have, has not."
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "[hidden email]"
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: compiling parts of kernel in userland

K. Macy
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.

-K
On Jun 10, 2015 10:13 PM, "Adrian Chadd" <[hidden email]> wrote:

> Hi,
>
> please look at libuinet. I'd really like the libuinet framework to be
> in freebsd-head so we can build various forms of the freebsd kernel as
> userland support code.
>
>
> -a
>
>
> On 10 June 2015 at 15:46, John-Mark Gurney <[hidden email]> wrote:
> > I'm not the only one doing this (libzpool does this w/ zfs_context.h),
> > but what do we need to do to make it easier/more standard to be able
> > to compile kernel code into a userland program for testing and other
> > purposes.
> >
> > I know I'm now the only one to do it, but I can't seem to find any
> > docs on how people are doing this, and exactly what issues people have
> > run into when doing this.
> >
> > My goal is to have documentation and integrated necessary code into
> > FreeBSD to make this as simple as possible.  My main goal is to make
> > it easier to compile kernel code into userland test harnesses.
> >
> > Thanks.
> >
> > --
> >   John-Mark Gurney                              Voice: +1 415 225 5579
> >
> >      "All that I will do, has been done, All that I have, has not."
> > _______________________________________________
> > [hidden email] mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> > To unsubscribe, send any mail to "[hidden email]"
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "[hidden email]"
>
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: compiling parts of kernel in userland

Enji Cooper
(Adding -testing because this pertains to testing)

On Jun 10, 2015, at 23:48, K. Macy <[hidden email]> 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…
Thanks,
-NGie

signature.asc (507 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: compiling parts of kernel in userland

K. Macy
On Jun 10, 2015 11:53 PM, "Garrett Cooper" <[hidden email]> wrote:
>
> (Adding -testing because this pertains to testing)
>
> On Jun 10, 2015, at 23:48, K. Macy <[hidden email]> 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.

-K
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: compiling parts of kernel in userland

Enji Cooper
On Jun 10, 2015, at 23:56, K. Macy <[hidden email]> wrote:

> On Jun 10, 2015 11:53 PM, "Garrett Cooper" <[hidden email]> wrote:
> >
> > (Adding -testing because this pertains to testing)
> >
> > On Jun 10, 2015, at 23:48, K. Macy <[hidden email]> 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?

signature.asc (507 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: compiling parts of kernel in userland

K. Macy
On Jun 10, 2015 11:57 PM, "Garrett Cooper" <[hidden email]> wrote:
>
> On Jun 10, 2015, at 23:56, K. Macy <[hidden email]> wrote:
>
> > On Jun 10, 2015 11:53 PM, "Garrett Cooper" <[hidden email]>
wrote:
> > >
> > > (Adding -testing because this pertains to testing)
> > >
> > > On Jun 10, 2015, at 23:48, K. Macy <[hidden email]> 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
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: compiling parts of kernel in userland

Hans Petter Selasky-6
In reply to this post by K. Macy
On 06/11/15 08:56, K. Macy wrote:

> On Jun 10, 2015 11:53 PM, "Garrett Cooper" <[hidden email]> wrote:
>>
>> (Adding -testing because this pertains to testing)
>>
>> On Jun 10, 2015, at 23:48, K. Macy <[hidden email]> 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.
>

FYI:

We already have libcuse and cuse.ko in base for character devices in
userspace.

--HPS

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: compiling parts of kernel in userland

Craig Rodrigues-2
In reply to this post by K. Macy
On Thu, Jun 11, 2015 at 12:10 AM, K. Macy <[hidden email]> 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

:)

--
Craig



--
Craig
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: compiling parts of kernel in userland

K. Macy
On Jun 11, 2015 7:53 PM, "Craig Rodrigues" <[hidden email]> wrote:
>
>
>
> On Thu, Jun 11, 2015 at 12:10 AM, K. Macy <[hidden email]> 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
>
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"