On Mon, Jul 16, 2012 at 8:16 AM, Chris Ball <cjb@xxxxxxxxxx> wrote: > Hi, > > On Sun, Jul 15 2012, Muthu Kumar wrote: >>> I've already replied to a later version of the patch, but just to get >>> this comment in at the appropriate point of the discussion as well: >>> >>> Even though it would result in a cleaner sysfs, I don't want to do >>> this now because it will break userspace scripts that are depending >>> on the current locations of these attributes. >> >> Maya is adding a new sysfs attribute with that patch. So, there should >> not be any user space stuff that depends on it. > > In the later patchset, Maya's "[PATCH v4 1/2] mmc: card: Move MMC > specific attributes to mmc sub-directory" moves the existing attributes > into the mmc/ directory. > > It's that move that I'm objecting to, rather than the creation of a new > directory -- although since we're going to leave the current attributes > where they are, it might not make sense to add the new directory. > > We'd be creating two places that people have to look for mmc-related > attributes, which is arguably less clean than having one place to look > even though it's mixed in with the other block device attributes. > It's better to normalise this eventually. It would be better if we create a duplicate sysfs entry within MMC, which is identical to the current block layer attribute. Then schedule the block layer attribute to be removed by, say, 3.9. [Add it to Documentation/feature-removal-schedule.txt] Since it is a MMC specific attribute, generic tools wouldn't depend on it. -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html