On Sun, Jul 13, 2008 at 02:58:55PM +0100, Mindaugas Rasiukevicius wrote: > Greg Troxel <gdt%ir.bbn.com@localhost> wrote: > > To me, the binary compatibility issue is the biggest one - while running > > 0.8 binaries is perhaps no longer important, 5.0 kernel on 4.0 userland > > is still relevant. > > AFAIK, all you need is just to upgrade your libpthread, and your 4.0 userland > would work fine. Your old applications would work fine too. Actually, no. As others have noted, the 4.0 libc didn't have the right syscall stubs needed by the 1:1 libpthread, so this doesn't just work. Also, see: http://www.NetBSD.org/cgi-bin/query-pr-single.pl?number=38804 It seems there are incompatabilities between the size of a mutex in the old and new libraries. I gather it is now bigger? There is a clean fix, which is to bump the libpthread major number. However the 5.0 libpthread then isn't a drop-in replacement for the 4.0 one due to the major version bump. > But instead of that, you want to add ~3000 lines of code, which is quite > complex, and not very resistant to the DoS attacks. I am not convinced :) What DoS attack_s_? I'm aware of one, which is that SA really needs upcall stacks for things work & things go bonkers when there aren't enough. You can kill the errant app, but the SA system should probably handle this better. Are you aware of others? I ask because DoS is a _quite_ reasonable concern about adding the code. It however has a simple solution, which is to just kill the application if it gets into the upcall-generating code and we don't have a stack available. Take care, Bill
Attachment:
pgpMNUpQDMeJT.pgp
Description: PGP signature