Re: svr4, again
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 unrelated > things. The last one is this [1], while working on kcov, exit1() is called but > the proc mutex is not held. > > The thing is just broken beyond repair. > > It is dead wood that consumes APIs and makes stuff harder to change, just like > the network components we (thankfully) retired. > > [1] https://nxr.netbsd.org/xref/src/sys/compat/svr4_32/svr4_32_signal.c#661 +1 for removing compat
Re: svr4, again
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 mechanical changes in the area in >past, and also encountered things which were broken just by casual >browsing. Which I did not fix because I did not have "srv4" binary I >would need to run. It's simply not useful any more. Just remove it already :-) If we want it back we can resurrect it. christos
Re: svr4, again
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 had any particular use for it, let alone anyone else. - Klaus
Re: svr4, again
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 binaries. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: svr4, again
> 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
Re: svr4, again
> 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 automatically without real > testing (a bit like PMCs, where people copied the PMC logic in each > port without ever implementing the support for real), and that the only > use cases were sparc, sparc64 and i386. I can speak a little to this... There were commercially available SVR4 variants for m68k systems ... at the time, there was a pretty big push for parity among the m68k systems we supported (there were lots of dumb reasons why the user land binaries were inconsistent from one m68k platform to the next, and there was a concerted effort to address that over a couple of releases), so that likely explains why COMPAT_SVR4 was added to *all* of the m68k kernel configs Although, to be honest, I would be really shocked if it would have actually worked on Sun 2, because the 68010 lacks instructions and addressing modes that SVR4 would have almost certainly required (and is why we don't have shared libraries on our Sun 2 port, IIRC). AFAIK, none of our m68k platforms ever had a "native" SVR4. -- thorpej
Re: Importing libraries for the kernel
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 ugly, very fast -- the in-kernel way with a thread is, I > believe, better. Also note that it is pretty straight-forward to give such a thread the "right" to use the FPU (or similar PCUs) in the kernel. Martin
Re: Importing libraries for the kernel
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 ask about how to import cryptography > > > > libraries needed tor the implementation. The libraries are > > > > libb2[1] and libsodium[2]: the former is for blake2s and > > > > the latter is for curve25519 and [x]chacha20-poly1305. > > > > > > I don't really have a problem with Blake2s, but I have serious concerns > > > for doing asymmetric cryptography in the kernel. In fact, it is one of > > > the IMHO very questionable design decisions behind WireGuard and > > > something I don't want to see repeated in NetBSD. > > > > Can you clarify the concerns? > > Asymmetrical cryptography is slow and complex. On many architectures, > the kernel will only be able to use slower non-SIMD implementations. ECC We have an existing facility for doing slow cryptographic operations asynchronously in the kernel. Except where architectures have really fast, instruction-style hardware support for asymmetric crypto operations (and perhaps even there depending on operand size) this stuff should be done in a thread interfacing to the rest of the kernel through the existing opencrypto framework. That said, I believe we should have asymmetric crypto operations in the kernel for executable and security policy signing. In fact, I believe it strongly enough to have implemented it (interfaced via opencrypto as described above) twice -- but I don't own either implementation and thus can't contribute them. 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 ugly, very fast -- the in-kernel way with a thread is, I believe, better. -- Thor Lancelot Simon t...@panix.com "Whether or not there's hope for change is not the question. If you want to be a free person, you don't stand up for human rights because it will work, but because it is right." --Andrei Sakharov
Re: svr4, again
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 encountered things which were broken just by casual browsing. Which I did not fix because I did not have "srv4" binary I would need to run. It's simply not useful any more. Jaromir
Re: svr4, again
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. I keep unintentionally finding bugs in it, and it just doesn't make any sense to keep it to me. I'm far from authoritative on this, but I agree that it makes sense to remove it (I mean, jeez, if Christos isn't even using it... ;-). Me neither - last I tried on sparc64 it was only usefull for a very limited set of binaries and far from trivial to fix. There were bugs in the mmap emulation and newer Solaris needed additional syscalls for ld.elf_so. I put fixing it somewhere on my todo list (and even have some diagnostic kernel modificiations to make it print out more stuff before binaries fail), but the fixing part had no chance to bubble up into visibility of the front page there for a year or so and unlikely is going to happen anytime soon. Better fish to fry elsewhere... So I won't object removal from the sparc64 PoV. Martin It is clear that COMPAT_SVR4 is completely buggy, but to be clear on the use of the code: Both COMPAT_SVR4 and COMPAT_SVR4_32 are disabled by default; this was done following the DEFCON fiasco. 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 automatically without real testing (a bit like PMCs, where people copied the PMC logic in each port without ever implementing the support for real), and that the only use cases were sparc, sparc64 and i386. * COMPAT_SVR4_32 is available only on sparc64. MIPS has a svr4_machdep.c file, but it seems that there is no reference to it. At a first glance it looks like dead code that is not compiled. Each architecture has an MD device-major for svr4_net, even when the arch doesn't support COMPAT_SVR4. This too looks like dead code.
RFC: vioif(4) multiqueue support
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 modification is follows: - vioif(4) - Set VIRTIO_NET_F_MQ bit to a features the driver requests - Allocate resources related to rx queue and tx queue - The number of the resources is written into the configuration registers - Send VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command to the device - For the command, vioif_ctrl_mq_vq_pairs_set() is newly added - Introduce vioif_transmit() - virtio(4) - Added virtio_child_attach_set_vqs() for setup of a virtqueue array after doing virtio_child_attach_start() - Enable per-vq MSIX vector when the child device uses multiqueue Do you have any questions or comments about the patch? Yamaguchi
Re: svr4, again
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 make any sense to keep it to me. I'm far from authoritative on this, but I agree that it makes sense to remove it (I mean, jeez, if Christos isn't even using it... ;-). Again, as with drivers that we retire, I also think it makes sense to document in an obvious location in the source tree where it can be found if someone goes looking for it (like "hey, if you check out this tag, you can get the last version of it before it was removed") sort of thing. That way, if someone wants to put their money where their mouth is and actually fix it, then they can't complain that you made it hard to find. Couvrez-vous le cul, oui? -- thorpej I've made one: http://wiki.netbsd.org/attic_museum/ I took the entries from src/doc/CHANGES.
