Messages in this thread | | | From | "H. Peter Anvin" <> | Subject | Re: 64-bit kdev_t - just for playing | Date | 8 Apr 2003 16:56:00 -0700 |
| |
Followup to: <Pine.LNX.4.44.0304081607060.5766-100000@dlang.diginsite.com> By author: David Lang <david.lang@digitalinsight.com> In newsgroup: linux.dev.kernel > > the biggest problem I see with dynamic numbers is that it needs a > userspace devfs type solution for creating and maintaining the device > nodes that are then used. While this isn't rocket science it's also > somthing that is hard to get people to agree to (remember the devfs names > that everyone gripes about are not what richard started with it's what he > switched to to get things into the kernel, they changed many times during > that process) > > I don't think many people will argue that dynamic assignments are evil, > but I think you will find a lot of people very nervous about switching to > them and the risk involved with doing so. >
They aren't evil, they're just very, very hard to get right.
So far, *none* of the schemes used for dynamics have gotten it right. They just ignore a fair number of the problems. People keep focusing on disks, and they are nearly uniformly the almost-trivial case in comparison with especially character devices, where you don't have the layer of indirection called /etc/fstab, persistent labels, etc.
It is also independent of the need to switch to a larger dev_t. Claiming that we can squeeze more out of the existing device scheme if we have an ideal-world dynamic scheme is unrealistic because:
a) There are, genuinely, systems with more than 65,536 devices or anonymous mounts. That rules out the current dev_t just by itself.
b) Despite the fact that people have tried since the mid-90's, we still don't have a sane way to manage such dynamicity.
c) We are now in what pretty much amounts to a crisis situation. We have needed to enlarge dev_t for well over half a decade. Therefore, it is too late to say "well, given X we wouldn't need it." We need something done in *this* kernel cycle.
Given that it has taken, literally, 8 years to get to this point, and based on collective global experience with numberspaces, I'm arguing for enlarging it far more than anyone can currently imagine being necessary.
dev_t is already 64 bits in glibc, and the glibc<->kernel interface needs to be fixed *anyway*. We have to take the pain of migration, we might as well go all the way.
-hpa -- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64 - 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/
| |