Re: The guts of /dev/* ?

From: Robert Heller (heller_at_deepsoft.com)
Date: 12/05/04


Date: Sun, 05 Dec 2004 00:51:53 +0100


   not@top-post,
  In a message on Sat, 04 Dec 2004 10:54:05 -0600, wrote :

n> Where would I find text explaining the 'innards' of /dev/* ?
n> Not at a 'salesClerk level': "try xyz [it worked for me]. ", but
n> down at asm, interrupts ...etc. level.
n>
n> Like what happens when you cat /dev/dsp > fileName
n> - in depth.

First of all, 'device files' (eg most of the files in /dev) are not
regular files. All they do is provide a mapping from names (/dev/dsp)
to major and minor numbers (14,3). Generally the major number maps to
a device driver (source code lives in
/usr/src/linux<mumble>/drivers/...). The minor number is used to select
an 'instance' or 'aspect' of the device, where there might be more than
one instance or aspect of a given device on your system (eg multiple disk
drives/partitions, or multiple serial ports, etc.). For example, 14
relates to the sound driver. The minor numbers refer to various sound
card sub-systems:

dir -l /dev/|grep '14,'
crw------- 1 heller root 14, 4 Apr 11 2002 audio
crw------- 1 heller root 14, 20 Apr 11 2002 audio1
crw------- 1 heller root 14, 7 Apr 11 2002 audioctl
crw------- 1 heller root 14, 3 Apr 11 2002 dsp
crw------- 1 heller root 14, 19 Apr 11 2002 dsp1
crw------- 1 heller root 14, 2 Apr 11 2002 midi00
crw------- 1 heller root 14, 18 Apr 11 2002 midi01
crw------- 1 heller root 14, 34 Apr 11 2002 midi02
crw------- 1 heller root 14, 50 Apr 11 2002 midi03
crw------- 1 heller root 14, 0 Apr 11 2002 mixer
crw------- 1 heller root 14, 16 Apr 11 2002 mixer1
crw------- 1 heller root 14, 1 Apr 11 2002 sequencer
crw------- 1 root root 14, 8 Apr 11 2002 sequencer2
crw------- 1 root root 14, 6 Apr 11 2002 sndstat

There is a master table in the kernel which maps device numbers to
device driver entry points. When a device file is open()'ed, this
table is refereed to and the kernel creates a (kernel) data structure
(associated with the process) with the information needed to deal with
the device. This structure is referenced (indexed) by the file
descriptor number open returns.

For a more in-depth look, you can look at the kernel source code.

n>
n> Thanks for any info.
n>
n> == Chris Glur.
n>
n>
n>

                                     \/
Robert Heller ||InterNet: heller@cs.umass.edu
http://vis-www.cs.umass.edu/~heller || heller@deepsoft.com
http://www.deepsoft.com /\FidoNet: 1:321/153

                   



Relevant Pages

  • Re: Trap number: how a system software recognise it?
    ... MINIX has no concept of "device recognition". ... discuss how to implement a new device driver - not so much documentation ... > driver code at the kernel space to perform the low level instructions. ... User program issues readlibc function to read some bytes from ...
    (comp.os.linux.misc)
  • Re: Trap number: how a system software recognise it?
    ... MINIX has no concept of "device recognition". ... discuss how to implement a new device driver - not so much documentation ... > driver code at the kernel space to perform the low level instructions. ... User program issues readlibc function to read some bytes from ...
    (comp.os.linux.development.system)
  • Re: Process D-stated in generic_unplug_device
    ... After a recent kernel upgrade (essentially 2.6.15.4 + a selection of other ... Please test vanilla 2.6.16-rc3 and let us know what block device driver is ... element of the production server that I can't duplicate in the lab right now ... Given that we can't replicate the problem on our lab hardware, ...
    (Linux-Kernel)
  • waiting process in procfs read
    ... I submitted this as a bugzilla kernel bug report but was directed here. ... My device driver sets up an entry in the /proc tree. ... If I kill the waiting process I do see "WOKE UP" and "returns error due to ... I can not see any reason why the waiting process wouldn't wake up. ...
    (Linux-Kernel)
  • Re: how to read dynamic data structures from the kernel (was Re: reading routing table)
    ... steps for any given kernel subsystem -- we have data structures, synchronization models, etc, that are all tuned to their common use requirements, and monitoring is very much an edge case. ... Then we release the global locks, and proceed lock, externalize, unlock, and copyout each individual entry, using a generation number fo manage staleness. ... It's unideal in other ways -- long lists, reference count complexity, etc, but as I mentioned, it is very much an edge case, and much of that mechanism is something we need anyway for any moderately complex kernel data structure. ...
    (freebsd-net)