No.
The real problem, in my opinion, is needing device numbers in the first
place, for stuff that really shouldn't use them.
I don't want to make allocation easy. In fact, I want to make it _harder_.
I like it being painful, because it should not be done.
I've seen _way_ too many instances of "let's create a special device" for
no good reason. For example, all the crap about mice was (and is) a
mistake. And that's the least of the problems. Some devices on the device
list are there mainly as just a way to hook in an ioctl or something. It's
sad, and it's wrong.
And I'm sorry, but I do NOT want to envision a future where you can say
"ok, majors in the range 512-576 are PPC-specific, and you can go wild".
Yes, it would make your job easier. But it would make for a BAD SYSTEM,
which is what _I_ care about.
We should encourage people to not need major numbers. It's easy. The
driver exports a /proc entry in /proc/driver/xxx or similar . Or the
driver writer says "if you want to use this device, use devfs", and
exports the name there.
Don't get the issue of "it would make my life easier" override the issue
of "it's the wrong thing to do".
Another example: all the stupid pseudo-SCSI drivers that got their own
major numbers, and wanted their very own names in /dev. They are BAD for
the user. Install-scripts etc used to be able to just test /dev/hd[a-d]
and /dev/sd[0-x] and they'd get all the disks. Deficiencies in the SCSI
layer made it impossible for a driver writer to be nice to the user, so
instead they got their own major numbers.
But again, you're arguing for _more_ badness. While I'm of the opinion
that we _already_ have too many major numbers, and we should realize that,
and not make it worse.
A 64-bit dev_t only makes it _easier_ to continue to be stupid about
things.
And that, btw, is the hallmark of "bloat". Bloat is not about being big.
Bloat is about being slow and stupid and not realizing that it's because
of design mistakes.
Linus
-
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/