I am trying to get a list of device drivers that have been loaded on linux. I would like to do this inside a kernel module I am working on, I was hoping there was kernel call that I could extend or extern in my module. I am hoping not to have to call lsmod I was hoping there was a way to get a handle on the klist. I was hoping for something like get_all_devices(); or something.
Related
I am using Linux kernel release 5.4. I have one kernel built-in driver, which creates a sysfs class: /sys/night_owl/tick1/* using class_create() and device_create_file() function. I am developing another kernel loadable module, which reuses the /sys/class/night_owl class, this means I will have something like this /sys/class/night_owl/tick2/*. Does Linux kernel support this feature or are there any keywords for me to search on this?
I have a task that consists in implementing a driver for an RF module.
The RF module communicate with the blackFin609 microcontroller using UART.
In a first step i created a uClinux image and download it in the BlackFin609 using uBoot and now i have to add the driver module to the kernel.
This is my first experience with embedded linux so i have no idea on how to add a driver module to linux.
Could you please point me to an easy tutorial, i find a lot of long tuto but i don't know from where to start, thanks in advance
So I'm look at sysfs for this. I'm looking at making a module/daemon that can read i2c devices and a couple of other things and export information in the filesystem for our main application.
For instance one of our io expanders is used as a board id, its a tca7408 but I don't need a GPIO interface to it. I just need to read it as an input and export the 0xXX number as an ID for userspace applications.
Just to add to this... is there a way to add custom data to sysfs? Or export application data to files similar to the functionality of sysfs?
If all of your devices are on i2c I would recommend creating a library with an easy to use API, things such as:
BoardId_t getBoardId();
Then you can hide all the i2c details in the library and reuse it where needed.
http://elinux.org/Interfacing_with_I2C_Devices
I tend to only write device drivers for things that actually NEED device drivers, in this case i2c already has a device driver so you can just use it. This will make your code easier to port to different versions of the linux kernel, and even different operating systems, and there is no need to mess with sysfs either.
I've not clear what is the difference between drivers that can be "embedded" inside a monolithic kernel and drivers available only as external modules.
What kind of effort is requested to "port" some driver (provided as "external module" only) to a monolithic kernel?
I would like to be able to run Vmware Tools disabling loadable modules support and getting rid of the initrd bazaar.
Though the driver more or less remains the same(in both cases),there are definitely benefits for using "drivers" embedded in monolithic kernel.
I'll try to explain the "effort in porting" the driver part which you've asked.
Depending on the kind of driver you've, essentially you've to figure out how it will fit in the current kernel source tree, its compilation(include your .ko in the uImage) and loading of it while kernel booting. Let's illustrate each step a bit:
a.) Locate the folder (in the kernel source tree) where you think it is best suited to keep your driver code.
b.) Work on to make sure your driver code is getting compiled.[i.e ultimately it will be part of monolithic kernel image(uImage or whatever you call it)]. In this context, You've to work on your Makefile for your driver. You might have to introduce some CONFIG flags to compile your driver code. There are tons of Makefiles' and driver code lying in the source tree. Roam around and you will get a good reference of how it is being done.
c.) Make sure that your driver code is independent of any other
loadable kernel module(i.e such modules which are not part of the
"monolithic" kernel image). Because if you invoke your driver
code(which is monolithic now and is in memory) which depends on
loadable module code then it may cause some kernel
panic/segmentation fault kind of error.
d.) Make sure that your driver is registered with a higher level of
subsystem which will be initializing all the registered drivers
during boot-up time.(for example: an i2c driver once registered
with i2c driver framework will be loaded automatically when i2c subsystem is initialized during system startup). This step might not be really required if you can figure out another way of invoking your driver's __init and __exit functions.
e.) Now, Your Driver _init and (_exit sections) "should" be called
if it is getting loaded by any device driver framework or directly(i.e. while
kernel is booting up ).
f.) In case of h/w drivers, we have .probe implementation in driver
which will be invoked once the kernel finds a corresponding device.
In case of s/w drivers, I guess __init and __exit is all you have.
g.) Once it is loaded, you can use it like you were using it earlier as a loadable kernel module
h.) I'll recommend reading source code of similar device drivers in the linux kernel tree and see how they are operating.
Hope this helps.
I need to make some RPC calls from a module that resides in the kernel. I was wondering if glib could be used for this prurpose. Has anyone tried using the glib library inside the kernel? Is that even possible?
No, it's not possible to use userspace libraries in the kernel. Have a look at net/sunrpc/ directory for the kernel impletantion of RPC. It's used by the NFS kernel code.