I am having a bit of trouble given that I am not super familiar with NetBSD (although I hope that will change).

Just compiled netbsd-current in XEN domain installed userland and all the new kernel modules in the DOMU root file system, booted the new kernel and everything works great except for a problem that should be obvious but I can't figure it out...

when I issue a modload solaris (or for that matter a modload "anything") I get the following message:

modload: Function not implemented

What am I doing wrong? Probably an obvious answer. 

The whole reason I want to run current is to test ZFS on NetBSD.

Thanks

RB

[ message continues ]

Well, in the current state, modules are a not enabled in the Xen kernels
(modules should be built specifically for Xen, but the build tools do not
allow this right now). So you have to compile all what you need in a
monolitic kernel. But ZFS is only available as module, so unfortunably
this means no ZFS for xen.
One way around it is to run NetBSD in a HVM guest.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--
[ message continues ]

Is it that in src/share/mk/bsd.kmodule.mk one would have to add some
support to build a XEN DOMU flavor of modules?    Is it reasonably easy
to just hack it in so that one gets XEN modules *instead* of standard
modules?  (Obviously not suitable for committing, but could be useful.)
[ message continues ]

there's also the search path issue; the uname values are the same
for i386 ws xen kernels (by purpose, there was no real reasons to
make a difference for userland) the module path is the same.
This is IMHO a mistake, the modules should be tied to a kernel,
not a userland ...

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--
[ message continues ]

Or we should have i386-pae architecture for pae build kernels.

Regards

Adam.

[ message continues ]

That's a possibility. AFAICR, this was never really solved, and the
module path "issue" is exacerbated for i386: i386 + xen + pae makes for
4 different possibilities, but for the same userland (*).

IMHO, uname -m should remain "i386". However, I wonder if the module
path should rather be a sysctl(7) string, with a value adapted to the
type of kernel used.

* not necessarily true for Xen, as a domain can implement "fast
syscalls", where "int 0x81" directly traps to the domain kernel rather
than jumping to hypervisor (like init 0x80 does).

-- 
Jean-Yves Migeon
jeanyves.migeon@free.fr
[ message continues ]

and i386-xen and i386-xen-pae ?
I'm not sure it's a good idea to expose this to userland via unable
(and it's probably going to confuse some ./configure scripts)

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--
[ message continues ]

On Sun, 19 Dec 2010 20:54:26 +0100

It it common for modules not to be able to be statically linked in a
monolithic kernel?  I understand providing ZFS as a module is
convenient for licensing reasons, but probably that it shouldn't be too
hard to somehow optionally link such a module to a kernel image at
build time, and call an init/load hook at boot runtime?

I tend to think that other than allowing to optionally dynamically load
code, another advantage to modules would probably be that they also can
optionally be included monolitically, with ideally no code changes...

Thanks,
-- 
Matt
[ message continues ]