No subject

---------------------------------------------------------------------
How does udev work?
~~~~~~~~~~~~~~~~~~~
Short summary: when a driver is loaded it makes some information available
in /sys/ and udev is run to read them and create the appropriate devices.

This means that:
- modules cannot be loaded on demand when applications open their device,
  because the device is not yet there!
- since modules are not loaded on demand, if you do not have a working
  hotplug package which can synthesize PCI hotplug events at boot time
  you will have to manually load with /etc/modules all the drivers you need.
- some modules are not hardware drivers and cannot be loaded automatically
  by hotplug, so they will have to be listed in /etc/modules as well.
- some drivers have not been ported to sysfs yet, and udev will not be
  able to create their devices. If you use one of these drivers you will
  have to create the devices after every boot.
- some drivers, like the md kernel RAID drivers, have design problems and
  will require further development before they will fully work with udev.
  See http://groups.google.com/groups?threadm=1VPLh-6f9-11%40gated-at.bofh.it
  and #294404 for details. Possible workarounds are manual creation of
  the /dev/md* devices or kernel RAID volumes autostart.


Also from the udev docs:
We've got a couple goals for udev:

1) dynamic replacement for /dev
2) device naming
3) API to access info about current system devices

Splitting these goals into separate subsystems:

1) udev - dynamic replacement for /dev
2) namedev - device naming
3) libsysfs - a standard library for accessing device information on the
              system.

Udev
------

Udev will be responsible for responding to /sbin/hotplug on device
events.  It will receive the device class information along with
device's sysfs directory.  Udev will call the name_device function from
the naming device subsystem with that information and receive a unique
device name in return.  Udev will then query sysfs through the libsysfs
for specific device information required for creating the /dev node like
major and minor number.  Once it has the important information, udev
will create a /dev entry for the device, add the device to the in memory
table of current devices, and send notification of the successful event
through a D-BUS message.  On a remove call, udev will remove the /dev
entry, remove the device from the in memory table, and send
notification.

Udev will consist of a command udev - to be called from /sbin/hotplug.
It will require the in memory dynamic database/table for keeping track
of current system devices, and a library of routines for accessing that
database/table.  Udev will not care about "how" devices are named, that
will be separated into the device naming subsystem.  It's presented a
common device naming API by the device naming subsystem to use for
naming devices.
...



For more information on the other two:
http://www.freedesktop.org/software/dbus/
http://www.freedesktop.org/Software/hal



On Wednesday 30 November 2005 00:13, Ken Moffat wrote:
> Collins Richey wrote:
> >...and you need something like hotplug (or ????) in
> >conjunction with udev to get the behavior you are looking for.
> >
> >HTH,
> >g !
>
> I think hotplug and udev conflict; you must choose one only. (could be
> debian distro dependent)

-- 
Matthew Carpenter 
matt at eisgr.com                          http://www.eisgr.com/

Enterprise Information Systems
* Network Server Appliances
* Security Consulting, Incident Handling & Forensics
* Network Consulting, Integration & Support
* Web Integration and E-Business
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.linux-sxs.org/pipermail/linux-users/attachments/20051130/2393492f/attachment-0001.pgp