On 20.12.2010 22:58, Adam Hamsik wrote: > > On Dec,Monday 20 2010, at 8:46 PM, Manuel Bouyer wrote: > >> On Sun, Dec 19, 2010 at 04:50:39PM -0500, Greg Troxel wrote: >>> >>> Manuel Bouyer <bou...@antioche.eu.org> writes: >>> >>>> 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. >>> >>> 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.) >> >> 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 ... > > Or we should have i386-pae architecture for pae build kernels.
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.mig...@free.fr
