Re: CVS commit: src/sys/arch

[Masao Uebayashi <uebayasi%tombi.co.jp@localhost>]

On Sat, Jul 24, 2010 at 06:12:39PM +0200, Jean-Yves Migeon wrote:
> 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 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.migeon%free.fr@localhost

Masao

-- 
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635