Re: Wrapping jiffies [was Re: udev and devfs - The final word]

Re: Wrapping jiffies [was Re: udev and devfs - The final word]

[Norman Diamond]

Pavel Machek wrote:

> BTW, as we are currently in stable series, it might be good idea to
> make jiffies start at zero...

I disagree.  The importance of fixing bugs does not decrease in stable.
Hiding bugs is still the opposite of fixing bugs.

Perhaps I misunderstand the meaning of stable, but I expected stable to mean
that efforts tend more towards fixing things so they work properly, and
unstable meant that efforts tend more towards adding features even though
they're broken at first.  Hiding a broken thing is still the opposite of
fixing a broken thing.

> Hopefully jiffie wrap had enough testing during stable...

I think you mean unstable, in which case I agree with this half of what I
think you meant.  This still doesn't give any reason to switch back to
hiding things.  In fact this doesn't give any reason to switch from a
technique that "hopefully [...] had enough testing" to a different
technique, even if logically the different technique doesn't need as much
testing.

Re: udev and devfs - The final word

[Andries Brouwer]

On Wed, Dec 31, 2003 at 03:19:22PM -0500, Rob Love wrote:

> We can get to the point where we don't even need the explicit concept of
> device numbers, but just "any old unique value" to use as a cookie.  The
> kernel can pull that number from anywhere, and notify user-space via
> udev ala hotplug.

My plan has been to essentially use a hashed disk serial number
for this "any old unique value". The problem is that "any old"
is easy enough, but "unique" is more difficult.
Naming devices is very difficult, but in some important cases,
like SCSI or IDE disks, that would work and give a stable name.

The kernel must not invent consecutive numbers - that does not
lead to stable names. Setting this up correctly is nontrivial.

Re: udev and devfs - The final word

[Rob Love]

On Wed, 2003-12-31 at 19:15, Andries Brouwer wrote:

> My plan has been to essentially use a hashed disk serial number
> for this "any old unique value". The problem is that "any old"
> is easy enough, but "unique" is more difficult.
> Naming devices is very difficult, but in some important cases,
> like SCSI or IDE disks, that would work and give a stable name.

Yup.

> The kernel must not invent consecutive numbers - that does not
> lead to stable names. Setting this up correctly is nontrivial.

This is definitely an interesting problem space.

I agree wrt just inventing consecutive numbers.  If there was a nice way
to trivially generate a random and unique number from some
device-inherent information, that would be nice.

	Rob Love

Re: udev and devfs - The final word

[Rob Landley]

On Wednesday 31 December 2003 18:31, Rob Love wrote:
> On Wed, 2003-12-31 at 19:15, Andries Brouwer wrote:
> > My plan has been to essentially use a hashed disk serial number
> > for this "any old unique value". The problem is that "any old"
> > is easy enough, but "unique" is more difficult.
> > Naming devices is very difficult, but in some important cases,
> > like SCSI or IDE disks, that would work and give a stable name.
>
> Yup.
>
> > The kernel must not invent consecutive numbers - that does not
> > lead to stable names. Setting this up correctly is nontrivial.
>
> This is definitely an interesting problem space.
>
> I agree wrt just inventing consecutive numbers.  If there was a nice way
> to trivially generate a random and unique number from some
> device-inherent information, that would be nice.
>
> 	Rob Love

Fundamental problem: "Unique" depends on the other devices in the system.  You 
can't guarantee unique by looking at one device, more or less by definition.

Combine that with hotplug and you have a world of pain.  Generating a number 
from a device is just a fancy hashing function, but as soon as you have two 
devices that generate the same number independently (when in separate 
systems) and you plug them both into the same system: boom.

Now if you don't care about hotplug, it gets a little easier.  You can have a 
collission handler that does some kind of hashing thing, figuring out which 
device needs to get bumped and bumping it.  (As long as it consistently picks 
the same victim, you're okay, although that in and of itself could get 
interesting.  And if you remove the earlier device it conflicted with and 
reboot, the device could get renumbered which is evil...)

Of course the EASY way to deal with collisions is to just fail the hash thingy 
in a detectable way, and punt to some kind of udev override.  So if you yank 
a drive from system A, throw it in system B, try to re-export it NFS, and 
it's not going to work, it TELLS you.

Solve 90% of the problem space and have a human deal with the exceptions.  How 
big's the unique number being exported, anyway?  (If it's 32 bits, the 
exceptions are 1 in 4 billion.  It may never be seen in the wild...)

Rob

Re: udev and devfs - The final word

[Rob Love]

On Thu, 2004-01-01 at 07:34, Rob Landley wrote:

> Fundamental problem: "Unique" depends on the other devices in the system.  You 
> can't guarantee unique by looking at one device, more or less by definition.

Of course.

> Combine that with hotplug and you have a world of pain.  Generating a number 
> from a device is just a fancy hashing function, but as soon as you have two 
> devices that generate the same number independently (when in separate 
> systems) and you plug them both into the same system: boom.

A solution would have to deal with collisions.

> Of course the EASY way to deal with collisions is to just fail the hash thingy 
> in a detectable way, and punt to some kind of udev override.  So if you yank 
> a drive from system A, throw it in system B, try to re-export it NFS, and 
> it's not going to work, it TELLS you.

No no no.  Nothing this complicated.  No punting to udev.

> Solve 90% of the problem space and have a human deal with the exceptions.  How 
> big's the unique number being exported, anyway?  (If it's 32 bits, the 
> exceptions are 1 in 4 billion.  It may never be seen in the wild...)

