Re: paddr_t change to 64-bits

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Tue, 28 Sep 2010 22:58:39 +0200
    From:        Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>
    Message-ID:  <4CA256FF.3040308%free.fr@localhost>

  | There is no other choice -- how can you expect kernel modules to be
  | shared between PAE and !PAE systems then?

Hmm - personally I don't care about modules, so I tend not to consider
them at all, what I'd like to be able to keep (perhaps, its benefit will
depend upon benchmark results of course) is the ability to keep a small
efficient monolithic i386 kernel for small systems.

  | Splitting i386 in two machine archs, "i386" and "i386pae"?

That's what we do with i386 and amd64 isn't it?   They're both really
basically the same architecture, just one has 64 bit addresses, the other
doesn't ...  (and yes, I know, a few other differences).

  | Then we would also have "i386xen", "i386xenpae". Huh...

Don't know enough about xen to comment on whether that's different enough
to actually be a different architecture, or just the same thing with some
different drivers and low level interface routines.

  | As I said in another mail, I do think that paddr_t should be the
  | standard for interfaces.

If it is to be used for that, then something else should be used inside
the kernel - that's true for this, and lots more, making the API use the
same data types as the kernel uses internally just complicates enhancements.
We can use a very similar data type - one with the same number of bits, and
same binary representation, where that's appropriate, but it should be
called something different so if one of them needs to change, we can do that
without affecting the other (particularly so what the kernel uses internally
can change without the API/ABI needing to alter - just because of the kernel
change).

  | For i386, it has to be 64 bits.

For the interface, yes, I agree.

  | Implementing optimizations (eg. use 32 bits operations unless strictly
  | required) will be the responsibility of certain code blocks (pmap,
  | bus_dma/space, pool_cache tracking...), and shall use types that
  | are kept private to these blocks.

Yes, that sounds OK.

  | Sadly, currently, paddr_t makes the abstraction leaky.

yes, that's what I was commenting on - while all these changes are happening
seems like the perfect time to clean up at least this one small part of the
interface, decide on an API data type, and use that for the API, and convert
to/from the internal data type at the kernel boundary (where sometimes the
"convert" will be "copyin" but definitely to a differently named data type).

Whether paddr_t is the API data type, or the internal one, I don't care.

kre