On 24.07.2010 17:54, Matthias Drochner wrote: > > c...@cubidou.net 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.mig...@free.fr
