On Mon, 27 May 2019 at 14:41, Pascal Van Leeuwen <pvanleeuwen@xxxxxxxxxxxxxxxx> wrote: > > > And if you go that naive route, just fix everything in the driver, then > > you simply end up with something terribly inefficient because all those > > corner case checks end up in the fast path and eating up code space. > > > One thing I forgot to mention here that should especially interest you: > you add a lot of complexity to the *driver* that needs to verified and > maintained (by the kernel community?!). Some of these workarounds I had to > implement are really quite a convoluted mess and it's starting to take up > a significant portion of the driver's code base as well ... just to support > some fringe cases that are not even relevant to the hardware's main use > cases (as "we" as the "hardware vendor" see it) at all. > > Note that I actually *have* implemented all these workarounds and my > driver is fully passing all fuzzing tests etc. I'm just not happy with it. > Good, glad to hear that. I would test it myself if my MacchiatoBin hadn't self combusted recently (for the second time!) but there are some others that volunteered IIUC? I think nobody is happy that we are adding code like that to the kernel, but it seems we will have to agree to disagree on the alternatives, since teaching the upper layers about zero length inputs being special cases is simply not acceptable (and it would result in those workarounds to be added to generic code where it would be affecting everyone instead of only the users of your IP) But I fully understand that dealing with this case in hardware is not feasible either, and so this approach is what we will have to live with.
