lkml.org 
[lkml]   [2004]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: udev and devfs - The final word


On Mon, 5 Jan 2004, Andries Brouwer wrote:
>
> > udev can then use those serial numbers to have a stable pathname
>
> True. Provided that it knows how to get them.

And that is the _only_ thing that the "device number" actually is. It is a
cookie that the kernel has allocated for the device that the kernel knows
about. Nothing more.

Go back and read my emails. Device numbers cannot have any meaning, they
literally are _only_ useful as cookies.

> The kernel driver knew all about the device.

No. The kernel driver knows _of_ the device, it does not know "all about"
the device. And that's a big difference.

Quite often the kernel only knows that it found "a device". It has very
limited knowledge about what the device is, and what it can do. That's why
we have tools like "smartd" etc, that know a lot more about devices than
the kernel often does.

In particular, the kernel driver knows _nothing_ about potential serial
numbers or how to read them for different classes of devices.

> Must udev also know all about all possible devices? Do I/O to these devices?
> Or must sysfs export all data that could possibly be used?

There is nothing to export. You seem to imply that the kernel somehow
knows more than user space, but the reverse is generally true.

In particular, the kernel should never have policy encoded in it, and
naming of a device is about pretty much nothing _but_ policy. Stuff that
the kernel literally has _zero_ knowledged about.

Yes, the kernel knows the physical location, but that doesn't actually
help the kernel itself. It's exported through sysfs, yes, and udev,
together with the hotplug stuff, can be used to make up the "stable name".

Have you even _tried_ udev? Udev can do exactly things like find UUID's
off disks - something the kernel doesn't have a _clue_ about. When the
kernel sees a disk, it's just a disk. The kernel doesn't know if there is
an UUID embedded on the disk, and the kernel SHOULD NOT HAVE A POLICY to
try to find one.

But for user space, the thing is trivially done: the kernel will notify
user space about the fact that it found a device (without necessarily
knowing what the heck the device is - quite common with USB or specialty
SCSI devices). The kernel pretty much doesn't know _anything_ about things
like laser range finders, cameras etc. It ends up classifying the device
on a very rough level, nothing more.

And without knowing practically _anythign_ about the device, it still has
to allocate a device number. Exactly so that somebody else can come around
and poke at it, and maybe know that "ahh, this device is a USB-attached
camera" or similar.

Do you not see that fundamental issue? The kernel has to allocate a number
before a UUID or anythign else is necessarily available.

The UUID/serial number/type policy comes _later_.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2009-11-18 23:46    [W:2.192 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site