Re: user-level drivers

[Samuel Thibault]

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?

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.

> 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.

> 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.

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.

> > The actual event:
> > 
> > simpleroutine mach_notify_irq(
> >                notify  : notify_port_t;
> >                name    : int);
> 
> I don't understand this ``name : int''.  Isn't this rather a pointer to a
> struct mach_irq_notification_t?

It's actually the interrupt line number.

> What about using the I/O port scheme?  That is, decide_intr_notify
> doesn't enable IRQ notifications, but instead just returns a handle
> (compare i386_io_perm_create) that is then passed to device_irq_enable to
> enable/disable IRQ notifications (compare i386_io_perm_modify).  Does
> that make sense in this IRQ scenario?

It probably looks better, yes.

Samuel