Re: Path to kmods

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

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.

ugly.

> 
> > 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.           
Manuel.Bouyer%lip6.fr@localhost
     NetBSD: 26 ans d'experience feront toujours la difference
--