Re: udev and devfs - The final word

Linus Torvalds
2004-01-05T23:34:26Z

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