Discussion:
compiling parts of kernel in userland
John-Mark Gurney
2015-06-10 22:46:54 UTC
Permalink
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."
Adrian Chadd
2015-06-11 05:13:24 UTC
Permalink
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
Post by John-Mark Gurney
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."
_______________________________________________
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
K. Macy
2015-06-11 06:48:08 UTC
Permalink
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
Post by Adrian Chadd
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
Post by John-Mark Gurney
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."
_______________________________________________
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
_______________________________________________
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
Garrett Cooper
2015-06-11 06:53:08 UTC
Permalink
(Adding -testing because this pertains to testing)
Post by 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.
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
K. Macy
2015-06-11 06:56:30 UTC
Permalink
Post by Garrett Cooper
(Adding -testing because this pertains to testing)
Post by 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.
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
Garrett Cooper
2015-06-11 06:57:22 UTC
Permalink
Post by Garrett Cooper
(Adding -testing because this pertains to testing)
Post by 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.
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?
K. Macy
2015-06-11 07:10:01 UTC
Permalink
Post by Garrett Cooper
Post by K. Macy
Post by Garrett Cooper
(Adding -testing because this pertains to testing)
Post by 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.
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…
Post by Garrett Cooper
Post by K. Macy
I looked at that first before starting a predecessor to uinet. You'll
just have to trust me: no, it's not.
Post by Garrett Cooper
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
Craig Rodrigues
2015-06-12 02:53:43 UTC
Permalink
Post by K. Macy
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
K. Macy
2015-06-12 03:03:08 UTC
Permalink
Post by Craig Rodrigues
Post by K. Macy
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
Post by Craig Rodrigues
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".
Post by Craig Rodrigues
I recently asked a similar question about xhyve (bhyve for OS X),
https://lists.freebsd.org/pipermail/freebsd-virtualization/2015-June/003624.html
Post by Craig Rodrigues
That's really all that is needed. If it will take hours to gather that
info,
Post by Craig Rodrigues
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
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
Post by Craig Rodrigues
:)
--
Craig
--
Craig
Hans Petter Selasky
2015-06-11 10:41:01 UTC
Permalink
Post by K. Macy
Post by Garrett Cooper
(Adding -testing because this pertains to testing)
Post by 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
Post by Garrett Cooper
Post by K. Macy
so one can run unmodified drivers in user. Libuinet is great as far as
it
Post by Garrett Cooper
Post by K. Macy
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
Loading...