On Mon, Dec 20, 2010 at 10:58:18PM +0100, Adam Hamsik wrote:
quoted text >
> 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 <bouyer@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.
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
--
