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
