[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <601824B6.60803@gmail.com>
Date: Mon, 01 Feb 2021 17:56:38 +0200
From: Eli Billauer <eli.billauer@...il.com>
To: Greg KH <gregkh@...uxfoundation.org>
CC: arnd@...db.de, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] char: xillybus: Add driver for XillyUSB (Xillybus
variant for USB)
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.
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.
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:
http://billauer.co.il/blog/2020/02/linux-cuse-fuse-libfuse-crash/
> And always cc:linux-usb@...r.kernel.org when submitting a USB driver so
> that the developers there can review it.
>
Sorry, I wasn't aware of that. Will resend this patch with this list
cc'ed shortly.
Thanks,
Eli
Powered by blists - more mailing lists