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.)
Related
So I want to build a kernel module (I suppose) which would insert little delay after a keyboard key is pressed (let's say 500ms). I managed to do this in Windows through hooks, but it seems to be different in Linux. Note that I do not wish to use x11 methods, as I want it to also work from the linux console (even if there is no X server running). From what I was able to understand, it would require to build a kernel module and insert it dynamically into the kernel with insmod. I managed to build a key logger which would dump each pressed key to the kernel log, but inserting a delay would require sending the thread that handles the keyboard interrupt handler to sleep, which is a very bad idea, and also to rewrite the entire USB_KBD driver, because the current script calls the request_irq function with the IRQF_SHARED flag set, so I guess the original driver still does its job before executing my function.
I am currently requesting an interrupt handler like this
request_irq (1, (irq_handler_t) irq_handler, IRQF_SHARED, "keyboard_stats_irq", (void *)(irq_handler));
Any suggestions on how to handle this (any other way) ?
You can write a user space daemon that reads the input events from /dev/input/input* (whatever the keyboard device is), while grabbing the device to block the events to go through the rest of the system (ioctl(fd, EVIOCGRAB, 1)).
Then, the daemon can create a virtual input device, using /dev/uinput and write the input events there after some delay. Since the delay will be implemented in user-space, that will be quite easy.
Starting your daemon will be equivalent to hot-plugging a virtual keyboard, and modern X servers (less than 10 years?) are able to cope with hot-plugged input devices. And the vconsole driver works fine too with those.
Currently, I am able to hook onto Direct3D application and draw custom stuff onto its surface. However, I would like to suspend this application and then draw something else.
Is this even remotely possible to do so? Like creating another my own Direct3D window on top of that application?
I'm targetting only Windows 7, but the application I want to draw on is using only DirectX 9.
The problem is that I have very little experience with DirectX in general.
Sort of.
You're working with two different elements here, one quite large and but not particularly complex: hooking D3D. The other ("suspending" the app) is simple within that, but you don't quite want what you think you want.
To hook D3D, by the simplest method, you need to intercept the call to CreateDirect3D9 and return your own IDirect3D9, which later creates and returns your own IDirect3DDevice9. This will give you full control over the app's render process.
In order to "suspend" it, you need to wait for the desired trigger, then in your IDirect3DDevice9::Present, call your own event loop. This will, for all intents and purposes, suspend execution of the original app's code, but not the process itself (allowing your code and event loop to process). There will be some limitations of this, and you may not be able to consume window/Windows events (simply), but it will give you full control and effectively pause the original app.
Note, however, that you must intercept and reroute execution in every thread you want to "suspend," it's only specific to a single thread and you don't want physics or AI crunching on while render and UI are paused.
You need to perform your overlay drawing, whatever that may be, during your loop or your IDirect3DDevice9::Present hook, then call the real device's Present method as needed. If you want to run multiple frames of your overlay, then call the real Present repeatedly before returning from your Present. Tweak as necessary. Rendering here is done pretty much normally (check out general D3D tutorials for that), but there is one major catch: the device's state is unknown and may be incompatible, but must be "untouched" on return. This is handled simply by caching an IDirect3DStateBlock9 created from the device immediately after creating it. In your Present hook, create another state block with the state on entrance, restore the clean state block, run your code, then restore the entrance state block. You can work with any states, off a fresh slate, without damaging the device's state (I use this in practice, in works great).
If you want some rather extensive examples of how this works, I'd suggest checking out the Voodoo Shader project, which has full D3D8 and 9 hooks, including everything needed for overlays [/shameless own-project promotion]. Feel free to reuse any of the concepts, or comment with further questions; this certainly isn't all the details that may be useful to you.
This is a very complex thing to accomplish, as it is very much a hack to do so. The only people you see doing such things are steam, teamspeak, xfire, fraps, and a few hard-core devs.
There are kits out on the internet that show you have to inject a DLL into the memory space of the target application to achieve such a feat, and methods such as proxy DLLs.
Proxy DLL:
http://www.codeguru.com/cpp/g-m/directx/directx8/article.php/c11453
Injection:
http://www.progamercity.net/d3d/372-c-directx9-0-hooking-via-detours.html
Good luck, this will take you a while.
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...
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.