Re: [PATCH] Add attribute container to the generic device model

[James Bottomley]

On Tue, 2005-01-11 at 23:08 -0800, Greg KH wrote:
> But classes could always have an arbitrary number of attributes, right?

Per class, yes.  The SCSI transport classes evolved such that they
simply don't display attributes that are irrelevant to the underlying
device.  Also, not all devices are fully capable, so attributes that are
ro on one HBA are rw on another.  This means that we need the attributes
per class device rather than per class.

> > This will be used as the basis for a generic transport class, but I did
> > it like this in case anyone found the abstraction useful.
> 
> Hm, I like the idea, but we already allow devices belonging to arbitrary
> number of classes (through class_device) today.  What makes this
> different?

The idea is simply to be an attribute container for classes that can't
use the per-class one (because of the needs listed above).

> And how does this change, if at all, sysfs representations of devices
> that use this?
> 
> Some minor comments about the code:
> 
> > +EXPORT_SYMBOL(attribute_container_classdev_to_container);
> 
> Can these all be EXPORT_SYMBOL_GPL?  It's your choice, as you wrote the
> code, but we're trying to keep the driver model stuff all GPL explicit,
> as there's no way someone can say it's a "derived work" from long ago
> that's using these new functions.

Well ... I can, certainly, but that would be window dressing it a bit.
The ultimate end consumer will be SCSI (and other bus) HBA's, not all of
which are GPL available.  However, as long as the HBA APIs exported by
the transport class are non-GPL available, this should all work (and
certainly none of the attribute container APIs are used by HBAs).

> > +/**
> > + * attribute_container_add_device - see if any container is interested in dev
> > + *
> > + * @dev: device to add attributes to
> > + * @fn:	 function to trigger addition of class device.
> > + *
> > + * If no fn is provided, the code will simply register the class
> > + * device via class_device_add.
> 
> You mean the class_device of the "container", right?

Yes, this function actually allocates the container (which contains the
classdev) then calls fn on it (or just does a class_device_add if no
fn).  I'll update the doc.

> The code looks sane, if not a bit confusing as there's no user of it :)

There is now ... you didn't wait long enough ...

James


-
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/