> On Fri Dec 07, 2001 at 02:04:42PM -0800, H. Peter Anvin wrote:
>
>>It's clear a painful change is needed. **We don't have a choice.**
>>However, the fewer places we have to make source code changes the better.
>>
>
> Sure. I'm not arguing again the change. Just making sure
> everyone 100% understands that we have just thown any prayer of
> binary compatibility with anything less then 2.5.x....
>
> But lets look on the bright side though. Since we are going to
> be having a flag day _anyways_ we may as well make the most of
> it. I can think of 20 things off the top of my head that are
> being retained in the name of binary cmpatibilty that can easily
> move to the trash bucket. :)
>
> For example, I would _love_ for Linux to standardize syscall
> numbers across all architectures, guarantee that userspace gets
> the exact same stack setup for all arches, we might as well fixup
> proc, etc, etc, etc.
>
Not going to happen. Linux deliberately choose against that, because in
Linux, syscall numbers are generally (except x86) compatible with the
dominant vendor Unix on the platform.
>
> That works, and should prevent most major problems. Hmm. At
> least for cpio there are 6 chars worth of device info in there,
> so we coule easily go to 48 bits without RPM problems. Or redhat
> could fix rpm to use tarballs like debs do, and then we could go
> to 64 bit devices no problem.
>
The big stubling block seems to be NFSv2.
-hpa
-
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/