[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: user-level drivers

From: Richard Braun
Subject: Re: user-level drivers
Date: Mon, 9 May 2011 10:55:36 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

On Mon, May 09, 2011 at 12:07:16AM +0200, Samuel Thibault wrote:
> I've started having a look at Zheng Da's user-level driver integration.
> I've cleaned his tree a bit, and now considering adding patches to
> the debian packages for wider testing.  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:
> /*
>  *      This routine is created for allocating DMA buffers.
>  *      We are going to get a contiguous physical memory
>  *      and its physical address in addition to the virtual address.
>  */
> routine vm_allocate_contiguous(
>                 host_priv       : host_priv_t;
>                 target_task     : vm_task_t;
>         out     vaddr           : vm_address_t;
>         out     paddr           : vm_address_t;
>                 size            : vm_size_t);

This RPC lacks a few additional constraints like boundaries, alignment
and maybe phase. We may not use them now, but they're important for
portability (e.g. if GNU Mach supports PAE, drivers that can't use
physical memory beyond the 4 GiB limit must be able to express it).

> /* Requesting IRQ events on a port */
> routine device_intr_notify(
>                master_port     : mach_port_t;
>        in      irq             : int;
>        in      id              : int;
>        in      flags           : int;
>        in      receive_port    : mach_port_send_t
>        );
> The actual event:
> simpleroutine mach_notify_irq(
>                notify  : notify_port_t;
>                name    : int);
> And a way to mask/unmask irqs:
> /*
>  *     enable/disable the specified irq.
>  */
> routine device_irq_enable(
>                master_port     : mach_port_t;
>                irq             : int;
>                status          : char);
> Should this be rather split into device_irq_enable/disable and drop the
> status paramter?

Naming a function taht can disable something "xxx_enable" is confusing.
By the way, I also think using both "intr" and "irq" is confusing. We
should stick with "intr". device_intr_notify() isn't a suitable name as
it doesn't make it obvious that it's a registration request. It should
rather be named device_intr_establish() or device_intr_register().
Parameters named "irq" could be renamed "line" instead. And we should
also follow the way Mach names are built (i.e. module_object_method).
mach_notify_irq() could be renamed mach_intr_notify().
device_irq_enable() would be named device_intr_enable().

Richard Braun

reply via email to

[Prev in Thread] Current Thread [Next in Thread]