I would like to know what callback gets called in Linux device drivers when issuing poweroff from user space. The driver is built as external module.
For suspend / resume we have struct dev_pm_ops methods.
Is there any method/callback that could be registered for getting called when issuing poweroff/shutdown command from user space?
Related
I am trying to talk to a MSC USB device (interface class 8, subclass 6, protocol 0x50) via a plain USB API with endpoints (all set up for me).
Provided I have a valid CDB, such as for "Test Unit Ready", how to I send that over the USB interface?
Where can I find examples or docs for how this is done?
Background: The actual platform is macOS, which doesn't provide SCSI-passthrough for block devices, and the native SCSI API is also not available in this case.
I have, however, been able to initiate communication on the USB level with the device, and am now trying to circumvent the blocked SCSI device level access by talking thru USB directly.
Most such devices implement the so-called “Bulk Only” protocol, which is specified here: https://usb.org/document-library/mass-storage-bulk-only-10
Essentially, you send a 31-byte “Command Block Wrapper”, which includes the CDB and is specified in section 5.1 of the spec, to the device via the bulk out endpoint. You then read or write the data to be transferred from the input bulk endpoint or to the output bulk endpoint and finally read the 13-byte command status wrapper from the bulk in pipe.
However, note that you’ll need to make sure the OS hasn’t already loaded a driver for the device - from user space, the system won’t give you access to the endpoints when a kernel driver has claimed them anyway, but if you were to attempt to use the same pipes as the default driver from a kext, you’d get unpredictable results.
Recently I was Trying to work with Qualcomm platform device. I was looking at Flow of touchscreen hbtp_input device driver, the driver is getting registered and calling init function but it doesn't call probe function.Does drivers work without probe functions?
I have a device driver with misc_register() API being called to create a serial device. Now, I want to call misc_deregister() because the device does not function any more due to hardware change (for example removal of cable of the serial port). Now the application has opened this device and performing operations on it, so there is an open file descriptor for this device.
I want to know if the driver wait for the application to call release (or close() API) on the device before calling misc_deregister()? Or can the driver call misc_deregister() and then it can still receive a (last) release callback?
In my kernel extension I am currently supporting, I communicate with user spaces using sockets. So, I subscribe to some callbacks and correctly process them
reg.ctl_send = ctl_handle_send;
reg.ctl_getopt = ctl_handle_getopt;
reg.ctl_setopt = ctl_handle_setopt;
reg.ctl_connect = ctl_handle_connect;
reg.ctl_disconnect = ctl_handle_disconnect;
Everything works as expected. Only one problem - I can not unload my kernel extension if there are user space clients that are connected (ctl_deregister(kctlref) returns errors)
Is there a way to override it in kernel extension? I would like to disconnect from ALL clients and successfully unregister myself
How do I control the network interface on Windows? Actually, the idea is quiet simple.
Establish connect to a certain adapter on a computer.
Direct whole traffic of the adapter to this program.
Give the rights to this program what must be transfer to the adapter and what should not.
I think the program has to implement any windows network adapter interface and be registered as an adapter driver. Thus, when it wants to transfer data to real adapter, the program has to call adapter driver methods. In their turn, the methods implement the same windows network interface (or that is called in other way don't really know, I hope you get the sense), don't they?
As a result, we have a kind of inheritance here.
Before use our new driver:
windows application and windows itself
________________________ windows network interface
DRIVER of Adapter1
________________________ end of OS boundaries
Adapter 1
Use our new driver:
windows application and windows itself
________________________ windows network interface
our DRIVER
________________________ windows network interface
DRIVER of Adapter1
________________________ end of OS boundaries
Adapter 1
I believe that kind of interface exists and I hope it is realized very easy.
You will likely need to hook Windows API calls to really do this. It is possible... Start by Googling hook API and Winternals - and see if you can find their sample code.
Before Winternals was bought by Microsoft they published their code. http://technet.microsoft.com/en-us/sysinternals/bb545021
The idea is this:
You write a user-mode program which controls your hooking device
driver.
Your hooking device driver determines if network traffic on
given API calls is ok.
Driver allows normal API calls to succeed if they are.