Re: udev and devfs - The final word

[Linus Torvalds <torvalds@osdl.org>]

On Tue, 6 Jan 2004, Andries Brouwer wrote:
> 
> Now compare our setups:
> 
> dev_t lbt_devno(void) { return random(); }

Actually, I'd have something like

	int nr;

	initialize()
	{
	#ifdef CONFIG_DEBUG_BAD_USERS
		nr = random();
	#endif
	}

	dev_t lbt_devno()
	{
		return nr++;
	}

since the numbers do have to be unique "per boot". They just shouldn't be 
considered "stable" _nor_ "meaningful".

> dev_t aeb_devno(char *s) { dev_t d = hash(s); while (inuse(d)) d++; return d; }
> 
> An earlier fragment of the discussion was concerned with the fact
> that random(); is a bad idea. Something reproducible is better.

And I've told you why reproducibility is a BAD THING, and why I disagree.

Basically, if you cannot 100% guarantee reproducibility (and nobody can,
not your hashes, not anything else), then the _appearance_ of 
reproducibility is literally a mistake. Because it ends up being a bug 
waiting to happen - and one that is very very hard to reproduce on a 
developer machine.

You seem to continually ignore this issue.

I'm  not going to bother arguign this for another week. I'm just going to 
state once and for all:

 - total device number reproducability is fundamentally impossible. It's 
   not just impossible in theory, it is impossible in practice too.
 - with that in mind, anything that depends on stable device numbers is a 
   BUG.
 - Thus all your arguments boil down to: "I want to encourage bugs".

My argument is that we should find and fix the bugs. And we should do so 
by making the lack of meaning of the device numbers as well-known as 
possible. And that shouldn't just be due to long and boring threads on the 
kernel mailing list, but by actually actively trying to trigger the bad 
cases.

Bugs are good at hiding, and then showing up at the most inopportune 
times when you can't debug them. It's much better to try to trigger them 
where a developer can see them, and you do that by doing strange things.

		Linus