On Fri, Jan 22, 2016 at 10:09:16AM -0500, Stefan Berger wrote: > Ok, so I guess the ioctl would take the PID of the created child as a > parameter (how else to identify it?). The kernel would find that child, > check that the calling parent is indeed the parent of the child, and if > everything looks good do the hook-up.
That is one choice, it is worth reviewing what, eg, the net folks did for their API. They have already thought about this alot. > >Right, controlfd implies that only vtpms could be shared to a IMA > >namespace, which is a terrible API. This is another reason why > >reserved is a terrible API. > > Thanks for all feedback. I will eventually post v2. For now it's to be found > here: > > https://github.com/stefanberger/linux > > The branch is easy to find. That looks much nicer, yes. I'd also merge the tpm-vtpm.h into the .c file However, I'm still not sure this is right: + vtpm_dev->chip = tpmm_chip_alloc(&vtpm_dev->dev, &vtpm_tpm_ops); The only issue is error unwind, the tpmm version assumes devm works for that, but the vtpm_dev will not be destroyed if the tpm attach fails, do devm is not appropriate. As I said before the tpmm stuff was a hack I did to make it easier to migrate the large number of drivers, core code should not be relying on devm like that... One good option here would be unwind that a bit and create a tpm_chip_alloc/tpm_chip_register flow that did not use devm at all. That could be fairly straight forward.. Also, what is up with the _vtpm prefix on some functions? That doesn't seem aligned with the kernel style.. And confused why there is a miscdev and a alloc_chrdev_region ? Jason ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ tpmdd-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
