I am new in Linux and i want to know the internals of drivers and how it is interacting with hardware, so my question is that How the application is interacting with hardware means when the core part will come in picture and what it will do?
When the controller of that driver will come and how it will handle the request generated by the application.
And what is Firmware and when it comes into picture in Linux?
For eg: if i am using usb device like
$ cat /dev/usb0.1
then which is the core of usb(usb_storage.c) and
which is the controller(usb_hub.c)
and how they are related to each other.
Thanks in advance..
Basically linux kernel driver provide interface such as device file node then application can use standard read()/write()/ioctl() to pass parameter to operate hardware. Provide interface in /proc or /sys can be facilities to do that too. Detail implementation how to handle request depends on respective hardware spec.
Related
I have a USB device (actually, a digital camera) that talks the MSC protocol, i.e. it appears as a disk device and can be talked to with SCSI commands. When it's connected to a Mac, the IOBlockStorageDriver takes over and mounts the volume.
Now, my goal is to prevent this from happening, in hopes that I can then talk to the device thru the SCSI interface functions for SCSITaskDeviceInterface, provided in <IOKit/scsi/SCSITaskLib.h>.
Is that possible? The SCSI Architecture Model Device Interface Guide states that the SCSITaskDeviceInterface is only available for types other than $00, $05, $07 and $0E (the MSC device is type 00), but I wonder if that's only because these types are taken over by the Mass Storage driver and therefore are not available. But if I prevent the Mass Storage driver to take over, will these types, such as 00, become available via SCSITaskDeviceInterface?
If that's possible, what must the kext code do to achieve this? E.g, which class should it subclass and which functions must it implement so that it prevents the mass storage driver from taking over while keeping the device visibile as a SCSI device in the io registry?
If that's not possible, could I then instead use the kext to provide a way to offer SCSI-cmd passthrough somehow? I would like to be able to send custom CDBs to this kext from userland, and it should then route them through the SCSI layer to the USB device. Is that possible? Assuming the kext has received a CDB string, how would it locate the SCSI functions for passing the data onward to the USB layer?
I've so far based my unsuccessful tests on Apple's VendorSpecificType00 sample project, which shows how to inject a kext that adds handling custom properties for a SCSI device.
For now, let's ignore upcoming kext deprecations by recent macOS versions (I want to get this working on High Sierra first).
I am testing a custom FPGA NIC and I need to send management information (such as header info for matching) and traffic data to it using a traffic generator from within the user space.
The driver built for the FPGA is a modified version of IXGBE with DMA support for management, and also supports DPDK for kernel bypass to achieve high throughput.
I am trying to understand how the various software (driver, userspace application, etc) should be stacked/connected to each-other so I can achieve the objective of reading and writing to PCIe on the NIC using set of scripts from user space?
I have also been looking at this project
https://github.com/CospanDesign/python-pci
which is useful however based on Xilinx XDMA.
Would appreciate any help, pointers on this.
Sorry, the question is too broad. For such a broad question there is a generic answer: have a look at Inter Process Communication:
https://en.wikipedia.org/wiki/Inter-process_communication
There are variety of methods, like Unix sockets, shared memory, netlink etc, to communicate between user space processes. As well as a variety of methods to communicate between user space and kernel space.
Just pick the best for you and try to do something. If it fails, come again on SO and ask ;)
I am using a i.Mx6 Sabre Lite board running Linux Kernel 3.14.18 and board is supposed to act as a USB Device (USB Gadget). One Vendor specific interface need to be added into CDC/NCM Configuration. CDC/NCM Configuration by default has two standard interfaces - Communication & Data. I have added third interface (Vendor specific) to CDC/NCM Configuration. This interface has two Bulk (IN & OUT) Endpoints. I can verify this newly added interface once board is connected to PC using "lsusb".
Problem:
I cannot see the newly added interface getting exposed to user-space on i.Mx Board or PC, like standard NCM interfaces can be seen as usb0 (Ethernet device) on i.Mx Board as well as on PC and I can PING to/from board using usb0.
If I have to hookup this newly added interface with some g_"driver" (just like standard NCM interfaces are hooked to g_ether); then what is the best choice for BULK I/O?
How to make this newly added vendor specific interface available to i.MX6 user space so as to do read/write on it from Linux Application? I came to know about GadgetFS; but any example would be
Hope someone must have tried similar thing in Linux-USB and can guide.
A vendor-specific interface does not use a standard protocol, so it is not possible to use one of the standard drivers. (And bulk is not a protocol, it is a mechanism to implement your own protocol.)
To access such an interface, you have to use the low-level functions from something like libusb.
I'm working with embedded linux.
There are two USB gadget drivers built as LKM, g_ether.ko and g_file_storage.ko.
I did depmod and then in modprobe -l both drivers show up in the list.
kernel/drivers/usb/gadget/g_ether.ko
kernel/drivers/usb/gadget/g_file_storage.ko
The problem is, the kernel doesn't load either of them on boot anatomically.
Curently my solution is to add boot scripts to /etc/init.d etc/rcX.d to force g_ether.ko to be loaded on boot as the default driver.
Are there other (better) ways to make g_ether.ko default driver?
A possible solution is, I make g_ether.ko a static driver, and make g_file_storage.ko an LKM, but I don't know how to turn off a static driver to release the hardware so that another LKM driver can be loaded.
Any suggestions?
It's a user choice to use USB peripheral controller as ethernet or storage. So there is no related hardware event for automatic client driver loading.
But there is a way to bind/unbind driver in user space through sysfs. Look at this： https://lwn.net/Articles/143397/
I am trying to understand the working of wireless in linux. I started with wpa_supplicant, hostapd applications with the help of their documentation and source code.Understood the flow and basic functionalities of :
wpa_supplicant,nl80211(driver interface)
libnl library(socket communication between user space and kernel using netlink protocol)
cfg80211(kernel interface used for communicating with the driver from userspace with the help of nl80211 implementation in user space),mac80211(software media access control layer)
driver(loadable driver ex:ath6kl - atheros driver).
I understood the above software flow and in my exploration I came to know that for providing freedom for developers MAC layer is implemented in software(popular implementation mac80211).
Is this true in all the cases ? If so what are pros and cons of softMAC and hardMAC ? Do cfg80211 interface in kernel directly communicates with the driver ? who and how communication with mac80211 happens ?
Thanks in advance.
The term 'SoftMAC' refers to a wireless network interface device (WNIC) which does not implement the MAC layer in hardware, rather it expects the drivers to implement the MAC layer.
'HardMAC' (also called 'FullMAC') describes a WNIC which implements the MAC layer in hardware.
The advantages of SoftMAC are:
Potentially lower hardware costs
Possibility to upgrade to newer standards by updating the driver only
Possibility to correct faults in the MAC implementation by updating the driver only
An additional advantage (in the Linux kernel at least) is that many different drivers for different types of WNIC can all share the same MAC implementation, provided by the kernel itself.
Despite the advantages, not all WNICs use SoftMAC. The main advantages of HardMAC is that since the MAC functions are implemented in hardware, they contribute less CPU load.
mac80211 is the framework within the Linux kernel for implementing SoftMAC drivers. It implements the cfg80211 callbacks which would otherwise have to be implemented by the driver itself, and also implements the MAC layer functions. As such it goes between cfg80211 and the SoftMAC drivers.
HardMAC drivers have to implement the cfg80211 interfaces fully themselves.
Also to add :-
Hardmac drivers helps in better as compared to SoftMAC, power save and quick connection/disconnection recovery due to MLME implemented in HW. Better power save is because HW/FW need not to wake up host on disconnection and still can connect and recover .