Re: udev and devfs - The final word

[Rob Landley]

On Monday 05 January 2004 17:13, Andries Brouwer wrote:
> An earlier fragment of the discussion was concerned with the fact
> that random(); is a bad idea. Something reproducible is better.

To find people making bad assuptions that will only break after widespread 
deployment, random() is much better than "usually reproducible".

> Let us abbreviate the above function f. Some driver determines that
> a disk has serial number A809ADGC. Another driver determines that
> some device was produced by HP but otherwise has no opinion.
> A third driver has no stable information at all about the device.
> They assign device numbers f("A809ADGC"), f("HP"), f("").
>
> What is the result? Yes, device numbers are cookies, but a reasonable
> attempt has been made to make the device numbers stable.

Should the same argument be made about process ID's?  When your system boots 
up, your daemons generally start in the same order.  But any script that 
depends on this is broken.

Or filehandles.  They're cookies.  There's whole pages on why it's a bad idea 
to make assumptions about what filehandles point to:

http://en.tldp.org/HOWTO/Secure-Programs-HOWTO/avoid-race.html

> No guarantees anywhere - this is best effort. Better than no effort.

You're suggesting that it should be easier to write things that are 
fundamentally unclean, and bake in assumptions that WILL break, but not on 
the developer's machine, only for end-users who aren't expecting it.

What's the advantage?  Making it easier for people to do something stupid?  
(You can sort of trust this thing we can't make any guarantees about.  Since 
when is "sort of trust" a condition that's encouraged?  At the very least, 
those kinds of cases are backed up by a detection and recovery mechanism and 
the whole thing's called a heuristic.)  Why is there a need for this?

Either the kernel can make a guarantee, or it should very much not make a 
guarantee.  Where is an example of a middle ground?

> And this information helps udev. It may make a callout superfluous,
> or even give udev information that cannot be obtained from userspace.

I'm waiting for the udev maintainer to weight in on this and say "no, it 
doesn't".  If there is information that "cannot be obtained from userspace", 
then we should fix the sysfs exports.  Encoding something in a semi-stable 
cookie and actually trying to USE that information is stupid.

What about kernel upgrades?  Future backwards compatability when developers 
change the device enumeration methods?  (The sata driver got completely 
rewritten from scratch, and now it detects devices in a wildly different 
order, but we need this shim layer for backwards compatability with a 
guarantee we never should have made because we encouraged old scripts to 
remain broken.)  This plants hidden land mines restricting future 
development.  You're basically proposing a whole "device number stabilization 
infrastructure" for future kernels if it's to have ANY meaning at all...

Where's the advantage?  Name a single real-world case that's more difficult to 
fix than it would be to make the kernel pander to it in perpetuity.

> Andries

Rob

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