[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Path to kmods
On Thu, Nov 13, 2008 at 08:58:37AM +0000, Andrew Doran wrote:
> On Wed, Nov 12, 2008 at 05:54:14PM +0100, Manuel Bouyer wrote:
> > I'm not sure uname -r would be enough for this specific case. I'm not even
> > sure modules built for a native kernel will work with a Xen kernel. at the
> > very last this is true for i386 where we'll need different modules for
> > i386 and i386PAE.
> We could make paddr_t and friends always be 64-bits in kernel.
> > But I suspect things like device drivers can't be shared because some
> > includes part of the kernel ABI are different (in interrupt or bus_space
> > areas for example).
> bus_space and bus_dma on x86 are module friendly. Most everything is a
> function call. There could potentiall be problems with some macros and
> inlines in intr.h but that should be easy to fix. I haven't checked over
> the xen headers.
> > FWIW, linux has different module sets for native and Xen kernels,
> > and they use different uname -r. I wonder if we should also have different
> > uname -r for amd64/i386 and xen, or use something else (uname -m ?) for
> > it. But changing uname -p may break third-party software builds ...
> I disagree. Rather than succumb to uncertainty and deal with an increasing
> number of permutations I think we should focus on fixing compatibility
> issues as they are identified.
would you say that modules should be the same between say, amiga and mac68k ?
native and xen kernels are really different and should have a different
uname -m. I really don't think we can make modules sharable across different
machines without increased complexity and exectution cost.
Manuel Bouyer, LIP6, Universite Paris VI.
NetBSD: 26 ans d'experience feront toujours la difference
Main Index |
Thread Index |