I am writing a C program in Linux user space for an HMI. I want to detect the pendrive when inserted into the USB port on my SBC. I am running Lubuntu on it. So it is not having udev libraries. When I try to install udev on SBC, it is asking for dependencies and version compatibility issues are coming. Is there any other way to detect the Pendrive insertion from user space.
When I mount a device ex: /dev/sdc1(pendrive) to a particular folder ex: /mnt/vj, its being mounted properly. If I remove the pendrive without unmounting it then when next time pendrive inserted its being detected as /dev/sdd1 . How to fix the logical name for a pendrive in such cases. I want it to be /dev/sdc1 always. Is it possible?
Thanks in anticipation.
You can implement your own event listening daemon instead of udev. Youhave to create a netlink socket of type NETLINK_KOBJECT_UEVENT. By parsing the events, you will be able to detect the insertion of your drive.
It is not possible to ensure the name is always the same but you can probably create a symlink to the proper block device after detecting the event.
Check the link ubuntu 12.04 libudev-dev won't install because of dependencies that should mostly resolve your udev installation/dependencies issue if related to it.
udev is one of the easiest ways for detecting hardware plug-in and fetching of device information. Checkout libudev that is part of udev (Device manager of Linux kernel). Apart from managing device nodes in the /dev directory while hardware devices are added into the system or removed from it, the udev also handles all related user-space events that are raised during various operations such as addition/removal.
libudev allows access to device information and also provides a monitoring interface like udev_monitor that connects to device event source. udev_monitor_get_fd provides file descriptor that can be used with select system call for monitoring.
Check this link that has information related to usage of libudev http://www.signal11.us/oss/udev/
Related
I want to write a linux inspection tool to check the usb device usage records on a certain machine. Parsing the dmesg method can obtain the usb usage record from the system startup to the present, and does not use dmesg -c to clear the dmesg information. So the point of the question is whether there is a place on the Linux system that records all USB usage records in the system, just like the Windows system writes this in the registry.
Linux doesn't natively provide this functionality. It isn't seen as an intrinsically important feature to have, and as mentioned, it can be done easily with a udev rule for those who want it. It's generally assumed that anyone with physical access to the machine can read any unencrypted data on it and execute arbitrary code on it if it's running, so logging USB devices isn't really an effective security measure.
If you want to see the recent history, you can check the kernel log (often /var/log/kern.log) to read the recent and older entries that the kernel has output when a USB device has been inserted. Do note that these are rotated periodically, so they won't provide the entire history of the system.
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.
Right now, I'm compiling with printk's, copy the resulting kernel to a USB stick, mounting the USB stick on the device, mounting the partition that contains the kernel, copying the new kernel from the USB stick to the partition, rebooting, then inspecting the trace by capturing the dmesg output to a file.
On workstation:
make my-kernel
cp new_kernel /path/to/usb/stick
On embedded device:
mount /dev/sda1/ /mnt
mount kernelpartition /tmp/kernel
cp /mnt/new_kernel /tmp/kernel
sync
umount /tmp/kernel
umount /dev/sda1
reboot
dmesg > mytrace
less mytrace
Is it supposed to this painful to develop? I don't understand how any meaningful amount of non-trivial kernel code is ever developed.
The best workflow is going to depend on the capabilities of the device you are working with. Often they will have a bootloader with options to boot from a network or serial port.
I'm doing some embedded development also, and here's what I came up with. The device I am working with has some built in flash which by default it boots from, but also has a USB port and an SD Card slot. It has a fairly primitive bootloader.
On the USB port I have connected a wifi dongle. I make sure that I compile the kernels with the needed modules to get the USB dongle up and running.
I have built a minimal kernel and root filesystem which I have flashed onto the device. This kernel has the option CONFIG_KEXEC enabled. The root filesystem has kexec tools. I build the system using buildroot.
When this system starts, it attempts to mount the SDCARD and checks to see if it can find a kernel in the root directory. If it can, then it uses kexec to boot this second kernel. This is done using a custom init script that I have written.
If you don't have an SD Card slot on your device, you could probably do something similar with a USB memory stick.
With this setup, I can just use sftp to transfer a new kernel image onto the sdcard, and kexec to boot it. It saves me the hassle of reflashing the device each time I change the kernel.
I have a ASUS laptop with Fedora 13. My problem is that any USB storage I connect does not automount. I have other computer with Fedora 13 which does not have the problem.
I have not be able to find any difference in configuration between my laptop and other computers that work.
So to try to trace down the problem I started to looomk for documentation on how it was supposed to work. I have looked at udev, devkit, hal , dbus, polkit, gnome and others.
I want to know which events, logs, config files and monitor programs that I can use to track down the events that takes place from when I attach an USB stick and until i have a window up and running in GNOME.
So far I have traced that udev detects the disk and creates /dev/sdb (and /dev/sdb1 for partition 1) and that event about device added is sent as messages on dbus. I am able to mount the disk manually with udisks but not with gnome-disk-utility (palmiset).
There is many different applications involved to automount a disk, I want to find out where in the chain of events does it fail.
I just found the reason it did not mount. I had a leftover file from earlier udev version. File 60-persistent-storage.rules existed in both /etc/udev/rules.d and in /lib/udev/rules.d . The former overruled the last one. When removing the one in /etc/udev/rules.d the USB drives mounted correctly again.
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.