linux-kernel - Re: [RFC] Simple userspace interface for PCI drivers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <44F78E88.8050602@myri.com>
Date:	Thu, 31 Aug 2006 21:36:08 -0400
From:	Brice Goglin <brice@...i.com>
To:	Greg KH <greg@...ah.com>
CC:	Matt Porter <mporter@...eddedalley.com>,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC] Simple userspace interface for PCI drivers

Greg KH wrote:
> On Wed, Aug 30, 2006 at 09:34:10AM -0500, Matt Porter wrote:
>   
>> On Tue, Aug 29, 2006 at 11:23:38PM -0700, Greg KH wrote:
>>     
>>> A while ago, Thomas and I were sitting in the back of a conference
>>> presentation where the presenter was trying to describe what they did in
>>> order to add the ability to write a userspace PCI driver.  As was usual
>>> in a presentation like this, the presenter totaly ignored the real-world
>>> needs for such a framework, and only got it up and working on a single
>>> type of embedded system.  But the charts and graphs were quite pretty :)
>>>
>>> Thomas and I lamented that we were getting tired of seeing stuff like
>>> this, and it was about time that we added the proper code to the kernel
>>> to provide everything that would be needed in order to write PCI drivers
>>> in userspace in a sane manner.  Really all that is needed is a way to
>>> handle the interrupt, everything else can already be done in userspace
>>> (look at X for an example of this...)
>>>       
>> What about portable access to the PCI DMA API from userspace?
>>     
>
> It currently does not provide this, but if you know how your card works,
> I'm pretty sure you can get this working without such an interface.
>
> If you wish to add this functionality, to make it easier, that would be
> great.
>   

I might be nice to have something like a copy-block where the
application writes/reads data, while the device does DMA only from/to
there. We would need an easy way to mmap some anonymous DMA-ready memory
in user-space, and something to give the corresponding DMA addresses to
the application.


Additionally, the current code might not be flexible enough regarding
acknowledging of interrupts. It might be good to use the bit that PCI
2.2 defines in the config space to mask/unmask interrupt in a generic
way. Something like : when an interrupt comes, the driver mask the
interrupts using this bit, and then passes the event to user-space. The
user-space interrupt handler acknowledges the interrupt with the device
specific code, and then unmask with the PCI 2.2 bit.

Brice

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/