Re: Someone using COMPAT_SVR4(_32) ?

Guus, Maxime,

compat_svr4 (with a sparc solaris 2.6 payload) works on Netbsd 5.2.3 sparc64
(released 15-NOV-2014), doesn't work on 6.0.6 sparc64 (released
22-SEP-2014). Tests performed with a GENERIC kernel.


Jerome

On Thu, Sep 7, 2017 at 12:38 PM, Guus Jansman <[email protected]> wrote:
> Hello Maxime,
>
>
> Our company used and still occasionally uses an old commercial
> cross-compiler and an EDA package for Solaris Sparc 32-bit.
>
> The Sparc hardware was dying and we managed to use NetBSD 5.2 with
> COMPAT_SVR4 on QEMU to keep using the packages. At that time Solaris could
> not be started on QEMU and besides that, NetBSD has some convenient
> low-power mode (so the CPU does not run at 100%).
>
> We are happy with it and thankful to the NetBSD and QEMU communities.
>
>
> So COMPAT_SVR4 is very useful to us but in your user case this may not mean
> much:
>
> Our company uses 32-bit Sparc
>
> Our company uses an old NetBSD version and have no intention to switch to a
> newer version
>
>
> I can imagine that other companies face the same problems. Some programs
> just have no open-source alternatives and if Solaris Sparc was chosen back
> in the time then you are out of luck now. I can not say whether COMPAT_SVR4
> has bit-rotten, is a dirty hack or is a development burden. If so then I can
> imagine that it should be removed. After all, NetBSD is an operating system
> on its own right and should not jump through hoops to emulate another. And
> one can always use an older NetBSD version that did support COMPAT_SVR4
> properly.
>
>
> But I felt it necessary to say that the option is being used.
>
>
> Guus
>
>
>
> ________________________________
> From: [email protected] <[email protected]> on
> behalf of Jerome Ibanes <[email protected]>
> Sent: Tuesday, September 5, 2017 3:29 PM
> To: Maxime Villard
> Cc: [email protected]
> Subject: Re: Someone using COMPAT_SVR4(_32) ?
>
> Maxime,
>
>> If someone is interested in keeping these features, he or she has to show
>> up within a month starting from now (date of the proposal). The minimum
>> requirement that such a maintainer would have to reach is demonstrating,
>> via patches or commits, that work is being done on improving the security
>> of
>> the features - fixing basic bugs, via audit for example - as well as their
>> reliability - being able to show the functioning of an SVR4 binary being
>> increased as a result of this work.
>> If no maintainer is forthcoming after a month, or the maintenance
>> threshold
>> is not met within a month, the code may be removed. It is to be noted that
>> the code will still be in the source code repository, should people wish
>> to
>> re-instate it in the future. If that should happen, the reasons for
>> removing
>> the code in the first place will have been addressed.
>
> Thanks for the head's up. I am looking into it and will hopefully come up
> with
> a patch to address this; but my time is very limited, and I would
> respectfully
> like to ask you to extend this deadline.
>
>
> Jerome