On 07/19/2018 11:47 AM, James Bottomley wrote: > On Thu, 2018-07-19 at 10:54 -0700, Tadeusz Struk wrote: >> On 07/19/2018 10:19 AM, James Bottomley wrote: >>> That's just an implementation, though, what's the use case? >> >> Hi James, >> The use case is described in the TCTI spec [1] in the >> "3.2.5.2 receive" section. > > Well, yes, but I think we've all agreed that the /dev/tpm and > /dev/tpmrmX aren't TCTI interfaces, although you can layer TCTI on top > of them, so why not simply do fragmentation on top if you need it? > > The reason for not doing it in the interface is that it alters the ABI. > Before this patch we had a hard packet boundary: one packet per read, > one per write and a -EFAULT if you fail to provide a correctly sized > buffer. Now if you provide a buffer too small but don't know about the > fragmentation you're going to misprocess a packet (because you think > you got a whole reply but you didn't) and then you get a -EBUSY on your > next command which you don't know how to handle. The only way out is > to update the applications to handle the new behaviour, which is a no- > no in Linux ABI terms. Don't all the existing applications that read a response in one go do a 4K read now? So nothing will change for them. They will work exactly the same with this change as they do without it. This doesn't break the ABI. > > It might be possible to layer the behaviour you want compatibly into > the current device structure (say an ioctl to switch to the fragment > behaviour) but I've got to ask why we'd go to the complexity without a > use case? New IOCTL would add extra complexity, which isn't necessary. Thanks, -- Tadeusz
