An idea on devfs vs. udev

An idea on devfs vs. udev

[Daniele Orlandi]

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

Re: An idea on devfs vs. udev

[Neil Brown]

On Sunday October 30, daniele@orlandi.com 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

Re: An idea on devfs vs. udev

[Greg KH]

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

Re: An idea on devfs vs. udev

[Neil Brown]

On Sunday October 30, greg@kroah.com 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

Re: An idea on devfs vs. udev

[Matt Mackall]

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.

Re: An idea on devfs vs. udev

[Greg KH]

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

Re: An idea on devfs vs. udev

[Matt Mackall]

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.

Re: An idea on devfs vs. udev

[Bill Davidsen]

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...

Re: An idea on devfs vs. udev

[Rob Landley]

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

Re: An idea on devfs vs. udev

[Frank Sorenson]

[-- Attachment #1: Type: text/plain, Size: 1204 bytes --]

-----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
frank@tuxrocks.com
-----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-----

[-- Attachment #2: miniudev.c --]
[-- Type: text/x-csrc, Size: 2566 bytes --]

/*
* miniudev - implement a small udev that can run at bootup
* Copyright Frank Sorenson <frank@tuxrocks.com> 2005
*
* Permission is hereby granted to copy, modify and redistribute this code
* in terms of the GNU Library General Public License, Version 2 or later,
* at your option.
*
*/

#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <dirent.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <sys/sysmacros.h>

#define DEV_PATH	"/dev"
#define DEV_MODE	0700

int get_device_info(const char *path, int *major, int *minor)
{
	char buf[512];
	int fd;
	int ret;
	char *chr;
	char got_colon = 0;
	int tempval = 0;

	sprintf(buf, "%s/dev", path);
	fd = open(buf, O_RDONLY);
	ret = read(fd, buf, 1024);
	buf[ret - 1] = '\0';
	if (ret == 0)
		return -1;
	close(fd);

	chr = buf;
	while (*chr != '\0') {
		if (*chr == ':') {
			*major = tempval;
			tempval = 0;
			got_colon ++;
		} else {
			tempval *= 10;
			tempval += (*chr - '0');
		}
		chr ++;
	}
	*minor = tempval;

	return 0;
}

int make_device(const char *path, int type)
{
	char buf[512];
	const char *device_name;
	int major;
	int minor;
	int ret;
	int local_errno;

	device_name = path;
	while (*device_name != '\0')
		device_name ++;
	while ((*(device_name - 1) != '/') && (device_name > path)) {
		device_name --;
	}
	get_device_info(path, &major, &minor);
	printf("%s: %d %d\n", device_name, major, minor);

	sprintf(buf, "%s/%s", DEV_PATH, device_name);
	ret = mknod(buf, DEV_MODE | type, makedev(major, minor));
	if (ret != 0) {
		local_errno = errno;
		printf("Could not create device node %s: error %d\n", buf, local_errno);
	}

	return 0;
}

char cmp(const char *s1, const char *s2)
{
	int n = 0;

	while (s1[n] == s2[n]) {
		if (s1[n] == '\0')
			return 1;
		n++;
	}
	return 0;
}

int find_dev(const char *path, int type)
{
	DIR *dir;
	struct dirent *entry;
	char temp_path[512];
	int local_errno;

	dir = opendir(path);
	if (dir == NULL) {
		printf("Could not open path %s: error %d\n", path, local_errno);
		exit(-1);
	}

	do {
		entry = readdir(dir);
		if (entry == NULL)
			break;
		if (cmp(entry->d_name, "."))
			continue;
		if (cmp(entry->d_name, ".."))
			continue;
		if (entry->d_type == DT_DIR) {
			sprintf(temp_path, "%s/%s", path, entry->d_name);
			find_dev(temp_path, type);
		}
		if (cmp(entry->d_name, "dev")) {
			make_device(path, type);
		}
	} while (entry != NULL);
	closedir(dir);

	return 0;
}


int main(int argc, char *argv[])
{
	find_dev("/sys/block", S_IFBLK);
	find_dev("/sys/class", S_IFCHR);

	return 0;
}

Re: An idea on devfs vs. udev

[Greg KH]

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

Re: An idea on devfs vs. udev

[Neil Brown]

On Sunday October 30, greg@kroah.com 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

Re: An idea on devfs vs. udev

[Daniele Orlandi]

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