Re: 64-bit kdev_t - just for playing

[James Bottomley <James.Bottomley@steeleye.com>]

On Wed, 2003-04-09 at 15:54, Roman Zippel wrote:
> Why do we need majors at all? There is no perfect way to partition the 
> device number, it will always be some compromise. This partitioning 
> creates more problems than it solves.

Because without them we need a user space tool or kernel policy add on
that doesn't yet exist.

> Simply start allocating from 0x10000 and you can have (2^32-2^16)/partnr 
> block devices.
> The sg nodes problem is also easy to solve, but it requires the character 
> device hash Andries removed.

But, isn't that, in part, the point of this discussion.  Sg with no code
changes will stand the expansion of the kernel dev_t.  There is only a
problem if you want the device numbers dynamically assigned.

> So let's "taste" a few ideas. I don't want any decision, I want to get a 
> discussion started, which explores some of the possibilities, so that we 
> have _some_ idea of what we need.

That discussion doesn't have much to do with the size of the kernel
dev_t, though.  For dynamic devices, it's just a number.

> > However, there is already consideration of this issue, see for example:
> > 
> > http://www.linuxsymposium.org/2003/view_abstract.php?talk=94
> 
> I'd love to see this implemented and I would certainly like to help, but 
> I'm mostly interested in the kernel side of this.
> I haven't found much information about this, so it's difficult to comment 
> on this.

Erm, I'm afraid I believe the idea to be based on leveraging the
existing infrastructure, so I'd be surprised if much kernel work were
required (well beyond what is already planned for hotplug, anyway).

> These "enterprise device demands" certainly shouldn't break existing 
> setups? The patches I've seen from Andries so far do exactly this.
> What I'm mostly trying to get out of this discussion is how this large 
> dev_t will be used during 2.6, as this requires decisions now, I'd like 
> to know and talk about the possible consequences.

I don't see how the current patches break anything, yet.  I've already
said how I plan to use a larger kernel dev_t in SCSI.

> In this mail 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=104928874409158&w=2
> I demonstrated how new device numbers can be generated, without breaking 
> backwards compatibility, it's quite trivial to complete this patch.

I said in my last mail that "thanks to the work of Al Viro and others,
the problem of dynamic majors for block devices lies predominantly in
user space".  The piece that you label "trivial" is the missing
character device and user space components.  I don't happen to believe
it is at all trivial, but you're welcome to prove me wrong.

James