Re: [PATCH v7 1/3] sysfs: added sysfs_link_entry_to_kobj()

[Jarkko Sakkinen]

On Mon, Jun 22, 2015 at 02:01:54PM -0400, Tejun Heo wrote:
> On Mon, Jun 22, 2015 at 11:52:53AM -0600, Jason Gunthorpe wrote:
> > On Mon, Jun 22, 2015 at 01:30:39PM -0400, Tejun Heo wrote:
> > > On Mon, Jun 22, 2015 at 08:24:50PM +0300, Jarkko Sakkinen wrote:
> > > > Added a new function sysfs_link_group_to_kobj() that adds a symlink
> > > > from attribute or group to a kobject. Exported kernfs_remove_by_name_ns
> > > > in order to provide a way to remove such symlinks.
> > > > 
> > > > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@xxxxxxxxxxxxxxx>
> > > 
> > > Hmmm... is this *really* necessary?  If linking from the parent kobj
> > > doesn't make a fundamental functional difference, I don't think this
> > > is a good idea.  If linking to the parent doesn't work, why doesn't
> > > it?  Shouldn't that already be a different kobj then?  I'd really like
> > > to keep groups as a dumb container of simple attrs.
> > 
> > TPM is undergoing a migration of core attributes from the
> > platform_device to the core's struct device.
> > 
> > The only purpose of the symlink was to provide userspace
> > compatability with the old location.
> 
> Ah, yeah, that's painful.  Can you please briefly explain why it
> wasn't necessary before?  Are you merging multiple devices into one?

I've been working on for a while on TPM 2.0 protocol support and wanted
to do things right from the beginning for TPM 2.0 level devices.

The first thing was to introduce a device class for TPM devices (both
1.x and 2.0), which I did when the baseline support for TPM 2.0 landed
in 4.0.

The second is to introduce *necessary* sysfs attributes in the correct
place so that they are created and destroyed race free. All sysfs
attributes for TPM 1.x devices have been placed in the pdev directory.

For major part of the attributes I decided not to add them at all for
TPM 2.0 devices because they break all the conventions suggested in
sysfs-rules.txt and more importantly you can acquire the data that they
contain by using /dev/tpm0 and TPM protocol (either 1.x or 2.0).

The PPI interface is necessary because it is used to take the ownership
of the device. The solution that I'm presenting in this patch set is
something that I just considered "least harm" when considering backwards
compatibility and raciness.

> Thanks.
> 
> -- 
> tejun

/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/