Source-Changes-D archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/sys/arch
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
Home |
Main Index |
Thread Index |
Old Index