On Wed, Feb 11, 2009 at 04:56:35PM -0700, Matthew Wilcox wrote:
> So a struct device_attribute is defined thus:
>
> struct device_attribute {
> struct attribute attr;
> ssize_t (*show)(struct device *dev, struct device_attribute *attr,
> char *buf);
> ssize_t (*store)(struct device *dev, struct device_attribute *attr,
> const char *buf, size_t count);
> };
>
> and a struct attribute so:
>
> struct attribute {
> const char *name;
> struct module *owner;
> mode_t mode;
> };
>
> so, on 64-bit, that's 40 bytes, plus the 16 bytes for the filename,
> an extra 56 bytes for msi_desc. That's basically doubling the size of
> msi_desc (while I'd much rather shrink it).
Is 56 bytes a big deal? How many attributes are we talking about here?
And on what size machine?
> So I have a counter-proposal. It's a bit of work though.
>
> If we give sysfs_dir_operations an open and a release method, we could
> construct directories on the fly. I don't think we'd want to do this
> for all sysfs directories necessarily, but for special cases like this
> where we have a large number of files, know there can't be duplicates,
> and can construct the files in the directory very quickly, I think it
> could be a big win.
I don't think it's worth the complexity, but feel free to prove me wrong
with a patch that shows otherwise :)
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
