[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: freebsd 5.99.41 as XEN3_DOMU
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 <bouyer%antioche.eu.org@localhost> 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).
Main Index |
Thread Index |