Hi Muthu, On Mon, Jul 16 2012, Muthu Kumar wrote: > On Sun, Jul 15, 2012 at 7:46 PM, Chris Ball <c...@laptop.org> 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. > > So, what is the plan for fixing the user land tools and cleaning this up?
At the moment I don't have any plan to do that, because the cure (potentially breaking userland scripts that are writing to some read/write attributes, by breaking ABI to move everything into a new directory) seems worse than the disease (having some attributes in a directory that isn't the ideal one). I'd be willing to explore something like Venkat's idea if the block layer maintainers insist, though. - Chris. -- Chris Ball <c...@laptop.org> <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/