Le 14/08/2016 15:09, k...@aspodata.se a écrit :
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:
/sys/dev/char/4:0 --> /sys/devices/virtual/tty/tty0/
and /sys/devices/virtual/tty/tty0/dev contains "4:0", meaning the
device file should be created with
'mknod /dev/tty0 c 4 0'
So something like this whould suffice to populate /dev
#!/usr/bin/perl -w
use strict;
my $char = "/sys/dev/char";
my $block = "/sys/dev/block";
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");
}
main();
It woouldn't be hard to convert that to a shell script.
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
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
