On Sat, Jul 24, 2010 at 06:12:39PM +0200, Jean-Yves Migeon wrote: > 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 totally agree. (I know that fixing paddr_t as 64-bit is possible and simpler, I believe that "paddr_t being split from MI" fits NetBSD's aesthetic sense more.) > 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 Masao -- Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635
