linux-kernel - Re: Userspace I/O driver core

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]

Date:	Thu, 14 Dec 2006 16:48:41 +1100
From:	Ben Nizette <ben.nizette@...et.net.au>
To:	linux-kernel@...r.kernel.org
CC:	tglx@...utronix.de
Subject: Re: Userspace I/O driver core

Greg KH wrote:
> But in order to get this core into the kernel tree, we need to have some
> "real" drivers written that use it.  So, for anyone that wants to see
> this go into the tree, now is the time to step forward and post your
> patches for hardware that this kind of driver interface is needed.
>   
We have a product being developed currently for which this interface is 
perfect.

The situation is that we have Linux collecting data from very many 
sources.  The data is processed by throwing it at a memory address at 
which an FPGA lives.  The FPGA processes the data and generates an 
interrupt upon completion at which time the processed data can be read 
back out.  Linux doesn't know anything about the data except it's source 
and destination and, for security reasons, it has to stay that way.  As 
such a formal driver makes little sense: data gets written to a memory 
address and a little while later it is read out again, that's it.  The 
only fly in the ointment is the interrupt.  Before I knew about these 
UIO patches I had written what effectively was a smaller version of UIO 
to handle this interrupt.  With the UIO patches the whole process 
becomes trivial and I (along with my boss) become happy :-)

I shall submit a patch once I move my code over but it's almost not 
worth it, it will be truly trivial.

I can see a similar scenario being played out a lot in industrial 
control and other embedded systems.  For example, if you just want to 
monitor a set of data but interrupt if something critical happens (or 
even just when the data is updated).  All an in-kernel driver would do 
is handle an interrupt and perform copy_{to,from}_user()s but it would 
have to have a fair bit of fluff around it to signal to userland that 
the interrupt had occured.  UIO is a clean, standard and powerful form 
of that fluff.  Congrats to all who worked on her.

Regards,
   Ben.
-
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/