Re: An idea on devfs vs. udev
From: Rob Landley
Date: Sun Oct 30 2005 - 18:31:29 EST
On Sunday 30 October 2005 12:07, Daniele Orlandi wrote:
> Disclaimer: My knowledge about devfs/udev/sysfs is superficial,
> I see /dev as an abstraction layer above /sys, where udev implements the
1) /sys/block/thingy/dev is a _text_file_, not a device node. It indicates
the major/minor, but you can't access the device through it.
2) Sysfs contains no permissions or ownership info.
A dozen-line shell can "find /sys -name dev", call sed 's/:.*//' and sed
'/.*://' on each entry to get the major and minor numbers, and do a mknod for
each (everything starting /sys/block takes b, the rest take c), and viola
you've populated dev. Except everything belongs to root and is chmod 700,
this is _dog_ slow (even populating the standard 100 or so entries can take 5
seconds on a 2 ghz machine), and doesn't handle adding/removing devices after
boot. But it's quick and dirty.
> Embedded people say "We don't need that kind of abstraction, we are ok with
> working at the lower level".
I maintain a half-dozen busybox applets. The really crazy embedded people are
yanking out /proc and /sys both (to save space), and using matt mackall's
-tiny tree with the kamikazi lobotomy options enabled.
> So, why cannot we substitute the "dev" file within /sys with the actual
> device file?
A) Go look at this thing:
B) Getting permissions and ownership right is A) policy, B) a security issue.
(Who owns what? Well what users are on _your_ system?)
> This is *not* meant to be alternative to udev, just a possibility for
> people who cannot run hotplug/udev
Who? This is a bit like saying "people who can't run ksoftirqd". It's
transient bootup code with tiny memory requirements and a reasonable disk
I'm pondering adding a micro-udev to busybox (it's fairly far down on the todo
list). It turns out udev is smaller than it seems because it block copies
code out of klibc and libsysfs (yes, having a standard interface library to
sysfs is _such_ a good idea we should fork our own copy and bundle it. After
all, that's what shared libaries are for...) And once you chop out all that,
90% of what's left is _still_ optional (try "grep ' main(' *.c'" and notice
we have 12 separate occurrences of main(). For something that needs at most
two (bootup and hotplug) and the bootup version can be a command line option.
You don't need udevinfo, udevmonitor, udevsend, or udevtest.) Add in the
fact that udev/udevd use a gratuitous database that can be ditched, and then
contemplate simplifying the config file (cut down the parser, and embedded
users should NOT need a rules compiler; dunno whether it's worth it to keep
the same config file syntax or come up with something tiny and dumb for
I'm not knocking it (much), just saying a busybox version could theoretically
be stripped way the heck down. (Not sure how small yet because I haven't
done the work. My busybox time is likely to go down in future because this
is a hobby and I need to go find something to get paid to do again, which is
always time consumping. :) I keep dreaming somebody might someday sponsor
work on busybox, but embedded device people are understandably pretty cheap.)
> and still want to access dynamic devices
> and are prepared to adapt their software and libraries to another scheme.
j=`echo "$1" | sed 's .*/\(.*\)/dev \1 '`
minor=`cat "$1" | sed 's .*: '`
major=`cat "$1" | sed 's :.* '`
mknod tmpdir/"$j" $2 $major $minor
for i in `find /sys/block -name "dev"`
makedev -m 700 $i b $major $minor
echo -n b
for i in `find /sys/class -name "dev"`
makedev -m 700 $i c $major $minor
echo -n c
You think implementing that in C would take more than 4k?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/