On 10/02 12:08, Josh Cartwright wrote: <snip> > > Hmm, maybe we're bikeshedding at this point, but LEDs with those names > seem much more straightfoward to me than a "dev-<maj>:<min>" name, for > devices which have done dynamic dev_t allocation. > > > Also, if I'm not mistaken, using this approach the partitions on MMC > > card or SATA drive would end up with the same trigger name, as it is a > > single device. > > This would only be true if you used _just_ the struct device. I was > imagining that you'd specify a (struct device, unsigned index) pair. > Better, you could do a (struct device, const char *) pair. > > Also, from a lifetime management perspective, it starts to feel like > something that might integrate better as a managed resource (devm_*). > > [..] > > Multiple dev nodes will already have different minor numbers, so > > their dev_t is different anyway. > > Okay, backing up I don't really see what this API really buys the > consumer. The dev_t -> struct led_trigger mapping just seems like a > total waste. Why not just make your ledtrig_dev_add() function return > the struct led_trigger * that the consumer keeps track of? > > Maybe seeing an example consumer would provide some clarification. > > > As for devices that do not have a dev_t assigned to them one can still > > pass a custom tag in ledtrig_dev_add(). It's just a number so as long as > > there's no collision in numbering things should be fine. > > Ensuring no collision will be difficult, especially given that it's most > common that the dynamic allocator is used. In order to guarantee no > collisions, a user who doesn't expose any device nodes would need to do > their own dev_t allocation...to use this interface. And that seems > silly to me. Thanks, I really appreciate your feedback. -- Maciek Borzecki -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
