On 1/31/2017 5:55 PM, James Bottomley wrote: > > I can do that, but I think this should be higher than debug. If this > trips, something an application was doing will fail with a non TPM > error and someone may wish to investigate why. Having a kernel message > would help with that (but they won't see it if it's debug). > > I'm also leaning towards the idea that we should actually have one more > _tbl slot than we know the TPM does, so that if someone goes over it's > the TPM that gives them a real TPM out of memory error rather than the > space code returning -ENOMEM.
I endorse this as a general principle. 1 - When a TPM application does something wrong, the developer will be looking for a specific TPM error, not a kernel read() error. Reserve the kernel errors for when something goes wrong in the device driver, not in the application. 2 - As much as possible, the RM should be transparent to the application. The RM should report a failure the same way the SW TPM would fail. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ tpmdd-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
