linux-kernel - Re: [PATCH v2] char: xillybus: Add driver for XillyUSB (Xillybus variant for USB)

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] [day] [month] [year] [list]

Date:   Mon, 1 Feb 2021 17:04:56 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Eli Billauer <eli.billauer@...il.com>
Cc:     arnd@...db.de, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] char: xillybus: Add driver for XillyUSB (Xillybus
 variant for USB)

On Mon, Feb 01, 2021 at 05:56:38PM +0200, Eli Billauer wrote:
> Hello, Greg.
> 
> On 01/02/21 16:25, Greg KH wrote:
> > As this has nothing to do with the existing XillyBus code, and you
> > aren't doing anything "fancy" with the character device nodes, why does
> > this need to be a kernel driver at all?  Why can't you just use libusb
> > and talk to the device directly from userspace with no kernel driver
> > needed?
> That's actually what I did in my first attempt.
> 
> However in order to provide the same API as the existing Xillybus driver,
> this driver must present some kind of device files.

But you are not providing the same API!  Or so you are saying in the
driver.

If you were, then you need to use the same device nodes that the
existing xillybus code uses and share them.  Which is what I asked about
before.

> Named pipes aren't sufficient, among others because closing a Xillybus
> device file is something that the hardware is informed about immediately.
> Also, when a device file is opened for write, the close() call should not
> return until all data has arrived to hardware (per existing API). This can't
> be guaranteed with named pipes.

What does a named pipe have to do with anything here?

> So a user-space driver needs to rely on CUSE. Which I wasted two months on
> before realizing it's not stable enough to rely upon. My whines on CUSE can
> be found in my blog:

Why is cuse an issue here?

Just use libusb and have your userspace programs link against it.

thanks,

greg k-h