Re: removing SVR4 binary compatibilty layer

2017-02-15 Thread Peter Jeremy
On 2017-Feb-14 10:32:32 -0800, Gleb Smirnoff wrote: > After some discussion on svn mailing list [1], there is intention >to remove SVR4 binary compatibilty layer from FreeBSD head, meaning >that FreeBSD 12.0-RELEASE, available in couple of years would >be shipped without it.

Re: removing SVR4 binary compatibilty layer

2017-02-15 Thread mokhi
Well, I'd like to offer help keeping it (because on a personal opinion, I'd like being compatible `:-D). But the reasons are pretty reasonable and convincing :-). I have no more objections against removing it when security risks involves. -- Best wishes, MMokhi.

Re: removing SVR4 binary compatibilty layer

2017-02-15 Thread Poul-Henning Kamp
In message <20170215081430.gc58...@freebsd.org>, Gleb Smirnoff writes: >Well, we all "maintain" it, meaning that we keep it compilable. However, >I'm sure that no one checks the functionality. There are no regression >tests, and seems to be no users. And probably nobody ever bothered to

Re: removing SVR4 binary compatibilty layer

2017-02-15 Thread Gleb Smirnoff
On Wed, Feb 15, 2017 at 10:56:29AM +0330, mokhi wrote: m> Is this removing is because no-interest on maintaining it? m> m> If it helps, I am working to use the `kern_* instead sys_*` as m> mentioned patch in that discussion suggests for svr4, if this helps. Well, we all "maintain" it, meaning

Re: removing SVR4 binary compatibilty layer

2017-02-14 Thread mokhi
Hi, Is this removing is because no-interest on maintaining it? If it helps, I am working to use the `kern_* instead sys_*` as mentioned patch in that discussion suggests for svr4, if this helps. -- Best wishes, MMokhi. ___ freebsd-current@freebsd.org

removing SVR4 binary compatibilty layer

2017-02-14 Thread Gleb Smirnoff
Hello! After some discussion on svn mailing list [1], there is intention to remove SVR4 binary compatibilty layer from FreeBSD head, meaning that FreeBSD 12.0-RELEASE, available in couple of years would be shipped without it. There is no intention of merge of the removal. The stable@ mailing