Date: Tue, 12 Dec 2000 23:37:57 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: Mike Smith <msmith@FreeBSD.ORG> Cc: arch@FreeBSD.ORG Subject: Re: Proposed bus address typedef. Message-ID: <Pine.BSF.4.21.0012122323430.606-100000@beppo.feral.com> In-Reply-To: <200012130730.eBD7UV307046@mass.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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 On Tue, 12 Dec 2000, Mike Smith wrote: > > I'd like to propose some changes to the way we represent bus addresses, to > deal with situations where u_long (IMO not a good choice to begin with) > is too small. > > Specifically, I'd like to be able to deal with x86 systems in PAE mode, > where physical addresses are 36 bits in size. > > To achieve this, I would like to introduce a typedef, bus_addr_t, which > is defined on a given platform as being large enough to contain any > bus-addressable location. > > This type would then be used in the following applications (initially): > > - The resource manager > - The resource list code (helpers for bus implementations) > - The busspace and busdma subsystems > > Note that this will break binary compatibility with loadable modules, but > should not cause significant problems at the source level with code > currently assuming that u_long or u_int32_t is big enough (except when it > isn't, of course). > > Comments? > > -- > ... every activity meets with opposition, everyone who acts has his > rivals and unfortunately opponents also. But not because people want > to be opponents, rather because the tasks and relationships force > people to take different points of view. [Dr. Fritz Todt] > V I C T O R Y N O T V E N G E A N C E > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > 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?Pine.BSF.4.21.0012122323430.606-100000>