Date: Wed, 13 Dec 2000 06:58:42 -0800 From: Julian Elischer <julian@elischer.org> To: mjacob@feral.com Cc: Mike Smith <msmith@FreeBSD.ORG>, arch@FreeBSD.ORG Subject: Re: Proposed bus address typedef. Message-ID: <3A378EA2.A7C14084@elischer.org> References: <Pine.BSF.4.21.0012122323430.606-100000@beppo.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Jacob wrote:
>
> A bus address is always going to be some kind of compound type. For example, a
> VME address is always a duple of address and address modifier.
>
> But what is you're trying to get at here? The needs of the busdma subsystem
> are such that a compound type is natural (and you extract the n-bit cookie to
> program your dma engine as needed from it- this is very similar to Solaris).
>
> But the CPU needs of bus address are different in different contexts. There's
> a natural virtual flat size (e.g., 32 bits for ia32, 64 bits for alpha). But
> there are possibly associated extra bits that don't fit conveniently in the
> natural pointer word size (I assume the PAE stuff is like this). But it's
> going to need to either strongly typed as to what to do with the extra bits or
> you have to be platform cognizant.
Mike mentions 36 bits for ia32.
I would be hesitant to make the value 36 bits for i386 because having looked at
the way they do this, there is no reason they couldn't extend it to 64 bits
in the 'pentiumV'. The page table entries have another 28 bits marked
"reserved".
>
> I would suggest that you define bus address as an opaque handle with methods
> for extracting:
>
> a kernel virtual pointer to the object for the calling cpu
> [ note that this *could* be different for different CPUs ]
>
> an appropriate DMA value that can be used to point to the object
> (note that this implies seperate methods for 32 and 64 bit PCI
> implementations)
>
> if you *must* have a scalar that represents the raw bits (if possible)
> that reflect the platform physical representation of the object,
> pick the largest integer scalar we support (64 bits). This would,
> for example, have the full 40 bit address in alpha of some I/O
> addresses (e.g.).
>
> [ a list of other types could go here ]
>
> That is, if you're boing to break binary compatibility, break it thoroughly
> and leave us some headroom to DTRT with respect to objects.
>
> -matt
>
--
__--_|\ Julian Elischer
/ \ julian@elischer.org
( OZ ) World tour 2000
---> X_.---._/ presently in: Budapest
v
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A378EA2.A7C14084>