> > 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? > Some people did volunteer about a month ago but I haven't heard from any of them since ... which means my fixes won't make it into any kernel trees any day soon. > 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) > You keep missing my point though ... I was not suggesting teaching upper layers about zero lengths or any other hardware limitations. My point is that the overal majory of the "upper layers" are known not to need zero lengths or any of these other corner cases and our driver/ hardware doesn't really care about supporting the ones that do, because those "upper layers" would not benefit from our driver/hardware anyway. You know, all I *really* care about at this point is *just* supporting the kernel IPsec stack. The rest is just baggage for me anyway. It's all about preventing the "upper layers" from selecting our driver. Which can be arranged very easily. Just set cra_priority to 0 which requires it to be selected explicitly, moving the responsibility to whomever configures the machine. > 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. > We don't *have* to do anything ... this thing is not set in stone as far as I know. We could actually come up with a real compromise, which this is not. It just requires some flexibility of mind and some good will ... Regards, Pascal van Leeuwen Silicon IP Architect, Multi-Protocol Engines www.insidesecure.com
