Re: CVS commit: src/sys/arch

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

On 24.07.2010 17:54, Matthias Drochner wrote:
> 
> cube%cubidou.net@localhost said:
>> Kernel modules, on the other hand...
> 
> Hmm, didn't think of that. (using them myself only for testing)
> 
>> a gaping ABI incompatibility is completely unacceptable
> 
> There are two ways to fix this without the 64-bit-paddr overhead,
> a short-term and a long-term one.
> The short-term fix would be to use another module load path.
> This is close to calling it a different port, but it would
> not affect userland.

"i386pae" and "i386"? Huh... then we will get i386xenpae, i386xen, and
so on?

> A more correct but more expensive fix would be to keep out
> paddr_t from the kernel ABI relevant to modules.

Then bus_addr_t and paddr_t should be split.

I do not think that there are many modules that make use of
paddr_t-bound variables; in itself, it should remain within uvm and pmap.

My biggest concern is that there is no real "stable KPI" we could rely
on. rmind@ is reworking the pmap/uvm code in its branch, but told me (in
a private mail) that it may take some time before he merges it. So I
asked if I could commit PAE first and come back to it later.

A long term fix would be to reuse (and probably extend) the modular
world, and have some kind of "one kernel fits all" possibility for x86,
because paddr_t/PD/PT handling also differs with Xen. But making that
work in a safe and consistant manner, without breaking ABI, needs more
thought that I currently could put in my patch.

Cheers,

-- 
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost