Mike: On Sat, Feb 12, 2011 at 10:41 PM, Mike Frysinger <vapier.adi@xxxxxxxxx> wrote: > On Sat, Feb 12, 2011 at 23:28, Bill Gatliff wrote: >> On Sat, Feb 12, 2011 at 8:53 PM, Mike Frysinger wrote: >>> document the module name in the help ? >> >> Not sure what you are asking. Like this? > > yes, but it seems to be more common to use a style like so: Ok. Will do. > it just means the pwm framework needs to be constified in the core code first :) Actually, the pwm framework is aggressively constified (though your suggestion has shown me one place I missed, and there are probably others). The complaints I can't help are the ones that come from configfs! > > hmm, i thought the configfs integration did more than just call the > create/destroy funcs. considering the common gpio code has sysfs > hooks for playing with gpios from userspace, perhaps there should be a > sysfs hook here too rather than requiring configfs ... The root issue is how to tell the kernel to create a new pseudo-device without kernel code. Gpiolib accomplishes that by the "export" attribute. I'm achieving the same thing, only with configfs. Configfs was designed explicitly for doing such things. The gpiolib approach, while it obviously works, is somewhat an abuse of sysfs as I see things. Sysfs is supposed to merely reflect the state of the kernel's internal device model. Ggpiolib modifies that model state as a side-effect of writing to an attribute. That seems wrong, no matter how well it works. I'll agree that the gpiolib approach works, and that there aren't many kernel users of configfs. Maybe my selection of configfs instead of a sysfs export attribute is a feeble attempt to change that... :) b.g. -- Bill Gatliff bgat@xxxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
