Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]


Le 03/08/2017 à 18:23, Johnny Billquist a écrit :
Reading up on iBCS2, it seems like a misnomer to have that name for
the kernel compatibility. If I understand iBCS2 right, it's both a ABI
(which would then be SVR3?) and also specifications for file system layout
and other details, which is not at all controlled by any kernel option. So,
even with compat_ibcs2, we might not be compatible with iBCS2.

Like I said before. SVR3 and SVR4 makes more sense to me. iBCS(2) is other
stuff that don't make sense around here, in my opinion.

Yes, all things considered, it would be good to rename it. Being the x86
maintainer, I can easily remove the iBCS2 part in i386, because I'm 98% sure
it has strictly zero use case - x86 is the default architecture on most
machines out there these days, and any program running for SVR3 got time to
be ported to Linux, to be open sourced, or to have an equivalent we support
natively. This would leave only compat_svr3 on vax and compat_svr4 on

But CVS does not support renaming files, and it seems to me that we're going
to make the option even more difficult to explore (in the CVS logs) if we start
moving things around. Also, it involves renaming each function that begins with
ibcs2_. If I were the one to do this, I would also need someone to compile-test
the changes on vax. In short, that's some work, and unless someone here is
brave enough to do it, I don't feel like breaking stuff I don't use.

Also, I'm not sure that it is worth the effort, especially if this feature
happens to be used by no one; but that's a different issue.

What I can do, still, is removing ibcs2 from i386, and modifying the
compat_ibcs2 man page to say explicitly that in reality it stands for SVR3, and
it is available only on vax. Note that this would make compat_ibcs2 vax
specific, and would later allow to better compartmentalize the feature.

What about this?


Home | Main Index | Thread Index | Old Index