With sock_loan_thresh=4096, sb_lowat==sb_hiwat, and sowritable will never
be true (even if only a single byte is pending). Some programs (like screen)
expect select() to return that a socket is writable on a socket when there
is space to write to it. XXX: What is the right thing to do here?
Specifically eap but no midi, which makes sense if you want sound,
and umidi but no midi, which makes little sense but shouldn't fail the
build.
Suggest changing the evbarm conf files containing umidi but #midi
to comment out umidi as well (even though this fix should let them build).
make sillyrename (try to) use LINK operation rather than RENAME.
PR/33861 from Jed Davis. he provided the almost same patch.
according to him, it also happen to be what opensolaris does in this case.
from the PR:
> In nfs_rename(), if the destination appears to exist and is "in use"
> (this check is apparently satisfied even if the file isn't in use by
> anything except the rename itself), it will sillyrename it, then delete
> the sillyrenamed file even if the rename fails -- for instance, because
> the "from" file no longer exists on the server.
> mkdir a b; touch a/x; perl -e 'fork(); rename("a/x","b/x") or die "$!\n"'
>
> Afterwards, neither a/x nor b/x will exist.
> 1) Lookup of b/x; fails with NOENT.
> 2) Rename from a/x to b/x; succeeds.
> 3) Lookup of b/x; fails with NOENT.
> 4) Rename from b/x to b/.nfsA23a3; succeeds.
> 5) Rename from a/x to b/x; fails with NOENT.
> 6) Remove of b/.nfsA23a3; succeeds.
sequencer API definitions in sys/midiio.h (so there is a use example).
These produce the same (ABI) sequencer events as the OSS macros, but in
a more strongly-typed way; OSS API macros could be built on them and added
to the OSS compatibility header sys/soundcard.h but have not been, yet.
- generic soft interrupts (ie. use powerpc/softintr.c)
- interrupt event counters (using the ones from powerpc/cpu.h:cpu_info
where appropriate)
- cleanup ibm4xx_intr.h, move implementation details to intr.c
Convert all affected evbppc platforms.
OK by simonb@, some points discussed with matt@
