Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1238538
| From | Maciek Borzecki <maciek.borzecki@gmail.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v2 1/3] leds: add device activity LED triggers |
| Date | 2015-10-02 21:10 +0200 |
| Message-ID | <qfdSq-3Vb-23@gated-at.bofh.it> (permalink) |
| References | <qeMIx-6KV-5@gated-at.bofh.it> <qeMIx-6KV-3@gated-at.bofh.it> <qeNlh-7wZ-29@gated-at.bofh.it> <qf3gm-5mM-11@gated-at.bofh.it> <qfc0h-1bK-1@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[PATCH v2 1/3] leds: add device activity LED triggers Maciek Borzecki <maciek.borzecki@gmail.com> - 2015-10-01 16:10 +0200
Re: [PATCH v2 1/3] leds: add device activity LED triggers Josh Cartwright <joshc@ni.com> - 2015-10-01 16:50 +0200
Re: [PATCH v2 1/3] leds: add device activity LED triggers Maciek Borzecki <maciek.borzecki@gmail.com> - 2015-10-02 09:50 +0200
Re: [PATCH v2 1/3] leds: add device activity LED triggers Josh Cartwright <joshc@ni.com> - 2015-10-02 19:10 +0200
Re: [PATCH v2 1/3] leds: add device activity LED triggers Maciek Borzecki <maciek.borzecki@gmail.com> - 2015-10-02 21:10 +0200
csiph-web