Difference between revisions of "Linux device management"

from HTYP, the free directory anyone can edit if they can prove to me that they're not a spambot
Jump to navigation Jump to search
m (added "edit log")
m (→‎Notes: umm, I *meant*...)
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
[[Linux]]:
+
[[Computing]]: [[Linux]]: [[Linux device management|device management]]
[[Device management]]
 
 
==Notes==
 
==Notes==
This text seemed like it might be useful information, even if it
+
This text seemed like it might be useful information, even if it contained some inaccuracies. Original document was published under [http://www.gnu.org/licenses/gpl.html GNU General Public License, Version 2], and those with appropriate knowledge should feel free to edit or expand the text.
contained some inaccuracies. Original document was published under
 
[http://www.gnu.org/licenses/gpl.html GNU General Public License,
 
Version 2], and those with appropriate knowledge should feel free to
 
edit or expand the text.
 
 
==Edit Log==
 
==Edit Log==
* '''2005-10-05''' Copied from
+
* '''2005-10-05''' Copied from http://www.reactivated.net/writing_udev_rules.html, with minor editing for clarity; the below was originally part of the udev article but seemed to belong here instead. The rest of the article should be checked to make sure it still makes sense without the introduction.
http://www.reactivated.net/writing_udev_rules.html, with minor editing
 
for clarity
 
 
==Text==
 
==Text==
 
A basic introduction only, might not be totally accurate.
 
A basic introduction only, might not be totally accurate.
On typical linux-based systems, the /dev directory is used to store
+
 
file-like device nodes which refer to certain devices in the system.
+
On typical linux-based systems, the /dev directory is used to store file-like device nodes which refer to certain devices in the system. Each node points to a part of the system (a device), which might or might not exist. Userspace applications can use these device nodes to interface with the systems hardware, for example, XFree86 will "listen to" /dev/input/mice so that it can relate the users mouse movements to moving the visual mouse pointer.
Each node points to a part of the system (a device), which might or
+
 
might not exist. Userspace applications can use these device nodes to
+
The original /dev directories were just populated with every device that might possibly appear in the system. /dev directories were typically very large because of this. devfs came along to provide a more managable approach (noticably, it only populated /dev with hardware that is plugged into the system), as well as some other functionality, but the system proved to have problems which could not be easily fixed.
interface with the systems hardware, for example, XFree86 will "listen
+
 
to" /dev/input/mice so that it can relate the users mouse movements to
+
[[udev]] is the "new" way of managing /dev directories, designed to clear up some issues with previous /dev implementations, and provide a robust path forward. In order to create and name /dev device nodes corresponding to devices that are present in the system, udev relies on matching information provided by sysfs with rules provided by the user.
moving the visual mouse pointer.
+
 
The original /dev directories were just populated with every device
+
[[sysfs]] is a new filesystem to the 2.6 kernels. It is managed by the kernel, and exports basic information about the devices currently plugged into your system. udev can use this information to create device nodes corresponding to your hardware. sysfs is mounted at /sys and is browsable. You may wish to investigate some of the files stored there before getting to grips with udev. Throughout this document, I will use the terms /sys and SYSFS interchangeably.
that might possibly appear in the system. /dev directories were
+
==Notes==
typically very large because of this. devfs came along to provide a
+
Mysterious message where digiKam (or other digital camera app) used to be able to talk to a camera (in our case, the [[Kodak EasyShare C360]] and suddenly can't: the problem seems to be with permissions on the device; you need to be able to ''write'' as well as read to it. This is probably a change in the udev configuration or something related, and I'll figure that out later, but for now the way to get it working is:
more managable approach (noticably, it only populated /dev with
+
* Run {{linuxcmd|lsusb}} (on some distros, you need to type '''/sbin/lsusb''') – sample output:
hardware that is plugged into the system), as well as some other
+
woozle@gonzo:~$ lsusb
functionality, but the system proved to have problems which could not
+
Bus 002 Device 001: ID 0000:0000
be easily fixed.
+
{{hilite|Bus 001 Device 013: ID 040a:0589 Kodak Co.}}
[[udev]] is the "new" way of managing /dev directories, designed to
+
Bus 001 Device 007: ID 0923:010f IC Media Corp. SIIG MobileCam
clear up some issues with previous /dev implementations, and provide a
+
Bus 001 Device 002: ID 05e3:0604 Genesys Logic, Inc. USB 1.1 Hub
robust path forward. In order to create and name /dev device nodes
+
Bus 001 Device 001: ID 0000:0000
corresponding to devices that are present in the system, udev relies on
+
* Look inside '''/dev/bus/usb'''. In the case of the above results, you would see the folder '''/dev/bus/usb/001''', and inside that a device called '''013'''. Change the permissions of 013 so it is readable and writable by your user account.
matching information provided by sysfs with rules provided by the user.
+
 
[[sysfs]] is a new filesystem to the 2.6 kernels. It is managed by the
+
Various things may reset this permission before you can actually view it for files, so if you get a message that the camera can't be read, try resetting the permissions again (without closing anything) and retry accessing the camera.
kernel, and exports basic information about the devices currently
 
plugged into your system. udev can use this information to create
 
device nodes corresponding to your hardware. sysfs is mounted at /sys
 
and is browsable. You may wish to investigate some of the files stored
 
there before getting to grips with udev. Throughout this document, I
 
will use the terms /sys and SYSFS interchangeably.
 

Latest revision as of 14:42, 12 April 2007

Computing: Linux: device management

Notes

This text seemed like it might be useful information, even if it contained some inaccuracies. Original document was published under GNU General Public License, Version 2, and those with appropriate knowledge should feel free to edit or expand the text.

Edit Log

  • 2005-10-05 Copied from http://www.reactivated.net/writing_udev_rules.html, with minor editing for clarity; the below was originally part of the udev article but seemed to belong here instead. The rest of the article should be checked to make sure it still makes sense without the introduction.

Text

A basic introduction only, might not be totally accurate.

On typical linux-based systems, the /dev directory is used to store file-like device nodes which refer to certain devices in the system. Each node points to a part of the system (a device), which might or might not exist. Userspace applications can use these device nodes to interface with the systems hardware, for example, XFree86 will "listen to" /dev/input/mice so that it can relate the users mouse movements to moving the visual mouse pointer.

The original /dev directories were just populated with every device that might possibly appear in the system. /dev directories were typically very large because of this. devfs came along to provide a more managable approach (noticably, it only populated /dev with hardware that is plugged into the system), as well as some other functionality, but the system proved to have problems which could not be easily fixed.

udev is the "new" way of managing /dev directories, designed to clear up some issues with previous /dev implementations, and provide a robust path forward. In order to create and name /dev device nodes corresponding to devices that are present in the system, udev relies on matching information provided by sysfs with rules provided by the user.

sysfs is a new filesystem to the 2.6 kernels. It is managed by the kernel, and exports basic information about the devices currently plugged into your system. udev can use this information to create device nodes corresponding to your hardware. sysfs is mounted at /sys and is browsable. You may wish to investigate some of the files stored there before getting to grips with udev. Throughout this document, I will use the terms /sys and SYSFS interchangeably.

Notes

Mysterious message where digiKam (or other digital camera app) used to be able to talk to a camera (in our case, the Kodak EasyShare C360 and suddenly can't: the problem seems to be with permissions on the device; you need to be able to write as well as read to it. This is probably a change in the udev configuration or something related, and I'll figure that out later, but for now the way to get it working is:

  • Run lsusb (on some distros, you need to type /sbin/lsusb) – sample output:
woozle@gonzo:~$ lsusb
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 013: ID 040a:0589 Kodak Co.
Bus 001 Device 007: ID 0923:010f IC Media Corp. SIIG MobileCam
Bus 001 Device 002: ID 05e3:0604 Genesys Logic, Inc. USB 1.1 Hub
Bus 001 Device 001: ID 0000:0000
  • Look inside /dev/bus/usb. In the case of the above results, you would see the folder /dev/bus/usb/001, and inside that a device called 013. Change the permissions of 013 so it is readable and writable by your user account.

Various things may reset this permission before you can actually view it for files, so if you get a message that the camera can't be read, try resetting the permissions again (without closing anything) and retry accessing the camera.