uevents has been sent from kernel space to user space through netlink socket.
In kernel, there must be something trigger uevent.
I guess there are two possibilities:
Hardware interrupt - this means, once hardware interruption happened, kernel sends event to user space to signal that there is some events happened.
software polling - this means, there is always a daemon to check these file system to see if there is anything changed. If so, then update these info to upper layer.
Could anyone provide your feedback?
Thanks
I can't agree with you about polling. uevent is event-based, so there is no polling.
Triggering uevent happened in many cases and I would rather start with figuring out what uevent types are exist?
Little searching and here you go - in include/linux/kobject.h
enum kobject_action {
KOBJ_ADD,
KOBJ_REMOVE,
KOBJ_CHANGE,
KOBJ_MOVE,
KOBJ_ONLINE,
KOBJ_OFFLINE,
KOBJ_MAX
};
So it's
Add event
Remove event
Change event
Move event
Online event
Offline event
KOBJ_MAX is special and marks and of enum.
There are 2 functions that actually sends uevent - kobject_uevent and kobject_uevent_env. These functions are called with on of the actions listed above.
Finally, to answer your questions. There are no predefined cases that will trigger uevent. If you search for calls of kobject_uevent and kobject_uevent_env you will see that it's happens in various callbacks in different unrelated kernel subsystems.
uevent is kernel facility to unify notifications from various unrelated drivers. So I think there are no well known list of things that will trigger uevent.
Related
I am writing some software to shutdown some external hardware wired into my control board. The catch is that I need to wait for the VERY end of the poweroff operation to send the signal (through a gpio output). I am weighing some options right now, but I am curious as to where I can see what the kernel actually does right before poweroff.
Is there a file somewhere that I can look into?
Start at the function kernel_power_off in kernel/reboot.c and follow the code. The final power-off operations are very platform specific, so if you want to follow down to the bitter end, you'd need to figure out exactly which bits of arch-specific code you're using.
One simpler possibility for sending your signals is to register a kmsg_dump handler. The last thing kernel_power_off does before invoking the platform-specific power-off code is to execute kmsg_dump(KMSG_DUMP_POWEROFF);. (Just ignore any kmsg_dump calls other than that one.)
Is it possible to trap Linux signals (e.g. SIGUSR1) through an handler in Erlang? (without having to resort to a driver crafted in C)
(NOT A REAL ANSWER)
In 2001 someone asked:
Does anyone have any examples of unix
signal handling in erlang. I would
like to make a loadbalancer that I
have written respond to sighup.
At that time the answer was:
There is no provision for handling
signals in Erlang "itself", i.e. you
will need to use a driver - or a port
program of course, might actually be a
better idea. Also for the driver case,
the emulator has its own handler for a
number of signals, and interfering
with that will probably have
"interesting" results - but SIGHUP
should be OK I believe.
SOURCE: http://www.erlang.org/pipermail/erlang-questions/2001-October/003752.html
As far as I know, nothing changed since then. But this is extremely interesting. If anyone has any news about this, please let us know :)
This is possible since Erlang/OTP 20.0, released in June 2017. It was done through this pull request that adds an event manager for signals called erl_signal_server. See the "OS Signal Event Handler" section in the kernel manual page.
If you're interested in SIGUSR1, note that the default handler will make the Erlang VM halt and produce a crash dump. To avoid that, it's not enough to add your own handler to erl_signal_server; you have to swap the default handler for it:
gen_event:swap_handler(erl_signal_server, {erl_signal_handler, []}, {foo, []}).
I'm writing a linux driver and I would like to register a callback function to be invoked when the system goes to sleep. What is the api to do this?
Thanks.
It depends on what kind of driver you have. For example, if you have a driver that is registered with platform_device_register(), then the struct platform_driver includes a .suspend member for the device's suspend callback. With PCI devices, the struct pci_driver that you pass to pci_register_driver() similarly includes a .suspend member.
Most device classes should provide a similar mechanism.
I'm pretty sure you want acpi_install_fixed_event_handler(), found in acpi/acpi.h , the generic events found in acpi/actypes.h (which is included from acpi.h).
The second argument to acpi_install_fixed_event() wants a handler of type u32, with the last argument being a void *context. What I could not find is a list of possibilities that *context might be. However, it looks like you just something to be entered on events, which means you probably don't care about the context. Not quite a callback, but the same result.
If you register a fixed handler for (say, ACPI_EVENT_POWER_BUTTON or ACPI_EVENT_SLEEP_BUTTON), your handler should be entered on the respective event. I'm not 100% sure ACPI_EVENT_SLEEP_BUTTON is what you want, i.e. I can't quite tell if its the same event as the system going to sleep on its own. Testing and further investigation is, of course, and exercise for the reader.
An example of using it can be found in drivers/rtc/rtc-cmos.c.
Please take care to wrap any code from acpi.h in
#ifdef CONFIG_ACPI
....
#endif /* CONFIG_ACPI */
I could be completely wrong here, I have not actually needed to do this for any of the drivers that I've written. The above is the result of about 30 minutes of digging through the source of 2.6.32.8 , which may be completely different than the kernel you are working with.
Please leave a comment if I am way off base :) I think this is what you are looking for.
Additional
As for licensing, its exported:
drivers/acpi/acpica/evxface.c:ACPI_EXPORT_SYMBOL(acpi_install_fixed_event_handler)
Not
*_EXPORT_SYMBOL_GPL()
... So you should have no issues using it, whatever you happen to be doing.
Finally, this is a perfectly good question that would probably be met with a good reception on the Linux Kernel mailing list. If in doubt, ask there. Even if this 'just works', its a good idea to confirm it.
The solution I settled on was using notifier chains. On later versions of the kernel you can register with register_pm_notifier. If your kernel doesn't support that api you can use the notifier for cpu hot-plug events (this appears to be what KVM uses). On the way in and out of suspend the cpu hotplug notifier chain fires.
The ACPI Howto probably will give you a good headstart...
Is there a way to confirm if a Linux Ethernet driver is using the NAPI interface?
I know this sounds like an obvious answer, but check the source to see if the NAPI API is being used.
For example:
In your driver's interrupt handler, does it use any of the calls below?
Does your driver implement a poll() method for the NAPI? If so, see if it uses
netif_receive_skb() instead of netif_rx().
If both of those questions lead to 'YES', the your driver is using NAPI.
Note: The following was copied from here
NAPI API
netif_rx_schedule(dev)
Called by an IRQ handler to schedule a poll for device
netif_rx_schedule_prep(dev)
puts the device in a state ready to be added to the CPU polling list if it is up and running. You can look at this as the first half of netif_rx_schedule(dev).
__netif_rx_schedule(dev)
Add device to the poll list for this CPU; assuming that netif_schedule_prep(dev) has already been called and returned 1
__netif_rx_schedule_prep(dev)
similar to netif_rx_schedule_prep(dev) but no check if device is up, usually not used
netif_rx_reschedule(dev, undo)
Called to reschedule polling for device specifically for some deficient hardware.
netif_rx_complete(dev)
Remove interface from the CPU poll list: it must be in the poll list on current cpu. This primitive is called by dev->poll(), when it completes its work. The device cannot be out of poll list at this call, if it is then clearly it is a BUG().
__netif_rx_complete(dev)
same as netif_rx_complete but called when local interrupts are already disabled.
Check out this wikipedia article and the external links in it for more detailed information.
I hope that helps.
I would like to implement a socket-like object in user space. There's an important requirement that it should be pollable (i.e. it's state should be queryable via select or poll call).
Is there a platform neutral way of implementing such an object?
I'm aware that on Linux there's eventfd which kind of suits the needs except that there's no way to force it to signalize neither POLLIN nor POLLOUT.
You can use socketpair() to create a pair of connected AF_UNIX sockets. This is better than pipe() as it allows for bidirectional communication. If this isn't good enough for your needs, another option (which requires root for a daemon) would be to use the as-yet-not-in-mainline-Linux CUSE patches to create a device driver in userspace to do whatever you like. Or you can just hook into whatever event loop your user will be using...
The new linux eventfd can also emulate POLLIN/POLLOUT, although not both at once - set its value to 0xfffffffffffffffe for POLLIN but not POLLOUT, 0 for POLLOUT but not POLLIN, or anything else for both.
Other than these options, there's no platform-neutral way to do this, no. The usual pattern is to use a FIFO just to wake up the event loop, and have it poll using some other API once it's awake.
You want to build an user space object, that will be accessible through system call ?
ie open, read, write etc ... are redirected to your userspace object ?
You need either kernel support or libc support, otherwise I don't see how you can redirect your system call.
eventfd is not what you are asking for, it is implemented in kernel space. Did you describe your real problem ? Could fifo or unix domain socket fit your need ?
What about pseudo tty ? I don't know if you can block writing from the master side by faking the hardware flow control.
It's really not clear what you're trying to do; if you want a socket-like device, why not use sockets? You don't say ... And what's the deal with POLLIN and POLLOUT?
I kinda suspect you might be interested in using pseudo-terminal devices, see man 7 pty.
Use pipe(). It gives you two fd's, one to write, one to read.
Use the fd[1] to do your select/poll on.
Use the fd[0] to signal your select/poll for activity.