I want to be able to create, read and write attributes in sysfs from user space. I've tried this in a UIO driver (which supposedly runs in user space, so they say) but I came across the same issue with accessing sysfs from user space apps... no access to kobject, sysfs_create_*(), etc.
The sysfs is ideal for me to use to pull data from an IP stream and populate a virtual file system with information that can be exported using NFS. Why? The data is highly cooked for a very specific application I am developing.
I'm cross compiling from a Linux PC box to a Beaglebone board which is running Jessie.
Any recommendations?
Related
I have a task to make a virtual device under a real one with the help of device mapper kernel module. Virtual device must transfer any request to a real device, so both devices must be equal.
In prospective I should be able to control requests, so I wrote kernel module, representing device mapper target, using this article.
After making module and inserting it (insmod command) I setup my device (dmsetup create). Then do mount and can work with a real device through just created virtual.
But the question is how to repeat above mentioned instructions in boot time? I'd like to use my virtual device as a general one (by changing fstab, I guess).
Thanks in advance!
If you are going to use your device as the root filesystem, you need to create an initramfs that sets it up. Basically a shell script that issues dmsetup commands, followed by a mount and finally pivot_root to the new filesystem.
There was a discussion on the dm-devel mailing list last year on how to do this in the Linux kernel without an initramfs, by specifying mapper lines on the kernel command line. This is they way Chrome OS does it, because they can't/won't use an initramfs. See here for documentation of this feature. The functionality was never merged though.
The patch series was updated and resubmitted in May 2017. Hopefully we will eventually see it merged in some form or other.
If you are not going to use your device as the root filesystem, you can still use the same approach if you want, but there might be easier ways.
I am reading Embedded Linux Primer book and The Linux Kernel Module Programming Guide and I am confused about user space application communication with kernel module
User space App --> Device node/proc file --> kernel module ( which resides in /lib/modules/)
1) What is exact difference when we communicate with device node method ( /dev/ - with open,read,write,close calls) and /proc/file method ?
procfs (/proc) should be reserved for process information a module should not put any file there. At some point, procfs was the only available pseudo filesystem, that is why you can find sound system or RTC information. Then, sysfs was created to properly contain those information.
The main difference between using a device file (usually residing in /dev) and a file from procfs is the way it is handled in the kernel.
Operations used for the device files are registered using the file_operations structure usually with cdev_init and cdev_add for a character device. Your module may not do that as quite often, the subsytem is the one registering your device.
While the operations for files in procfs are registered using proc_create
At present, I have a Linux 2.6 kernel module which accesses a certain device via pci_get_device() and pci_read_config_dword(). In future, the module shall be modified to also work a different machine which seems to have no PCI bus (/sys/bus/pci doesn't exist), but has the certain device at a fixed, known address. Now, I would like to have one module binary without parameters which works on both machines. To be able to load the module on the non-PCI machine, I think I must refrain from using pci_get_device() etc.; thus I have to get the needed config space info on the PCI machine in some other way. I could read it from /sys/bus/pci/devices/.../resource in my init_module(), but I gather it is considered bad practice to make kernel modules read files. Are there better ways to achieve my goal?
When functions like pci_get_device() cannot be used (because the module must work also with kernels that don't provide such functions), apparently there is no better way to get the PCI address info than reading /sys/bus/pci/devices/.../resource.
I resorted to doing so, using filp_open(), vfs_read() and filp_close() on the basis of How to read/write files within a Linux kernel module?.
My question is pretty much the same as -
How to create a virtual file?
except I want to do it in Linux instead. I imagine what I need to do is create a virtual device and point the application logging to that device. I'd like to write the device in python or ruby or something else interpreted, if possible.
check out named pipes http://en.wikipedia.org/wiki/Named_pipe
Use mknod. You can create a socket file which your apps can write too. And your logging app would connect to the socket to read from it.
Mocking usb devices using umockdev
Umockdev is a linux based application which record the behaviour as well as properties of hardware and run the software independent of actual hardware it is running on. Hardware devices can be simulated in virtual environments
without disturbing the whole system.It currently supports sysfs, uevents, basic support for /dev devices, and recording/mocking usbdevfs ioctls (for PtP/MTP devices).
umockdev home page
source code and examples
I'm looking for either a kernel mode call that I can make from a driver, a userland utility, or a system call that will ask the Kernel to look at the PCI bus and either completely re-run its initialization, or initialize a specific device. Specifically, I need the Kernel to recognize a device that was added to the bus after boot and then configure its address space, interrupt, and other configuration parameters, and finally enable the device so that I can load the driver for it (unless this all happens as part of the driver load).
I'm stuck on the 2.4.x series Kernel for this, and am currently working with 2.4.20, but will be moving to 2.4.37 if it matters. The distro is a stripped down Red Hat 7.3 running in a ram disk, but I can add in whatever tools are needed to get this working (as long as they play nice with 2.4 series).
If some background would help clarify what I'm trying to do: From a cold boot, once in Linux I use GPIO to program an FPGA. Part of the FPGA, once programmed, implements a simple PCI device. Currently, after programming the FPGA, I reboot the system and Linux recognizes the device after coming up and loads the driver for it.
Instead of needing that reboot, I'd like to simply ask the Kernel to do whatever it does during boot up to find PCI devices (I have the Kernel configured to find PCI devices on its own, instead of asking the BIOS for that information, so the BIOS won't need to know about this device (I hope)).
I believe that Linux is capable of seeing the device after it is programmed but before a reboot, because scanpci will show the device after I program it, as will lspci -H 1. I just need a way to get it into /proc/pci, configured and enabled.
This below command will help the user to rescan it complete root hub.
echo "1" > /sys/class/pci_bus/0000\:00/rescan
You could speed up the reboot with kexec, if you don't figure out how to get the PCI scan redone. You could ask this on the LKML, if you haven't already.
unloading/reloading the module doesn't help, does it?
http://www.linuxjournal.com/article/5633 suggests you should be able to do it with 2.4 kernels using pcihpfs.
If that isn't working, maybe the driver doesn't support hotplug?
It would probably crash the system if you reconfigured the addresses of other PCI devices while they are in use.
A better way would be to just configure the new card. If your kernel has support for Cardus devices, it already knows how to configure a newly-inserted PCI device (which is what Cardbus is). You just need to figure out how to get the kernel to do it...
It should be possible for a kernel module to do this. Even if you can't get built-in hotplug code, you should be able to set the pci resources using calls to pci_bus_write_config_dword() and friends. There is probably some IRQ routing setup to do as well.