> Right, that is what I was thinking, although for the power adapter case > I was thinking there are not so much variants so we can just do > a couple of fixed strings for the combos, or maybe just sat that > the adapter does not delivers enough power and that at minimum X watts > is necessary" then we only have 1 variable and we can probably easily > do fixed strings for the few cases of X. I would rather have a generic fixed string or fixed strings with a single than an array. But the problem then is that the numbers are not discoverable from anywhere and would need to be hardcoded. So in that regard I think generic fixed strings is the only way this can work. > > Or we could get fancy and do some generic notification mechanism outside > of printk/dmesg where we push a format string + parameters to the format > string to userspace. So that the translation can be done on the format > string rather then on the end result. I'm not sure we need to make things > that complicated though. > > >> So the idea would be that e.g. gnome-shell can listen for these in some > way > >> and then show a notification in its notification mechanism with the > >> message, > >> like how it does for when software updates are available for example. > >> > >> I think we can make this as simple as using the normal printk buffer for > >> this > >> and prefixing the messages with "USER NOTIFY", we already have some > >> messages > >> in the kernel which would qualify for this, e.g. in the USB core we > have: > >> > >> dev_info(&udev->dev, "not running at top speed; " > >> "connect to a high speed hub\n"); > >> > >> This one is about USB1 vs USB2 ports, but we have a similar one > somewhere > >> for USB2 vs USB3 ports (I think) which would also be an interesting > message > >> to actually show to the user inside the desktop environment. > >> > >> So sticking with the above example, we could change that to > >> > >> #define USER_NOTIFY "USER NOTIFY: " > >> > >> dev_info(&udev->dev, USER_NOTIFY "not running at top speed; connect to a > >> high speed hub\n"); > >> > >> And then userspace would trigger on the "USER NOTIFY: " part, keep the > >> bit before it (which describes the device) as is, try to translate > >> the text after it and then combine the text before it + the possibly > >> translated text after it and show that as a notification. > >> > >> The reason for (ab)using the printk ring-buffer for this is that > >> we will still want to have these messages in dmesg too anyways, > >> so why add a new mechanism and send the same message twice if > >> we can just tag the messages inside the printk ring-buffer ? > >> > >> Note the dev_info above would likely be replaced with some new > >> helper which also does some magic to help with gathering a > >> list of strings to translate. > >> > >> Again just thinking out loud here. If anyone has any initial > >> reaction to this please let me know... > >> > > > > As a general comment, I think it captures very well the possibility > > that the kernel has more information than userspace about the > circumstances > > of something that a user should be notified. Definitely that's the > > case for these WMI/ACPI events, and I would think similar circumstances > > can apply to other subsystem too. > > Right, that was my idea behind having a generic notification mechanism. > > Regards, > > Hans
