On 20.12.2010 22:58, 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.

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