Re: Using rump kernel to provide drivers?

  • From: Justin Cormack <justin@xxxxxxxxxxxxxxxxxxxxx>
  • To: unknown unknown <garasubo@xxxxxxxxx>
  • Date: Wed, 29 Jul 2015 14:00:33 +0100

On 29 July 2015 at 07:42, Takumi Shimada <garasubo@xxxxxxxxx> wrote:

Hi all,

I am also interested in running rump kernel to use NetBSD drivers.
I plan to run rump kernel on the bare metal ARM board and use network
driver.
I wonder how to configure hardware information (e.g. like Linux's
DeviceTree) and how to implement hypcalls.
I have downloaded rumprun, frankenlibc and genode. But I cannot understand
how to implement hardware specific parts for rump kernel.
Could you explain what should I do for running drivers or tell me good
examples which implement hardware specific parts?

Is the board you are porting to already supported on NetBSD? NetBSD does not use
devicetree but this article explains the basics of how config works on Arm
http://www.netbsd.org/docs/kernel/porting_netbsd_arm_soc.html

To get frankenlibc working, start by copying platform/qemu-arm and
adjust the platform.sh and link.ld files as needed, then implement the
__libc_start_main.c for the platfom init, and write.c to write to
console. That should boot but you will then need to add a real clock
driver and memory allocator, although the dummy ones should still
boot.

Justin




Thanks,
Takumi



2015-07-25 0:39 GMT+09:00 Antti Kantee <pooka@xxxxxx>:

On 24/07/15 14:58, Tony Zhang wrote:

Hi all,

I am quite new to this project and I have downloaded and looked around in
the
repo for some time. We are interested in using parts of rump kernels in
our
research OS. Specifially, we'd like to add more drivers to our OS, and
running
NetBSD drivers inside rumpkernels seems like a really good way to do
this. From
my limited understanding, this requires that I implement some hypercalls
used by
said drivers. I think I am on the right track but there seems to be more
to it
so I would appreciate your thought on this. Is it viable?


Well, you obviously need to interface with the drivers somehow from your
OS. Unlike POSIX'y syscalls, there's really no standardized interfaces for
interfacing "into" the kernel. Check out section 3.6 of book.rumpkernel.org
(1st edition) for some clues. Interfacing through syscalls might work too,
but it's not possible to list the tradeoffs without knowing more about your
case. See also http://wiki.rumpkernel.org/Platforms#integrating



Other related posts: