Code location in kernel responsible for probing devices attached/detached

Hi,

Where are the code in the kernel responsible for probing devices attached/detached to the ports in the board/PC? Is that code uses event driven method to probe that devices ie) by means of any interrupt like mechanisms?

Please reply!

Hi,

Originally Posted by ayyasprings Hi, Where are the code in the kernel responsible for probing devices attached/detached to the ports in the board/PC? Is that code uses event driven method to probe that devices ie) by means of any interrupt like mechanisms? Please reply!

From https://en.wikipedia.org/wiki/Udev

udev is a device manager for the Linux kernel. As the successor of devfsd and hotplug, udev primarily manages device nodes in the /dev directory. At the same time, udev also handles all user space events raised while hardware devices are added into the system or removed from it, including firmware loading as required by certain devices.

Hope this helps.
Have fun & enjoy!

Hi onebuck,

Upto my knowledge the udev uses the environment variables and values supplied by \sbin\hotplug utility which was called after the device was detected to be attached/detached and a kobject was added by Linux device model code. But I like to know the platform specific code location which detects the voltage level changes in the pin and calls the subsequent function calls to calling hotplug utility.

Please reply!

Hi,

Originally Posted by ayyasprings Hi onebuck, Upto my knowledge the udev uses the environment variables and values supplied by \sbin\hotplug utility which was called after the device was detected to be attached/detached and a kobject was added by Linux device model code. But I like to know the platform specific code location which detects the voltage level changes in the pin and calls the subsequent function calls to calling hotplug utility. Please reply!

You missed this;

The system gets calls from the kernel via netlink socket. Earlier versions used hotplug, adding a link to themselves in /etc/hotplug.d/default with this purpose.

Look at this from Operations;

udev is a generic kernel device manager. It runs as a daemon on a Linux system and listens (via netlink socket) to uevents the kernel sends out if a new device is initialized or a device is removed from the system. The system provides a set of rules that match against exported values of the event and properties of the discovered device. A matching rule will possibly name and create a device node and run configured programs to set up and configure the device. udev rules can match on properties like the kernel subsystem, the kernel device name, the physical location of the device, or properties like the device's serial number. Rules can also request information from external programs to name a device or specify a custom name that will always be the same, regardless of the order devices are discovered by the system. In the past a common way to use udev on Linux systems was to let it send events through a socket to HAL, which would perform further device-specific actions. For example, HAL would notify other software running on the system that the new hardware had arrived by issuing a broadcast message on the D-Bus IPC system to all interested processes. In this way, desktops such as GNOME or K Desktop Environment 3 could start the file browser to browse the file systems of newly attached USB flash drives and SD cards.[3] By the middle of 2011 HAL had been deprecated by most Linux distributions as well as by the KDE, GNOME[4] and XFCE[5] desktop environments, among others. The functionality previously embodied in HAL has been integrated into udev itself, or moved to separate software such as udisks and upower.

A good paper to reference, even if it is dated but still useful; http://www.kroah.com/linux/talks/ols_2003_udev_paper/Reprint-Kroah-Hartman-OLS2003.pdf

Remember that IRQ from the PIC provides notification for a device interrupt to the kernel which then addresses the udev via rules set. Here is; http://jdurrett.ba.ttu.edu/Resources...ssignments.pdf

Plus you should look at; https://en.wikipedia.org/wiki/Interrupt_handler

Locally you can; 'cat /proc/interrupts'

As to the pin assignments for 8259. IRQ, ACPI and APIC and the Linux kernel is a good read with some very useful information.
Hope this helps.
Have fun & enjoy!