Re: user-level drivers

[Thomas Schwinge]

Hallo!

On Mon, 9 May 2011 12:17:51 +0200, Samuel Thibault <samuel.thibault@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

pgpdtNLWx1GyZ.pgp
Description: PGP signature