Re: 64-bit kdev_t - just for playing

Roman Zippel (zippel@linux-m68k.org)
Mon, 7 Apr 2003 22:10:11 +0200 (CEST)


Hi,

On 7 Apr 2003, H. Peter Anvin wrote:

> > This still doesn't answer what will come next. You must have _some_ idea,
> > otherwise you wouldn't add a new interface, remove other infrastructure
> > and provide a patch which modifies MKDEV & co. All of this only leads us
> > away from the goal of dynamic device numbers. Why?
> >
>
> I have an idea, why don't you read the archives of this mailing list
> for the past eight years and learn, once again, why dynamic numbers
> are broken for nearly all applications (disks and ptys being, perhaps,
> the few case where they actually work.)
>
> This has been hashed and rehashed on this list so many times it's not
> even funny.

I ignore the flame bait in the hopes to get a reasonable answer this time,
if you have a personal problem with me, you are free to tell me this
directly, but flaming will help nobody.

The dynamic number discussion I remember were not only about numbering but
also about naming. A specific device had to be addressable with a specific
number. We currently have a fixed mapping between numbers and names (as
documented in devices.txt). Disks are an area where this doesn't work, the
only exception is IDE, because most machines have a builtin controller,
so it's easy to map to a fixed number. SCSI already has to use dynamic
numbers, because it wouldn't otherwise fit into a 16bit dev_t and with SAN
even 64bit will not be enough. This makes SCSI very annoying, when at the
next boot everything has a new name, because a disk was added/removed.

Consequently it's impossible that the kernel guarantees a static name/
number for a specific device. devfs showed that the kernel is the wrong
place for name policies. Is see no other possibility than to number
devices dynamically and leave it to userspace to name them or did I miss
an important point in previous discussions?
Maybe you could also answer me, what exactly you need a 64bit dev_t for?
If anything of this has been discussed previously, I'd also be happy about
any URLs. Thanks.

bye, Roman

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