Re: paddr_t change to 64-bits

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

    Date:        Tue, 28 Sep 2010 10:49:51 +0200
    From:        Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>
    Message-ID:  <2741c3f0cdb111bbb7077e25f6b47dc5@localhost>

  | In the long run, paddr_t will be a fixed size for i386: 64 bits.

Do you really want to decide that yet?

  | However, we are in transition here: I cannot virtually double paddr_t size
  | (4 => 8 bytes) without carefully checking that it does not affect code,

Yes, of course - and what's more, in the long run, it may prove that for
small i386's 32 bits is the better choice (inside the kernel anyway).

Nothing that you're doing in this regard was the subject of my message.

  | IMHO, the easiest way to fix agp_allocation there is to make "physical" an
  | uint64_t

exactly - uint64_t or agp_addr_t (a newly invented type just for the
purpose perhaps) or something - but something unrelated to the internal
kernel data type (except being certainly big enough).

  | only at this interface

That one I can't comment on, if it is the only place that there's
any movement of "phycical" addresses then it makes sense.

  | (and only for i386...),

but I'd hesitate before being sure that's the right solution - unless
there's a very good reason, don't add machine dependent API interfaces.
I know this is in a fairly MD area anyway, so I'm not certain that i386
only is the wrong choice, and if the API is already inherently MD, that
would make a difference - but otherwise, the benefits in having a single
API for all users far outweighs the cost of passing a few useless bytes
over the user/kernel interface - especially for something like this which
I suspect is not anywhere on the high usage path.

kre