Date: Fri, 17 Apr 2015 11:25:32 -0600 From: Warner Losh <imp@bsdimp.com> To: Peter Wemm <peter@wemm.org> Cc: John Baldwin <jhb@freebsd.org>, Oliver Pinter <oliver.pinter@hardenedbsd.org>, Konstantin Belousov <kostikbel@gmail.com>, "freebsd-arch@freebsd.org" <arch@freebsd.org>, Stefan Esser <se@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: Removal of the 6.x kernel compat code from libc Message-ID: <F9A778D2-1E22-4536-80F4-A01FDE85D78F@bsdimp.com> In-Reply-To: <2754569.tvBmmIXdDx@overcee.wemm.org> References: <20150417075942.GI2390@kib.kiev.ua> <5531059F.4060500@freebsd.org> <14081053.n6WdaDRXXc@ralph.baldwin.cx> <2754569.tvBmmIXdDx@overcee.wemm.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
> On Apr 17, 2015, at 11:10 AM, Peter Wemm <peter@wemm.org> wrote:
>
> On Friday, April 17, 2015 09:28:24 AM John Baldwin wrote:
>> On Friday, April 17, 2015 03:07:43 PM Stefan Esser wrote:
>>> Could we get rid of check_utility_compat(3) on that occasion?
>>>
>>> It is only used (AFAIK) to select FreeBSD-4 compatible behaviour of
>>> expr(1), which can also be selected with option "-e" and env variable
>>> COMPAT_EXPR.
>>>
>>> I doubt that anybody relies on non-POSIX behaviour that has been
>>> deprecated for some 15 years ...
>>>
>>> We'll need to preserve a stub function for check_utility_compat(3),
>>> I'm afraid, but I think we can remove the environment variable and
>>> the actual checking for a sym-link named "/etc/compat-FreeBSD-4-util"
>>> at startup of expr. (I bet, nobody even knew that the behaviour of
>>> expr could be changed with above sym-link ...)
>>>
>>> If there is consensus, I could prepare a patch to remove the check
>>> and to update the man-page for expr (just for -CURRENT, no MFC).
>>
>> I would not be surprised if Y!BSD depends on this and uses it in 11 FWIW. :)
>
> I'm sorry to say, but yes. We do actually us this on 10.x and 11.x at work,
> although it's worse than you can imagine. I just did a quick diff and I see:
>
> ==== //depot/vendor/FreeBSD/stable/10/bin/expr/expr.y#2 (text+ko) -
> //depot/yahoo/ybsd_10/src/bin/expr/expr.y#3 (text+ko) ==== content
> @@ -270,6 +270,8 @@
> int c;
>
> setlocale(LC_ALL, "");
> + if (getenv("NO_EXPR_COMPAT") == NULL)
> + setenv("EXPR_COMPAT", "1", 1);
> if (getenv("EXPR_COMPAT") != NULL
> || check_utility_compat("expr")) {
> av = argv + 1;
>
> I'm not going to do an annotate to see who did that.. However, we can
> maintain patches locally if needed.
>
> I'm not even sure *why* its there. I might have removed the code that
> depended on it. Let me do some research. With a bit of luck, it might be
> academic for us now.
For some reason, I’m happier you said you were using the expr hack rather
than running new libc on ancient kernels… Both fill me with horror, but I guess
the expr one is less horrific somehow...
Warner
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJVMUINAAoJEGwc0Sh9sBEAPFMQAOmK33qnVYMBOfaZd5JTgMjw
D/aIEfnXisSFEGnhPQk7hfwYsjbhE+21ExPiHzzD6PRX9J6JGdvlihO0Ax3Zfpx5
Zker1VYIF0KQn9V0lz6jjbDJvYgMQ3OsDBXd5OqlUq8JlYOXMtRGV+qFG4iYY31Q
gb8rOVRqkZcUhJdplwryEh+K4feZkyJEIoAIvn0+7l3Ry3o+qUVvoNyL1nxqxM11
CjPkQMao7GMf5YRXOUJWAhqcojlbfNtFl8GSGOHStJIBHSaFnbcJsZ3+z87flXrc
bEIj7v20elpVZDmML3QCayKM47KSYbFpyI+J5R4a9m7Up00zunSizxi/RA/X6V9M
DCePJMSCCNDAEh9XUyxMpPdG8RA3ASjS7WGFAVdtRGrwvGpH8Y8IslsbSVWZgMep
0Ka8I8oc+2pk7z0OSyxFE2ftEDowsgXkd6WDvwX6oWT7jW//v2awFG/F5MjDw1o7
aX0cK27knQ7V3R07QMW7bzTuSzzhqnSEnYkp0nfVC0bRwCX7WsbYcyYZp3qK81Sl
0Dls0GE1sc0gpNblL8wuLRIphvsw9uubWZI/FOl64sV31Feqry9VxaKkHdmRNSUJ
cymJ8+REwpwlE+lnqQnsCNOaqY6w9g0nAvfLlBbQN9Cpk/g75hAkVtQ6eV+aKzN+
drVtbeeFrQnTFvQFW6HW
=RpUA
-----END PGP SIGNATURE-----
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F9A778D2-1E22-4536-80F4-A01FDE85D78F>