On Mon, Dec 17, 2018 at 02:57:54PM +0100, Maxime Villard wrote:
> Should I re-start a fight about dropping COMPAT_SVR4? Because I keep finding
> bugs, and it's becoming tiring. Over time I've come across at least a good
> dozen of bugs in it, by just grepping through the tree searching for unrelate
> It's simply not useful any more.
can we refrain from making comments that may not be true?
no one here actually knows the truth of this. it may be that
once particular binary someone uses does still work. just
because there are bugs in it does not make it "broken" in the
sense it can't be use
In article ,
JaromÃr DoleÄ ek wrote:
>Le mar. 18 déc. 2018 à 13:16, Maxime Villard a écrit :
>> It is clear that COMPAT_SVR4 is completely buggy, but to be clear on the
>> use of the code:
>
>+1 to removal for COMPAT_SVR4, there is always attic.
>
>I remember I've been also doing some mechan
On Tue, Dec 18, 2018 at 06:20:12PM -, Michael van Elst wrote:
> thor...@me.com (Jason Thorpe) writes:
>
> > AFAIK, none of our m68k platforms ever had a "native" SVR4.
>
> http://en.wikipedia.org/wiki/Amiga_Unix
A donation of which is what made COMPAT_SVR4 on m68k possible. :-)
Not that I'd
thor...@me.com (Jason Thorpe) writes:
> AFAIK, none of our m68k platforms ever had a "native" SVR4.
http://en.wikipedia.org/wiki/Amiga_Unix
Also some hardware running NetBSD/mvme68k had a native SVR4.
AFAIK mac68k only got up to SVR3.
The compat code was also necessary to run some m68k SunOS bi
> On Dec 18, 2018, at 12:39 AM, Maxime Villard wrote:
>
> I've made one:
>
> http://wiki.netbsd.org/attic_museum/
>
> I took the entries from src/doc/CHANGES.
This is great, thanks.
-- thorpej
> On Dec 18, 2018, at 4:16 AM, Maxime Villard wrote:
>
> Judging by the configuration files:
>
> * COMPAT_SVR4 is available on sparc, sparc64, *68k, sun2, sun3, atari,
> hp300, amiga. This is in terms of files.svr4 inclusions. I suspect that
> a part of these inclusions were added automat
On Tue, Dec 18, 2018 at 08:53:54AM -0500, Thor Lancelot Simon wrote:
> They did _not_ cause measureable performance problems of any kind, and
> though it is theoretically possible to do this sort of thing via a
> tightly-protected userspace helper process, I prototyped that too and
> it gets very u
On Fri, Dec 14, 2018 at 03:19:45PM +0100, Joerg Sonnenberger wrote:
> On Thu, Dec 13, 2018 at 11:07:23PM +0900, Ryota Ozaki wrote:
> > On Thu, Dec 13, 2018 at 6:30 AM Joerg Sonnenberger wrote:
> > >
> > > On Thu, Dec 13, 2018 at 12:58:21AM +0900, Ryota Ozaki wrote:
> > > > Before that, I want to a
Le mar. 18 déc. 2018 à 13:16, Maxime Villard a écrit :
> It is clear that COMPAT_SVR4 is completely buggy, but to be clear on the
> use of the code:
+1 to removal for COMPAT_SVR4, there is always attic.
I remember I've been also doing some mechanical changes in the area in
past, and also encount
Le 18/12/2018 à 06:51, Martin Husemann a écrit :
On Mon, Dec 17, 2018 at 02:35:11PM -0800, Jason Thorpe wrote:
On Dec 17, 2018, at 2:00 PM, Maxime Villard wrote:
Now I'm re-putting the subject on the table, because, as if it wasn't
already glaringly obvious, COMPAT_SVR4 is broken beyond repair
Hi all,
I implemented a patch that make vioif(4) support multi-queue. And I have put
the patch on ftp.n.o. I used vioif(4) multiqueue on qemu-kvm on Linux kernel
4.19.5. And It seems to be working fine.
https://ftp.netbsd.org/pub/NetBSD/misc/yamaguchi/vioif_mutilq.patch
The summary of the modifi
Le 17/12/2018 à 23:35, Jason Thorpe a écrit :
On Dec 17, 2018, at 2:00 PM, Maxime Villard wrote:
Now I'm re-putting the subject on the table, because, as if it wasn't
already glaringly obvious, COMPAT_SVR4 is broken beyond repair. I keep
unintentionally finding bugs in it, and it just doesn't m
13 matches
Mail list logo
