[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: user-level drivers
From: |
Samuel Thibault |
Subject: |
Re: user-level drivers |
Date: |
Mon, 9 May 2011 12:17:51 +0200 |
User-agent: |
Mutt/1.5.12-2006-07-14 |
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
- user-level drivers, Samuel Thibault, 2011/05/08
- Re: user-level drivers, Richard Braun, 2011/05/09
- Re: user-level drivers, Thomas Schwinge, 2011/05/09
- Re: user-level drivers,
Samuel Thibault <=
- Re: user-level drivers, Richard Braun, 2011/05/09
- Re: user-level drivers, Thomas Schwinge, 2011/05/09
- Re: user-level drivers, Richard Braun, 2011/05/09
- Re: user-level drivers, Samuel Thibault, 2011/05/09
- Re: user-level drivers, Richard Braun, 2011/05/10
- Re: user-level drivers, Thomas Schwinge, 2011/05/09
Re: user-level drivers, olafBuddenhagen, 2011/05/26
Re: user-level drivers, olafBuddenhagen, 2011/05/26