> Didier:
> ...
>>      Erratum again. The devices are accessible through symlinks in
>> /sys/dev/char and /sys/dev/block. The name of each symlink apparently
>> duplicates the contents of the dev file in the directory it points to. Eg:

> sub run_dir($$) {
>      my $dir = shift;
>      my $type = shift;

>      opendir(my $dh, $dir) || return;
>      while(readdir $dh) {
>     next unless m/^\d+:\d+$/;
>     my $file = "$dir/$_";
>     my ($maj,$min) = split(/:/);

>     my $name = readlink($file);
>     next unless (defined($name));
>     $name =~ s|.*/||;
>     print "mknod $name $type $maj $min\n";
>      }
>      closedir $dh;
> }

> sub main() {
>      run_dir($char, "c");
>      run_dir($block, "b");
> }

     I can't read perl, but it seems to me that you got it. And it might 
be converted to a script. Basically, at any time, the whole /dev 
structure can be re-created by such a simple program. However it is 
essential to be able to do it in real time, which, also, isn't very 
difficult, reading uevents from the netlink.

      Not all the job is covered by this however. Here is a list, by 
growing order of difficulty:

     - pts interfaces must be created in /dev/pts, with /dev/pts mounted 
with -t devpts

     - Module and firmware loading requests must be honoured in real 
time, but this is straightforward and newer kernel versions will take 
over this job because udev people decided to do it in a way which is in 
contradiction with kernel expectation,

     - Some devices don't show up in /dev and need some action, eg the 
network interfaces,

     - Some applications need access to detailed device properties like 
keyboard mapping. AFAIU, the kernel  API (/sys and /proc) is always 
changing and these changes are taken in charge by libudev to present a 
stable API to applications like xorg. I don't know yet, but it is 
possible that libudev makes use of some files maintained by udev, which 
would explain the dependency. This is an area where standardization 
would be usefull.

     Didier