Messages in this thread | ![/](/images/icornerl.gif) | | Subject | Re: 64-bit kdev_t - just for playing | From | James Bottomley <> | Date | 09 Apr 2003 13:40:36 -0500 |
| |
> Let's try it with a real example: > I have two onboard SCSI channels, the first one is for external devices > and the second for internal devices.
There seems to be some confusion here. As I understand it, you're advocating a completely dynamic device space (both major and minor), but the concrete examples you post come from devices that do dynamic minors only.
Thanks to the work of Al Viro and others, the problem of dynamic majors for block devices now lies predominantly in user space, but those problems are still significant.
As far as SCSI goes, in the current 8/8 device scheme, we occupy 16 different majors for sd already, but this only gives us room for 256 discs and we had to compromise and only have 16 partitions on each (as opposed to the 64 that IDE has). Even if you expand this (as there are patches to do), we get into trouble because we only have 256 sg nodes, etc.
Expanding the size of the kernel dev_t will allow us to occupy only one major, for each SCSI device type, supply far more discs and still move to a 64 partition model.
> I have to come back to the two questions I already asked earlier: > 1. How do we want to manage devices in the future?
Well, it's a legitimate question to ask, but not one anyone is required to answer. The whole "taste" thing in the kernel is about making correct decisions without necessarily seeing the ultimate end points. Enabling rather than dictating. Nothing about an expanded kernel dev_t precludes more dynamism in major number allocation.
However, there is already consideration of this issue, see for example:
http://www.linuxsymposium.org/2003/view_abstract.php?talk=94
If you have other contributions to make, I'm sure people will listen.
> 2. What compromises can we make for 2.6?
I think that's expand the kernel's device type but keep the current static major/static or dynamic minor. It seems to me, at this late stage in the game, that this will cause the minimum disruption and require the minimum of code changes, while still allowing us to satisfy the enterprise device demands. Pragmatically as well, we already have the patches for this, we don't for dynamic majors.
James
- 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/
| ![\](/images/icornerr.gif) |