Device numbers are 64-bit now.

	Rob Love

Re: udev and devfs - The final word

[Andries Brouwer]

On Thu, Jan 01, 2004 at 10:22:53AM -0500, Rob Love wrote:

> Device numbers are 64-bit now.
> 
> 	Rob Love

I am afraid I have to disappoint you. I made them 64-bit,
and I think they were 64-bit for a few months in the -mm tree,
forgot the details, but unfortunately Al went back to 32-bit again.

Re: udev and devfs - The final word

[Rob Love]

On Thu, 2004-01-01 at 10:48, Andries Brouwer wrote:

> I am afraid I have to disappoint you. I made them 64-bit,
> and I think they were 64-bit for a few months in the -mm tree,
> forgot the details, but unfortunately Al went back to 32-bit again.

You did disappoint me!  My heart is crushed and my aspirations for the
future ruined.

But you are right, dunno what I was thinking.

	Rob Love

Re: udev and devfs - The final word

[Linus Torvalds]

On Thu, 1 Jan 2004, Rob Love wrote:
>
> On Thu, 2004-01-01 at 10:48, Andries Brouwer wrote: 
> > I am afraid I have to disappoint you. I made them 64-bit,
> > and I think they were 64-bit for a few months in the -mm tree,
> > forgot the details, but unfortunately Al went back to 32-bit again.
> 
> You did disappoint me!  My heart is crushed and my aspirations for the
> future ruined.
> 
> But you are right, dunno what I was thinking.

Note that one reason I didn't much like the 64-bit versions is that not 
only are they bigger, they also encourage insanity. Ie you'd find SCSI 
people who want to try to encode device/controller/bus/target/lun info 
into the device number. 

We should resist any effort that makes the numbers "mean" something. They 
are random cookies. Not "unique identifiers", and not "addresses".

The unique identifiers you get from things like udev, using contents of
the device itself or user preferences etc. That's outside the scope of the
kernel. The addresses you get from /sys.

		Linus

Re: udev and devfs - The final word

[Andries Brouwer]

On Fri, Jan 02, 2004 at 12:42:41PM -0800, Linus Torvalds wrote:

Hi Linus - A happy 2004 !


> Note that one reason I didn't much like the 64-bit versions is that not 
> only are they bigger, they also encourage insanity. Ie you'd find SCSI 
> people who want to try to encode device/controller/bus/target/lun info 
> into the device number. 

Weak. "We don't want this power that has good uses because it also
can be used stupidly." That is not Unix-style.

> We should resist any effort that makes the numbers "mean" something. They 
> are random cookies. Not "unique identifiers", and not "addresses".

Random cookies? I prefer "arbitrary" over "random". The value plays no role
at all, but it must be unique, preferably stable across reboots.

Andries

Re: udev and devfs - The final word

[Linus Torvalds]

On Sat, 3 Jan 2004, Andries Brouwer wrote:
> 
> > Note that one reason I didn't much like the 64-bit versions is that not 
> > only are they bigger, they also encourage insanity. Ie you'd find SCSI 
> > people who want to try to encode device/controller/bus/target/lun info 
> > into the device number. 
> 
> Weak. "We don't want this power that has good uses because it also
> can be used stupidly." That is not Unix-style.

No.

That's not the argument: the argument is that the _only_ thing that 64-bit 
stuff can be used for is stupid things.

For everything else, a 32-bit dev_t is sufficient.

And the UNIX way is definitely: "do one thing, and do it well" and "small
is beautiful". It has _never_ been "overdesign everything to accomodate
stupidity".

You may have confused UNIX with Multics. Where overdesign was the rule, 
not the exception.

> > We should resist any effort that makes the numbers "mean" something. They 
> > are random cookies. Not "unique identifiers", and not "addresses".
> 
> Random cookies? I prefer "arbitrary" over "random". The value plays no role
> at all, but it must be unique, preferably stable across reboots.

Don't use "unique". It has way too many connotations of _true_ uniqieness 
in computer science.

And the operative word in "preferably stable across reboots" is
"preferably". Because it basically cannot be in the general case (it 
can't be unique for things that aren't enumerable, and clearly a lot of 
things aren't), and thus nothing must ever _assume_ it is.

And the thing is, to break those wrong assumptions (that are true in many
common cases, but are _not_ true in the rare general case), we may have to
actively do things that are "silly" on purpose. For example, for 
debugging, we start the "jiffies" counter not at zero, but at -300. That's 
patently _silly_, but it was very useful in finding the cases where the 
rare general case was not handled correctly.

Similarly, I'll probably advocate at some point (when distributions are
using udev) that we purposefully try to make device numbers _unstable_
across reboots, to find cases that do the wrong thing and have things
hardcoded. Exactly to find and fix them, so that the distribution works 
correctly even when things aren't enumerable.

(As to examples of inumerable devices, iSCSI comes to mind. As does pretty 
much anything else that is connected over IP - you can't even enumerate 
according to path or IP, since those may change too).

		Linus

Wrapping jiffies [was Re: udev and devfs - The final word]

[Pavel Machek]

Hi!

> actively do things that are "silly" on purpose. For example, for 
> debugging, we start the "jiffies" counter not at zero, but at -300. That's 
> patently _silly_, but it was very useful in finding the cases where the 
> rare general case was not handled correctly.

BTW, as we are currently in stable series, it might be good idea to
make jiffies start at zero... Hopefully jiffie wrap had enough testing
during stable...

								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]