Hallo! On Mon, 9 May 2011 12:17:51 +0200, Samuel Thibault <samuel.thiba...@gnu.org> wrote: > Thomas Schwinge, le Mon 09 May 2011 11:15:15 +0200, a écrit : > > > The patches however add a few > > > kernel RPCs, which we should probably agree on first, at the minimum > > > that their existence makes sense, so we can reserve slots in upstream > > > gnumach. Basically, it's about allocating physically-contiguous memory > > > for DMAs, and getting IRQ events: > > > > Of course, it doesn't matter at the moment, but are these for x86 only, > > or architecture independent?
(I meant that given the non-usability of GNU Mach on other machines, it doesn't matter interface-wise whether we put them into mach.defs or mach_i386.defs.) Of course, making it independent of the architecture right now is better. > Well, it does matter since that changes the allocation which we'd do. I > believe that as it is proposed, it is architecture-agnostic: allocating > a physically-contiguous area of memory for things like DMAs, and being > notified of hardware requests. The vocabulary of the calls should be > made arch-neutral of course. Ack. > > Hmm, I guess we don't have anything that is better than using > > vm_address_t for physical addresses? At least not in > > include/mach/std_types.h, i386/include/mach/i386/vm_types.h. Should we? > > (phys_address_t based on natural_t?) > > Maybe we should, indeed, else we can't do PAE. But -- if this can return full PAE addresses -- then a natural_t isn't big enough either. As we have to be PAE-agnostic at this level (you can exchange a PAE with a non-PAE kernel, and expect your system still to work), we'd need something that works in either case -- in any cases where we mean to be ABI compatible, which for PAE va. non-PAE only is physical addresses. (Same for the Xen port, I guess?) While we're at this, we could also think about any issues with running a 32 bit user land on a 64 bit GNU Mach -- but at this kernel interface, that's already covered with PAE addresses, I think? > > At this time, would it make sense to make paddr inout (and/or vaddr, > > too?) and add an additional ``anywhere : boolean_t'' parameter as > > vm_allocate has? Or can't there be any need for such functionality? > > I was wondering too. I don't think it makes sense for paddr: either you > do care, and then should simply use /dev/mem and whatever we implement > behind (currently it's the mem driver), or you don't care. OK. > For vaddr, I was wondering. With Zheng Da's current implementation it's > not trivial to add !anywhere support, but it could make sense indeed. OK. We don't have to implement it (if we don't have a need for it at the moment), but we should provision for it in the RPC interface (and always have it fail with KERN_INVALID_ARGUMENT or whatever is appropriate). Grüße, Thomas
pgpzwxt0UL0gt.pgp
Description: PGP signature
