Earlier quoted context omitted.
Ya, OpenBSD has done some pretty remarkable work on the laptop front, and I find it interesting, because it's not where I would have guessed they'd be interested. They're leaders in the accelerated gfx and wireless. I'm used to thinking of the project being more focused on hardening applications. Certainly NetBSD has benefited from the work done in Open, by way of the famous *BSD cross-pollination. I hope you enjoy N…
> Ya, OpenBSD has done some pretty remarkable work on the > laptop front, and I find it interesting, because it's not > where I would have guessed they'd be interested. My guess is this stems from the very strong dogfooding culture the OpenBSD devs seem to have. If most/all of them are running OpenBSD on their main systems, and some subset of those folks use laptops as their main systems, then I am sure they are moti…
Announcing NetBSD 7.0
21–26 of 26 posts
Re: Announcing NetBSD 7.0
#22I'm not sure if I understand well the "rump kernel"/"anykernel" idea as implemented in NetBSD. Could anybody please help me with that - specifically, how this differs from a microkernel? My current idea is that I can take the current NetBSD kernel and: a) for some (any? or only some?) hardware subsystems, ask the kernel (by some switch/config? where?) to run drivers in userspace, in "microkernel-like" way (and thus t…
There is a difference between what is possible to do with rump kernels and what NetBSD is currently doing with them. The basic point is to be able to use the same code in different contexts, so in theory you could use rump kernels in implementing a microkernel. However, AFAIK NetBSD currently uses it for (optionally) running filesystems in userland (so you can mount potentially corrupted file systems without crashing…
(I remembered that Haiku got network drivers from some WhatsitBSD, so I thought those are maybe there too, but it seems it was FreeBSD actually, so just some confusion of mine. So no microkernel there, it seems. Bummer.)
As to running on Xen etc, that was what I seemed to vaguely remeber as what rump kernels mean, so I was really confused and surprised to slowly find out that the NetBSD usage of the term seems to diverge quite substantially, as far as I can (or can't?) understand. Hmph.
Re: Announcing NetBSD 7.0
#23I'm not sure if I understand well the "rump kernel"/"anykernel" idea as implemented in NetBSD. Could anybody please help me with that - specifically, how this differs from a microkernel? My current idea is that I can take the current NetBSD kernel and: a) for some (any? or only some?) hardware subsystems, ask the kernel (by some switch/config? where?) to run drivers in userspace, in "microkernel-like" way (and thus t…
"a" is sort of orthogonal to rump kernels, but yes, you can run at least file system drivers transparently as userspace servers (just give -o rump to mount(8)). I've also run a USB modem driver as a userspace server, in the "the kernel I'm running doesn't contain support, but a future kernel revision has" fashion. For "b", rump kernels don't support "compiling out". Rather, the idea is to "link in" only what you need…
Re: Announcing NetBSD 7.0
#24Earlier quoted context omitted.
There is a difference between what is possible to do with rump kernels and what NetBSD is currently doing with them. The basic point is to be able to use the same code in different contexts, so in theory you could use rump kernels in implementing a microkernel. However, AFAIK NetBSD currently uses it for (optionally) running filesystems in userland (so you can mount potentially corrupted file systems without crashing…
Uh, so only FS for now? That's sure nice, and a nice start, but I really thought there's more to it. Thanks for the clarification & and details. (I remembered that Haiku got network drivers from some WhatsitBSD, so I thought those are maybe there too, but it seems it was FreeBSD actually, so just some confusion of mine. So no microkernel there, it seems. Bummer.) As to running on Xen etc, that was what I seemed to va…
There is a FAQ with more information at: https://github.com/rumpkernel/wiki/wiki/Info:-FAQ
I'm pretty sure that Antti created these terms, so it is an authoritative definition :).
Re: Announcing NetBSD 7.0
#25I am so excited! I have been waiting to have an excuse to spend some time with BSD, Lua kernel scripting is definitely going to be something I mess with this weekend. Awesome!
Have you seen any info on where to get started with the Lua kernel scripting? This sounds like too much fun!
The manpages for lua(4) and luactl(8) may be of help.
lua(4) is the device driver which allows you manage Lua states in the kernel through an ioctl interface. With luactl(8) you can create and destroy states, load and execute scripts, and require modules.
Example:
1. Load lua(4) driver modload lua 2. Create a Lua state in the kernel luactl create s0 3. Load and execute a script named hello.lua luactl load s0 ./hello.lua 4. dmesg
A Lua state is created empty. In order to load the standard libs (base, string, table, ...) into that state you'd need to do a luaL_openlibs(). Even though the libs are compiled into lua(4), you can't easily load them with luactl. [1] is a patch that adds a 'openlibs' command to luactl. After you apply it and recompile luactl, you can do that:
luactl openlibs s0
Btw, we've ported Lua test suite to the NetBSD kernel in this year's GSoC. Part of the work was on porting parts of the standard libraries which were not available in kernel Lua (e.g., os, io, math). Take a look at [2].
Let me know if you need any help. My email address is my HN username at gmail.com
---- [1] https://github.com/gmesalazar/kerneltest/blob/master/kernel/... [2] https://github.com/gmesalazar/kerneltest/
Re: Announcing NetBSD 7.0
#26Earlier quoted context omitted.
Uh, so only FS for now? That's sure nice, and a nice start, but I really thought there's more to it. Thanks for the clarification & and details. (I remembered that Haiku got network drivers from some WhatsitBSD, so I thought those are maybe there too, but it seems it was FreeBSD actually, so just some confusion of mine. So no microkernel there, it seems. Bummer.) As to running on Xen etc, that was what I seemed to va…
I just saw this so not sure if you'll actually see this response, but rump kernel doesn't imply Xen or such, that is just a common thing people want to do with them. It just means kernel drivers that can be used outside the kernel. Anykernel refers to a kernel that can be used that way with minimal differences and without modifying individual drivers. So rump kernel is "libkernel" and an anykernel is one way to get a…