Hi!

It seems that FreeBSD pipes will fix the asynchornous I/O bug that
breaks the emulation of Linux JDK on the PowerPC (and it probably Opera,
RealPlayer, and probably other things as well).

I installed the new pipes, and my test program now behaves on NetBSD the
same way that it does on Linux, OpenBSD, FreeBSD and Solaris, when run
natively. Of course, when run as a Linux binary, it now emulates
accurately the Linux behavior.

The question now is that should we fix the async I/O semantic of the old
implementation, or should we rely on the new implementation? If we
choose the latter, then we must throw away the old implementation
completely, because having broken semantic on async signals is bad, but
having two different semantics is even worst.

If we choose to fix the old implentation, then I need some help. I can't
figure how to do it without breaking other things.

For Jaromir information: I had to patch sys/pipe.h and kern/sys_pipe.c
to build new pipes on macppc.
pipe.h, line 83: I don't know why, it complains at build time because
"variable-size type declared outside of any function". I wonder why it
is not satified with the macro, but I had to set the value by hand to
get it compiling.

-       vm_page_t       ms[PIPENPAGES];  /* pages in source process */
+       vm_page_t       ms[65];  /* pages in source process */

sys_pipc.c: This is more trivial: I had to add a NULL to the struct
fileops, in the fo_stat field. This field must have been added since you
submitted your patch.

Now, the bad news: I have only been able to test the new pipe code in
single user mode, because I cannot reach multiuser anymore:

(it's booting)
starting network
hostname: violette
domainname: hcpnet.local
trap type 10000 at 18330d4
Stopped in pid 23 (ifconfig) at  0x18330d4:     cmpi crf7, L, r31,
-0xffff,
db> trace
at db_disasm+34
at 0x4
at db_trap+140
at kdb_trap+ac
at trap+568
at ddblow+e0
at op_base+18
at db_disasm+34
at 0x4
at db_trap+140
at kdb_trap+ac
at trap+568
at ddblow+e0
at op_base+18
at db_disasm+34
(and this pattern reproduces thousand of times, I cannot see the end of
my stack)
db> ps
 PID       PPID       PGRP        UID S   FLAGS          COMMAND    WAIT
>23          18          8          0 7  0x4006         ifconfig
 18           8          8          0 3  0x4086               sh  piperd
 8            1          8          0 3  0x4086               sh    wait
 7            0          0          0 3 0x20204         aiodoned aiodone
 6            0          0          0 2 0x20604          ioflush
 5            0          0          0 3 0x20204           reaper  reaper
 4            0          0          0 3 0x20204       pagedaemon pgdaemo
 3            0          0          0 3 0x20204          mesh0:0  sccomp
 2            0          0          0 3 0x20204           esp0:0  sccomp
 1            0          1          0 3  0x4084             init    wait
 0           -1          0          0 2 0x20204          swapper
(Not sure this can be interesting, but...)
db> show registers
r0                   0
r1          0xe674de50
r2                   0
r3            0x99d0a8  end+0x580984
r4          0xe674de58
r5            0xa151d0  end+0x5f8aac
r6                   0
r7              0x9032  tlbdsmsize+0x8f4a
r8              0x4000  tlbdsmsize+0x3f18
r9            0x3d9898  defcorename+0x418
r10                  0
r11           0x928198  end+0x50ba74
r12                  0
r13                  0
r14                  0
r15                  0
r16                  0
r17                  0
r18                  0
r19                  0
r20                  0
r21                  0
r22                  0
r23                  0
r24           0x3d8974  sysent+0xd14
r25                0x8
r26              0x117  tlbdsmsize+0x2f
r27         0xe674df64
r28         0xe674df64
r29           0xa151d0  end+0x5f8aac
r30           0xa151d0  end+0x5f8aac
r31           0x99d0a8  end+0x580984
iar          0x18330d4  end+0x14169b0
msr             0xd032  tlbdsmsize+0xcf4a
 0x18330d4:     cmpi crf7, L, r31, -0xffff,
-- 
Emmanuel Dreyfus.
Si la reponse est NT, c'est probablement 
que vous n'avez pas compris la question.
p99dreyf@criens.u-psud.fr