Disclaimer: My knowledge about devfs/udev/sysfs is superficial, all the
following text maybe nonsense. In case, please ignore it, complain, insult
me, whatever you prefer, I'm not going to be offended :)
I see /dev as an abstraction layer above /sys, where udev implements the
abstraction. udev takes information from /sys and "translates" it to device
files organized in a nice way, following several policies configured on the
system.
Embedded people say "We don't need that kind of abstraction, we are ok with
working at the lower level".
So, why cannot we substitute the "dev" file within /sys with the actual device
file?
udev could continue to work in the same fashion, just stat(2)ing the file,
instead of parsing its contents.
embedded software could directly access the device file in /sys following a
path that is often meaningful and persistant between reboots.
This is *not* meant to be alternative to udev, just a possibility for people
who cannot run hotplug/udev and still want to access dynamic devices and are
prepared to adapt their software and libraries to another scheme.
Bye,
--
Daniele Orlandi
On Sunday October 30, [email protected] wrote:
>
> So, why cannot we substitute the "dev" file within /sys with the actual device
> file?
I'd just like to say that I am 100% in favour of this idea.
The argument against it seems to be something that I have never
managed to understand about "policy not belonging in the kernel".
Now I agree that the kernel should avoid implementing policy, but I
fail to see how that relates to the current issue.
In fact, the way I see it, the current practice clearly violates the
"avoid policy" policy.
The kernel needs to export major/minor information through the
file system. The "obvious" mechanism for doing this is through a
device special file.
But instead, a text file with %d:%d is used. Why? I presume to stop
people from just opening /sys/.../dev. Stopping people from doing
such a thing is clearly implementing a "Thou shall not" policy.
But then to make matters worse, there is this "sample.sh" file. UGH!
It's a bit of shell code exported by the kernel.
#!/bin/sh
mknod /dev/hda b 3 0
This contortion would be totally unnecessary if 'dev' were an honest
device special file. Then instead of
sh $sysfspath/sample.sh
you could
cp -R $sysfspath/dev /dev/`basename $sysfspath`
Notes:
- obviously a different name would have to be chosen for back
compatibility (rdev?).
- I would *not* be in favour of then allowing chown/chmod. These
special files should stay root/root/0600.
NeilBrown
On Sun, Oct 30, 2005 at 08:07:11PM +0200, Daniele Orlandi wrote:
>
> So, why cannot we substitute the "dev" file within /sys with the actual device
> file?
Please read the archives, this comes up every few months or so.
greg k-h
On Mon, Oct 31, 2005 at 08:18:12AM +1100, Neil Brown wrote:
> But then to make matters worse, there is this "sample.sh" file. UGH!
> It's a bit of shell code exported by the kernel.
> #!/bin/sh
> mknod /dev/hda b 3 0
That's just a "joke" patch that is only in the -mm tree, as it gets
pulled in from my tree. It's not in mainline, and will never go there.
thanks,
greg k-h
On Sunday October 30, [email protected] wrote:
> On Mon, Oct 31, 2005 at 08:18:12AM +1100, Neil Brown wrote:
> > But then to make matters worse, there is this "sample.sh" file. UGH!
> > It's a bit of shell code exported by the kernel.
> > #!/bin/sh
> > mknod /dev/hda b 3 0
>
> That's just a "joke" patch that is only in the -mm tree, as it gets
> pulled in from my tree. It's not in mainline, and will never go there.
That's a relief,
thanks,
NeilBrown
On Sunday October 30, [email protected] wrote:
> On Sun, Oct 30, 2005 at 08:07:11PM +0200, Daniele Orlandi wrote:
> >
> > So, why cannot we substitute the "dev" file within /sys with the actual device
> > file?
>
> Please read the archives, this comes up every few months or so.
..thus making it a Frequently Asked Question. However it isn't
answered in the FAQ.
Any chance of writing a little FAQ entry for us and getting it into
> Please read the FAQ at http://www.tux.org/lkml/
Maybe it could replace entry 9.5:
What's devfs and why is it a Good Idea (tm)?
:-)
NeilBrown
On Sunday 30 October 2005 22:35, Neil Brown wrote:
>
> > Please read the archives, this comes up every few months or so.
>
> ..thus making it a Frequently Asked Question. However it isn't
> answered in the FAQ.
I swear I've searched through them thoroughly, evidently not enough :^/
Greg, could you point me at the proper thread?
Thanks,
Bye,
--
Daniele Orlandi
On Sunday 30 October 2005 12:07, Daniele Orlandi wrote:
> Disclaimer: My knowledge about devfs/udev/sysfs is superficial,
Agreed.
> I see /dev as an abstraction layer above /sys, where udev implements the
> abstraction.
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:
http://kerneltrap.org/node/5347
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
footprint.
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
embedded use)...
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.
function makedev
{
? 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"`
do
? makedev -m 700 $i b $major $minor
? echo -n b
done
for i in `find /sys/class -name "dev"`
do
? makedev -m 700 $i c $major $minor
? echo -n c
done
You think implementing that in C would take more than 4k?
> Bye,
Rob
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rob Landley wrote:
> I'm pondering adding a micro-udev to busybox (it's fairly far down on the todo
> list).
snip
> function makedev
> {
> 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"`
> do
> makedev -m 700 $i b $major $minor
> echo -n b
> done
>
> for i in `find /sys/class -name "dev"`
> do
> makedev -m 700 $i c $major $minor
> echo -n c
> done
>
> You think implementing that in C would take more than 4k?
I'm certain that someone can do better than this, but here's a C version
that does it in 4684 bytes (stripped). It's simple, and runs fast. I'm
sure that someone could optimize this much further.
Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
[email protected]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFDZeIWaI0dwg4A47wRAiWgAJ9LzBcNhfrW5KHP9f8qg+spfGUSKwCdFTlw
grK0kedpIQ/JRDN2yMqLG4U=
=K4vE
-----END PGP SIGNATURE-----
On Sun, Oct 30, 2005 at 02:23:09PM -0800, Greg KH wrote:
> On Mon, Oct 31, 2005 at 08:18:12AM +1100, Neil Brown wrote:
> > But then to make matters worse, there is this "sample.sh" file. UGH!
> > It's a bit of shell code exported by the kernel.
> > #!/bin/sh
> > mknod /dev/hda b 3 0
>
> That's just a "joke" patch that is only in the -mm tree, as it gets
> pulled in from my tree. It's not in mainline, and will never go there.
Perhaps you can drop this horror now that Halloween has passed.
--
Mathematics is the supreme nostalgia of our time.
On Tue, Nov 08, 2005 at 10:41:32AM -0800, Matt Mackall wrote:
> On Sun, Oct 30, 2005 at 02:23:09PM -0800, Greg KH wrote:
> > On Mon, Oct 31, 2005 at 08:18:12AM +1100, Neil Brown wrote:
> > > But then to make matters worse, there is this "sample.sh" file. UGH!
> > > It's a bit of shell code exported by the kernel.
> > > #!/bin/sh
> > > mknod /dev/hda b 3 0
> >
> > That's just a "joke" patch that is only in the -mm tree, as it gets
> > pulled in from my tree. It's not in mainline, and will never go there.
>
> Perhaps you can drop this horror now that Halloween has passed.
Heh. But why? Is it causing problems for anyone?
thanks,
greg k-h
On Tue, Nov 08, 2005 at 10:51:01AM -0800, Greg KH wrote:
> On Tue, Nov 08, 2005 at 10:41:32AM -0800, Matt Mackall wrote:
> > On Sun, Oct 30, 2005 at 02:23:09PM -0800, Greg KH wrote:
> > > On Mon, Oct 31, 2005 at 08:18:12AM +1100, Neil Brown wrote:
> > > > But then to make matters worse, there is this "sample.sh" file. UGH!
> > > > It's a bit of shell code exported by the kernel.
> > > > #!/bin/sh
> > > > mknod /dev/hda b 3 0
> > >
> > > That's just a "joke" patch that is only in the -mm tree, as it gets
> > > pulled in from my tree. It's not in mainline, and will never go there.
> >
> > Perhaps you can drop this horror now that Halloween has passed.
>
> Heh. But why? Is it causing problems for anyone?
Someone else might take your joke seriously. Or worse yet, imitate it.
See C++.
--
Mathematics is the supreme nostalgia of our time.
Matt Mackall wrote:
> On Tue, Nov 08, 2005 at 10:51:01AM -0800, Greg KH wrote:
>
>>On Tue, Nov 08, 2005 at 10:41:32AM -0800, Matt Mackall wrote:
>>
>>>On Sun, Oct 30, 2005 at 02:23:09PM -0800, Greg KH wrote:
>>>
>>>>On Mon, Oct 31, 2005 at 08:18:12AM +1100, Neil Brown wrote:
>>>>
>>>>>But then to make matters worse, there is this "sample.sh" file. UGH!
>>>>>It's a bit of shell code exported by the kernel.
>>>>> #!/bin/sh
>>>>> mknod /dev/hda b 3 0
>>>>
>>>>That's just a "joke" patch that is only in the -mm tree, as it gets
>>>>pulled in from my tree. It's not in mainline, and will never go there.
>>>
>>>Perhaps you can drop this horror now that Halloween has passed.
>>
>>Heh. But why? Is it causing problems for anyone?
>
>
> Someone else might take your joke seriously. Or worse yet, imitate it.
> See C++.
>
It probably should be rewritten in C for efficiency.
;-) if you didn't guess...