linux-kernel - Re: [PATCH 2/2] New driver: Xillybus generic interface for FPGA (programmable logic)

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 for Android: free password hash cracker in your pocket

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

Message-id: <50BB4BB0.90609@gmail.com>
Date:	Sun, 02 Dec 2012 14:38:08 +0200
From:	Eli Billauer <eli.billauer@...il.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Philip Balister <philip@...ister.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, Pavel Machek <pavel@...x.de>,
	John Linn <john.linn@...inx.com>,
	Michal Simek <michal.simek@...inx.com>,
	"Ira W. Snyder" <iws@...o.caltech.edu>,
	Josh Cartwright <josh.cartwright@...com>
Subject: Re: [PATCH 2/2] New driver: Xillybus generic interface for FPGA
 (programmable logic)

On 12/01/2012 10:48 PM, Arnd Bergmann wrote:
> I agree that is a concern, but for now, I'm mostly worried about
> the kernel-to-user interface. If we can agree on a driver interface
> that works for Xillybus as well as any of the others we know about,
> we can start using that as the generic kernel FPGA interface.
>
> Once we get a second FPGA driver, that can use the same user
> interface but talk to the hardware in a different way, and then
> we can reorganise the code to keep the user interface bits in a
> common driver, away from the hardware specific parts.
>
> If you see anything in the user interface that directly depends on
> the Xillybus IP block, then that would make the approach impossible
> and we should change that to be more generic.
>    

The whole idea about Xillybus was not to invent a new user space 
interface. A lot of effort has been put in to make the device files 
behave like named pipes. For example, it makes perfect sense to go

$ cat mydata > /dev/xillybus_my_data_sink

knowing that the data will arrive as one would expect to the FPGA.

On my next patch submission, I'll include a documentation file, which 
will describe the fine details. But don't expect much on the API side: 
All of the configuration is already done on the hardware (FPGA) side, 
and the driver merely detects the pipes and their attributes.

All that is left for the user space programmer is to exercise common 
UNIX programming practices, and things will work as expected. Or at 
least, this is the intention.

    Eli

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