What's tha KOBJ_MAX action used for?
Hi all, I was wondering, what the KOBJ_MAX action in the kobject.h file does. It is self explainatory what KOBJ_ADD, KOBJ_REMOVE etc. are used for, but KOBJ_MAX puzzles me. On top of that, it is never referenced somewhere in the sourcecode (https://elixir.bootlin.com/linux/v5.7.8/C/ident/KOBJ_MAX). Can it maybe even be removed? Regards, Garrit Franke
On Mon, Jul 13, 2020 at 01:17:25PM +0200, Garrit Franke wrote:
Hi all,
I was wondering, what the KOBJ_MAX action in the kobject.h file does. It is self explainatory what KOBJ_ADD, KOBJ_REMOVE etc. are used for, but KOBJ_MAX puzzles me.
On top of that, it is never referenced somewhere in the sourcecode (https://elixir.bootlin.com/linux/v5.7.8/C/ident/KOBJ_MAX).
Can it maybe even be removed?
Maybe it can, try it and see! greg k-h
On Mon, 13 Jul 2020 14:35:23 +0200, Greg KH said:
On Mon, Jul 13, 2020 at 01:17:25PM +0200, Garrit Franke wrote:
Hi all,
I was wondering, what the KOBJ_MAX action in the kobject.h file does. It is self explainatory what KOBJ_ADD, KOBJ_REMOVE etc. are used for, but KOBJ_MAX puzzles me.
Can it maybe even be removed?
Maybe it can, try it and see!
I suspect that this line: for (action = 0; action < ARRAY_SIZE(kobject_actions); action++) { in lib/kobject_uenvent.c:kobject_action_type() combined with the fact that kobject_actions[] does *not* actually match the enum regardless of the comment above it, result in it being superfluous. Figuring out why is left as an exercise for the student. Oh, and if I had a dollar for every time I've been surprised by creative abuse of the cpp ## operator... :)
Thanks for your replies. Also, thanks greg for your thorough review on my corresponding patch (https://lkml.org/lkml/2020/7/14/84), I learned a lot! I have been digging around about Kobjects a bit. They are nicely documented. Still, no documentation exists about this KOBJ_MAX action. This post on stackoverflow mentions that it's a "special" field that marks the end of the enum (if I understand correctly): https://stackoverflow.com/a/23149574/9046809 This lead me to think that this is a convention I'm not aware of, but I could not find any resources that described such a thing, so I discarded that idea. If I understand correctly, this action can in fact be passed to userspace by the kobject_uevent function, so it would be a bad idea to remove it. Is my reasoning correct? regards, Garrit Am Di., 14. Juli 2020 um 04:15 Uhr schrieb Valdis Klētnieks <valdis.kletnieks@vt.edu>:
On Mon, 13 Jul 2020 14:35:23 +0200, Greg KH said:
On Mon, Jul 13, 2020 at 01:17:25PM +0200, Garrit Franke wrote:
Hi all,
I was wondering, what the KOBJ_MAX action in the kobject.h file does. It is self explainatory what KOBJ_ADD, KOBJ_REMOVE etc. are used for, but KOBJ_MAX puzzles me.
Can it maybe even be removed?
Maybe it can, try it and see!
I suspect that this line: for (action = 0; action < ARRAY_SIZE(kobject_actions); action++) { in lib/kobject_uenvent.c:kobject_action_type() combined with the fact that kobject_actions[] does *not* actually match the enum regardless of the comment above it, result in it being superfluous.
Figuring out why is left as an exercise for the student.
Oh, and if I had a dollar for every time I've been surprised by creative abuse of the cpp ## operator... :)
A: http://en.wikipedia.org/wiki/Top_post Q: Were do I find info about this thing called top-posting? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Tue, Jul 14, 2020 at 04:36:15PM +0200, Garrit Franke wrote:
Thanks for your replies. Also, thanks greg for your thorough review on my corresponding patch (https://lkml.org/lkml/2020/7/14/84), I learned a lot!
I have been digging around about Kobjects a bit. They are nicely documented. Still, no documentation exists about this KOBJ_MAX action.
Please look at commit 60a96a59569b ("Driver core: accept all valid action-strings in uevent-trigger") in the tree. That's when it was added, and it was used. Then a short bit later, 5c5daf657cb5 ("Driver core: exclude kobject_uevent.c for !CONFIG_HOTPLUG") stopped using it in the .c files, and no one noticed that it should have been removed.
This post on stackoverflow mentions that it's a "special" field that marks the end of the enum (if I understand correctly): https://stackoverflow.com/a/23149574/9046809 This lead me to think that this is a convention I'm not aware of, but I could not find any resources that described such a thing, so I discarded that idea.
If I understand correctly, this action can in fact be passed to userspace by the kobject_uevent function, so it would be a bad idea to remove it. Is my reasoning correct?
Yes, if it did get passed to userspace. But it doesn't, as you can see by the last commit I referenced above. We pass strings to userspace for the kobject events and we take that same string sent to us from userspace to send "fake" kobject uevents as well. Also, the loop that we checked for KOBJ_MAX is no longer present, we do a much more sane ARRAY_SIZE() check, right? So I don't think it's needed. Can you rewrite your changelog text with all of this new information and resend it? I'll be glad to take the patch then. thanks, greg k-h
participants (3)
-
Garrit Franke -
Greg KH -
Valdis Klētnieks