64-bit kdev_t - just for playing
Quoted 2 lines
Let's try it with a real example:
I have two onboard SCSI channels, the first one is for external
devices
Quoted 1 line
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.
Quoted 2 lines
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.
Quoted 1 line
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
Hi,
Quoted 9 lines · James Bottomley
Quoted 2 lines
Let's try it with a real example:
I have two onboard SCSI channels, the first one is for externaldevices
Quoted 1 line
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.
These examples were intended to show problems of the current dynamic and static numbering. I use examples like these to evaluate how a new numbering scheme helps to manage devices.
Quoted 10 lines
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_twill allow us to occupy only one major, for each SCSI device type, supply far more discs and still move to a 64 partition model.
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.
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.
Quoted 8 lines
Quoted 2 lines
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_tprecludes more dynamism in major number allocation.
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.
Quoted 3 lines
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.
Quoted 8 lines
Quoted 1 line
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.
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.
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.
Quoted 3 lines · Roman Zippel
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.
Quoted 4 lines
Simply start allocating from
0x10000and 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.
Quoted 3 lines
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.
Quoted 8 lines
Quoted 3 lines
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).
Quoted 5 lines
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_twill 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.
Quoted 4 lines
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
Hi,
Quoted 9 lines · James Bottomley
Quoted 3 lines
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.
[..]
Quoted 8 lines
Quoted 5 lines
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_twill 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_tin SCSI.
If you want to use only a single SCSI major, won't it change the device numbers? What will happen to setups, which already use more than 16 disks (but are still way below the 128 disk limit)?
Do you want to go to 64 partitions during 2.6? If yes, how? Won't that change the device numbers too?
Changes in these area require kernel policy, exactly like dynamic device numbers. If you want to maintain compatibility, you likely require user space support, exactly like dynamic device numbers. So why don't we even consider dynamic device numbers, especially as they have the promise of the simpler long term solution. The required kernel changes are certainly not more complex than the patches Andries got merged and still wants to get merged. If you actually look at the character device patches I posted, they already allow simple cleanups for 2.6.
Quoted 10 lines
Quoted 4 lines
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.
The only nontrivial missing piece is how we want to map the sysfs and other information to static device names. OTOH if you only need a solution for scsi now, it should be rather simple to expand scsidev. If you can live with dynamic device names (what scsi currently has), it's a simple shell script to generate the device nodes.
If you want to have thousands of disk, you need some kind of user support anyway, but I get surprisingly little answers, about how people want to actually manage that much devices? All I hear is "we want them and we want them now!", this makes it difficult to actually answer the question, how kernel should support this. In the kernel it's simpler to keep this dynamic, scsi does that already anyway. How will user space find these devices? Will it continue to scan thousands of nodes in /dev or will it just use the information already easily available via sysfs?
I know I'm asking a lot of annoying questions, but I have the feeling, that hardly anyone really thought all these problems through or someone withholds some important information (e.g. Peter's vague hints about "a fair number of the problems" for dynamic schemes or "collective global experience with numberspaces" don't really help without further explanation).
Considering all the information I currently have, dynamic device numbering is the better long term solution and is also usable for 2.6. I'm still looking for the deciding reason, which would give static device numbers a real advantage.
bye, Roman
Quoted 2 lines · Roman Zippel
If you want to use only a single SCSI major, won't it change the device numbers?
They will collapse down to a single major, yes. No application should be relying on knowing the device number, though (and if you are trying to argue that they do, you must see that in that scenario dynamic mapping is a total failure). Once /dev is rebuilt, no-one will know. Depending on whether people still dual boot 2.4 and 2.5, someone may also come up with a compatibility layer, but one is not required.
Quoted 4 lines
What will happen to setups, which already use more than 16 disks (but are still way below the 128 disk limit)?
Do you want to go to 64 partitions during 2.6? If yes, how? Won't that change the device numbers too?
It won't matter to a user application whether /dev/sdaa7 is 65,161 or 257,1667. As you should understand, since dynamic device numbers relies on this property.
Quoted 8 lines
Changes in these area require kernel policy, exactly like dynamic device numbers. If you want to maintain compatibility, you likely require user space support, exactly like dynamic device numbers. So why don't we even consider dynamic device numbers, especially as they have the promise of the simpler long term solution. The required kernel changes are certainly not more complex than the patches Andries got merged and still wants to get merged. If you actually look at the character device patches I posted, they already allow simple cleanups for 2.6.
Ah, OK, this may be the misunderstanding. Kernel dev_t can be expanded without any change to the current naming policy. The only change is the numbering in /dev, which is simple.
Quoted 8 lines
Quoted 5 lines
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.
The only nontrivial missing piece is how we want to map the sysfs and other information to static device names.
So we agree.
Quoted 4 lines
OTOH if you only need a
solution for scsi now, it should be rather simple to expand scsidev. If you can live with dynamic device names (what scsi currently has), it's a simple shell script to generate the device nodes.
But, as I've said before, not simpler than expanding kernel dev_t.
Quoted 8 lines
If you want to have thousands of disk, you need some kind of user support anyway, but I get surprisingly little answers, about how people want to actually manage that much devices? All I hear is "we want them and we want them now!", this makes it difficult to actually answer the question, how kernel should support this. In the kernel it's simpler to keep this dynamic, scsi does that already anyway. How will user space find these devices? Will it continue to scan thousands of nodes in /dev or will it just use the information already easily available via sysfs?
:-)
You take me back a decade to the "thirty two bits is enough for" everybody and "why would an application want more than 640k of memory"
Operating systems which impose arbitrary limits on their users, or demand cast iron justification before adding features tend to be at a competitive disadvantage.
However, if you want an example of how it works today, consider clustering tools: They have to identify the same piece of shared storage as it gets passed around a cluster. The way we do it (for a few hundred discs) is to get the SCSI WWN from all the discs (via sg, then map sg<->sd). Our application policy is to use the WWN to identify the device and a number for the partition. Other cluster tools use the volume label, still others use the LVM UUID.
The point is that none of these applications cares whether the kernel uses dynamic or static, all they need to do is be able to identify all the devices in the system.
Quoted 6 lines
I know I'm asking a lot of annoying questions, but I have the feeling, that hardly anyone really thought all these problems through or someone withholds some important information (e.g. Peter's vague hints about "a fair number of the problems" for dynamic schemes or "collective global experience with numberspaces" don't really help without further explanation).
I wouldn't characterise the questions like that. Not listening to the answers now...
Quoted 4 lines
Considering all the information I currently have, dynamic device numbering is the better long term solution and is also usable for 2.6. I'm still looking for the deciding reason, which would give static device numbers a real advantage.
No, dynamic device numbering may turn out to be the better long term solution. To justify "is", we'd have to be able to see the solution.
As far as SCSI is concerned, the complete solution has already been presented for the expansion of kernel dev_t, no such complete solution has been presented for dynamic devices. That constitutes a real advantage to dev_t expansion in my book.
James
Hi,
Quoted 9 lines · James Bottomley
Quoted 2 lines
If you want to use only a single SCSI major, won't it change the device numbers?
They will collapse down to a single major, yes. No application should be relying on knowing the device number, though (and if you are trying to argue that they do, you must see that in that scenario dynamic mapping is a total failure). Once /dev is rebuilt, no-one will know. Depending on whether people still dual boot 2.4 and 2.5, someone may also come up with a compatibility layer, but one is not required.
So we do break compatibility! Wow, it really took quite some time until someone confirmed this...
The problem now is that unfortunately programs do know about the device number (e.g. MAKEDEV, scsidev), these programs will be broken and have to be "fixed" so that they now have to change their behaviour depending on the kernel version.
This change will make it even more difficult for people to try a new kernel. I would say there are more people which use more than 16 disks than people who need more than 128 disks, but the former have to pay now for the latter?
OTOH it is possible to keep all device numbers below 0x10000 constant and start allocating dynamic device numbers from above 0x10000. This won't change anything for the current users and only people who want to go beyond the current limits have to update their tools (what they have to do in either case).
Quoted 9 lines
Quoted 8 lines
Changes in these area require kernel policy, exactly like dynamic device numbers. If you want to maintain compatibility, you likely require user space support, exactly like dynamic device numbers. So why don't we even consider dynamic device numbers, especially as they have the promise of the simpler long term solution. The required kernel changes are certainly not more complex than the patches Andries got merged and still wants to get merged. If you actually look at the character device patches I posted, they already allow simple cleanups for 2.6.
Quoted 3 lines
Ah, OK, this may be the misunderstanding. Kernel
dev_tcan be expanded without any change to the current naming policy. The only change is the numbering in /dev, which is simple.
The current numbering matches the naming, 0x0301 is /dev/hda1, 0x0802 is /dev/sda2 and 0x4103 is /dev/sdq3, the proposed patch does change the numbering _and_ naming policy.
Quoted 6 lines
Quoted 4 lines
OTOH if you only need a
solution for scsi now, it should be rather simple to expand scsidev. If you can live with dynamic device names (what scsi currently has), it's a simple shell script to generate the device nodes.But, as I've said before, not simpler than expanding kernel
dev_t.
This may be true in the kernel, but you move all the compatibility problems into user space and so we just added another ugly emulation layer.
Quoted 9 lines
Quoted 8 lines
If you want to have thousands of disk, you need some kind of user support anyway, but I get surprisingly little answers, about how people want to actually manage that much devices? All I hear is "we want them and we want them now!", this makes it difficult to actually answer the question, how kernel should support this. In the kernel it's simpler to keep this dynamic, scsi does that already anyway. How will user space find these devices? Will it continue to scan thousands of nodes in /dev or will it just use the information already easily available via sysfs?
Quoted 8 lines
:-)
You take me back a decade to the "thirty two bits is enough for" everybody and "why would an application want more than 640k of memory"
Operating systems which impose arbitrary limits on their users, or demand cast iron justification before adding features tend to be at a competitive disadvantage.
Splitting the device number into major and minor is such an arbitrary limit as well. If user space wants this it can do so, but it makes no sense in the kernel.
Quoted 11 lines
However, if you want an example of how it works today, consider clustering tools: They have to identify the same piece of shared storage as it gets passed around a cluster. The way we do it (for a few hundred discs) is to get the SCSI WWN from all the discs (via sg, then map sg<->sd). Our application policy is to use the WWN to identify the device and a number for the partition. Other cluster tools use the volume label, still others use the LVM UUID.
The point is that none of these applications cares whether the kernel uses dynamic or static, all they need to do is be able to identify all the devices in the system.
You cannot really compare the device number with other disk ids, because the device number is a purely local and dynamic number, while the other ids are global and static.
Quoted 4 lines
Quoted 1 line
I know I'm asking a lot of annoying questions,
I wouldn't characterise the questions like that. Not listening to the answers now...
Oh, I do listen, you can be sure of that, but what am I supposed to so, when it even takes weeks to get a clear answer about something simple as compatibility? When I ask questions, I get evading answers, when I say it's broken, I get silence, what else can I do?
Quoted 4 lines
As far as SCSI is concerned, the complete solution has already been presented for the expansion of kernel
dev_t, no such complete solution has been presented for dynamic devices. That constitutes a real advantage todev_texpansion in my book.
Producing a patch isn't that difficult, but I'd rather be interested, if there is even interest in such a patch? I already got not a single comment about the last patch.
bye, Roman
but the compatability layer can be as simple as having the new kernel recognise the old major/minor numbers and allocate the 'new' cleaned up majors in the range that the old numbers don't use.
or it could be that the new major number gets stored in a different spot on disk and the existing major/minor numbers become the new minor number with a major number of 0
either way it doesn't break compatability until people choose to use the new capibilities that they couldn't use otherwise, which is a reasonable thing to do.
nobody has claimed that MAKEDEV and similar wouldn't need to be changed, just that changing them is not a major deal, and is far less work then implementing dynamic numbering.
David Lang
Quoted 129 lines · Roman Zippel
Date: Fri, 11 Apr 2003 01:53:07 +0200 (CEST)
From: Roman Zippel <[email protected]>
To: James Bottomley <[email protected]>
Cc: Linux Kernel <[email protected]>
Subject: Re: 64-bitkdev_t- just for playingHi,
Quoted 9 lines · James Bottomley
Quoted 2 lines
If you want to use only a single SCSI major, won't it change the device numbers?
They will collapse down to a single major, yes. No application should be relying on knowing the device number, though (and if you are trying to argue that they do, you must see that in that scenario dynamic mapping is a total failure). Once /dev is rebuilt, no-one will know. Depending on whether people still dual boot 2.4 and 2.5, someone may also come up with a compatibility layer, but one is not required.
So we do break compatibility! Wow, it really took quite some time until someone confirmed this...
The problem now is that unfortunately programs do know about the device number (e.g. MAKEDEV, scsidev), these programs will be broken and have to be "fixed" so that they now have to change their behaviour depending on the kernel version.
This change will make it even more difficult for people to try a new kernel. I would say there are more people which use more than 16 disks than people who need more than 128 disks, but the former have to pay now for the latter?
OTOH it is possible to keep all device numbers below0x10000constant and start allocating dynamic device numbers from above0x10000. This won't change anything for the current users and only people who want to go beyond the current limits have to update their tools (what they have to do in either case).Quoted 9 lines
Quoted 8 lines
Changes in these area require kernel policy, exactly like dynamic device numbers. If you want to maintain compatibility, you likely require user space support, exactly like dynamic device numbers. So why don't we even consider dynamic device numbers, especially as they have the promise of the simpler long term solution. The required kernel changes are certainly not more complex than the patches Andries got merged and still wants to get merged. If you actually look at the character device patches I posted, they already allow simple cleanups for 2.6.
Quoted 3 lines
Ah, OK, this may be the misunderstanding. Kernel
dev_tcan be expanded without any change to the current naming policy. The only change is the numbering in /dev, which is simple.The current numbering matches the naming,
0x0301is/dev/hda1,0x0802is/dev/sda2and0x4103is/dev/sdq3, the proposed patch does change the numbering _and_ naming policy.Quoted 6 lines
Quoted 4 lines
OTOH if you only need a
solution for scsi now, it should be rather simple to expand scsidev. If you can live with dynamic device names (what scsi currently has), it's a simple shell script to generate the device nodes.But, as I've said before, not simpler than expanding kernel
dev_t.This may be true in the kernel, but you move all the compatibility problems into user space and so we just added another ugly emulation layer.
Quoted 9 lines
Quoted 8 lines
If you want to have thousands of disk, you need some kind of user support anyway, but I get surprisingly little answers, about how people want to actually manage that much devices? All I hear is "we want them and we want them now!", this makes it difficult to actually answer the question, how kernel should support this. In the kernel it's simpler to keep this dynamic, scsi does that already anyway. How will user space find these devices? Will it continue to scan thousands of nodes in /dev or will it just use the information already easily available via sysfs?
Quoted 8 lines
:-)
You take me back a decade to the "thirty two bits is enough for" everybody and "why would an application want more than 640k of memory"
Operating systems which impose arbitrary limits on their users, or demand cast iron justification before adding features tend to be at a competitive disadvantage.
Splitting the device number into major and minor is such an arbitrary limit as well. If user space wants this it can do so, but it makes no sense in the kernel.
Quoted 11 lines
However, if you want an example of how it works today, consider clustering tools: They have to identify the same piece of shared storage as it gets passed around a cluster. The way we do it (for a few hundred discs) is to get the SCSI WWN from all the discs (via sg, then map sg<->sd). Our application policy is to use the WWN to identify the device and a number for the partition. Other cluster tools use the volume label, still others use the LVM UUID.
The point is that none of these applications cares whether the kernel uses dynamic or static, all they need to do is be able to identify all the devices in the system.
You cannot really compare the device number with other disk ids, because the device number is a purely local and dynamic number, while the other ids are global and static.
Quoted 4 lines
Quoted 1 line
I know I'm asking a lot of annoying questions,
I wouldn't characterise the questions like that. Not listening to the answers now...
Oh, I do listen, you can be sure of that, but what am I supposed to so, when it even takes weeks to get a clear answer about something simple as compatibility? When I ask questions, I get evading answers, when I say it's broken, I get silence, what else can I do?
Quoted 4 lines
As far as SCSI is concerned, the complete solution has already been presented for the expansion of kernel
dev_t, no such complete solution has been presented for dynamic devices. That constitutes a real advantage todev_texpansion in my book.Producing a patch isn't that difficult, but I'd rather be interested, if there is even interest in such a patch? I already got not a single comment about the last patch.
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hi,
Quoted 3 lines · David Lang
nobody has claimed that MAKEDEV and similar wouldn't need to be changed, just that changing them is not a major deal, and is far less work then implementing dynamic numbering.
Dynamic numbering is simple (scsi does it already), the big problem is to manage a large number of devices in a scalable way and keeping as much as possible dynamic actually helps here.
bye, Roman
Quoted 2 lines · Roman Zippel
So we do break compatibility! Wow, it really took quite some time until someone confirmed this...
No, the current patch DOES NOT BREAK compatibility. Device
numbers from 00:00 to FF:FF are not munged in any way. As long as regular drivers don't expect anything else (eg, a new scsi driver that uses a new larger major), nothing is broken or changed.
Quoted 3 lines
The current numbering matches the naming,
0x0301is/dev/hda1,0x0802is/dev/sda2and0x4103is/dev/sdq3, the proposed patch does change the numbering _and_ naming policy.
The proposed patch changes none of it. Folks have proposed
other changes based upon it, but Andreas' patch as it stands (at least, last time I looked at it) does not break this.
Quoted 3 lines
This may be true in the kernel, but you move all the compatibility problems into user space and so we just added another ugly emulation layer.
Naming is entirely a userspace problem. It is also an extremely
hard problem. Consider that the UK folks will want /dev/disc and the US folks will want /dev/disk. That's before we even approach persistent naming.
Quoted 4 lines
Oh, I do listen, you can be sure of that, but what am I supposed to so, when it even takes weeks to get a clear answer about something simple as compatibility? When I ask questions, I get evading answers, when I say it's broken, I get silence, what else can I do?
I will repeat: The patch does not break compatibility, and any
discussion of new device spaces based on the larger number have been theoretical. If you had read the patch, you would have seen this.
Quoted 3 lines
Producing a patch isn't that difficult, but I'd rather be interested, if there is even interest in such a patch? I already got not a single comment about the last patch.
Propose a dynamic system. Show us your code. Until you do,
do not clutter the simple task of "expand the size of dev_t" with the orthogonal task of "how do we use this new dev_t".
Joel
Signature · 15 lines
"You cannot bring about prosperity by discouraging thrift. You cannot strengthen the weak by weakening the strong. You cannot help the wage earner by pulling down the wage payer. You cannot further the brotherhood of man by encouraging class hatred. You cannot help the poor by destroying the rich. You cannot build character and courage by taking away a man's initiative and independence. You cannot help men permanently by doing for them what they could and should do for themselves." - Abraham Lincoln Joel Becker Senior Member of Technical Staff Oracle Corporation E-mail: [email protected] Phone: (650) 506-8127
Hi,
Quoted 4 lines · Joel Becker
No, the current patch DOES NOT BREAK compatibility. Device
numbers from 00:00 to FF:FF are not munged in any way. As long as regular drivers don't expect anything else (eg, a new scsi driver that uses a new larger major), nothing is broken or changed.
Device number mapping _is_ changed, unless the driver is very careful. Look at the latest patch from Badari, now try to add more partition while maintaining compatibility and this has to be done for every driver!
Quoted 1 line
If you had read the patch, you would have seen this.
I did, but it's only half the story, how it will be used matters.
Quoted 5 lines
Quoted 3 lines
Producing a patch isn't that difficult, but I'd rather be interested, if there is even interest in such a patch? I already got not a single comment about the last patch.
Propose a dynamic system. Show us your code.
Again, scsi _is_ already dynamic, there is not much to propose, it just needs to be generalized and I did already show some code.
bye, Roman