On Wed, Jan 11, 2017 at 10:25:57AM -0800, James Bottomley wrote: > Right, but we're going around in circles. I'm currently researching > what it would take to be daemonless, so an ioctl which requires an > access broker daemon would obviously be something I'd object to.
Well, when we figure out a security model that works for that and can be implemented in the kernel then lets add the new cdev. But that is *explicitly* not what Jarkko is doing, no reason to jump the gun. > Basically, though, I think you can do both: we can add an ioctl and the > differing device hooks. I just think for that case RAW vs RM would be > redundant. Right, some future new cdev would only support ioctl and only the RM path, but for priv use having both concurrently available makes sense as a userspace broker producing a full RM will need to using both paths. Jason ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ tpmdd-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
