RE: another testmgr question

[Pascal Van Leeuwen <pvanleeuwen@insidesecure.com>]

> As I explained before, what appears synchronous to a single userland
> process may look very differently from the OS and h/w perspective. But
> of course, I take your point that h/w is not faster than the CPU in
> the general case, and so care must be taken.
>
"Synchronous" in this context was referring to a use case where the
application does a request and then *waits* for the result of that
request before continuing.
While "asynchronous" would refer to a case where the application fires
off a request and then merrily goes off doing "other" things (which
could be, but is not limited to, preparing and posting new requests).

So I'm strictly viewing it from the applications' perspective here.

> This is made worse by the priority scheme, which does not really
> convery information like this.
>
Yes, the priority scheme is far too simplistic to cover all details
regarding hardware acceleration. Which why we probably shouldn't use
it to select hardware drivers at all.

> > But then again that would still be too simplistic to select to best
> > driver under all possible circumstances ... so why even bother.
> >
> > > flag for that. But even if that does happen, it doesn't mean you can
> > > stop caring about zero length inputs :-)
> > >
> > If the selection of the hardware driver becomes explicit and not
> > automatic, you could argue for a case where the driver does NOT have
> > to implement all dark corners of the API. As, as a hardware vendor,
> > we could simply recommend NOT to use it for application XYZ  because
> > it does things - like zero length messages - we don't support.
> >
>
> Spoken like a true h/w guy :-)
>
Guilty as charged. I AM a true H/W guy and not a software engineer at all.
But have you ever stopped to wonder WHY all hardware guys talk like that?
Maybe, just maybe, they have a damn good reason to do so ...

> Our crypto s/w stack and the storage, networking and other subsystems
> that are layered on top of it are complex enough that we shouldn't try
> to cater for non-compliant hardware. This is why you need to fix this
> in your driver: to prevent the issue from leaking into other layers,
> making it even more difficult to do testing and validation.
>
Now where am I suggesting that applications should cater for non-compliant
hardware? I'm simply suggesting that you should NOT use the hardware for
such an application at all. If you make it explicit, you can do that.

And besides, who decides what is "compliant" and what the rules are?
Please keep in mind that existing hardware cannot be changed. So why
wasn't the API designed around the limitations of *existing* hardware?
It can take several years for a hardware fix to reach the end user ...

As for testing and validation: if the selection is explicit, then the
responsibility for the testing and validation can move to the HW vendor.

Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Inside Secure
www.insidesecure.com