interacts with the userspace file server:
* since the kernel-user communication is not purely request-response
anymore (hasn't been since 2006), try to rename some "request" to
"message". more similar mangling will take place in the future.
* completely rework how messages are allocated. previously most of
them were borrowed from the stack (originally *all* of them),
but now always allocate dynamically. this makes the structure
of the code much cleaner. also makes it possible to fix a
locking order violation. it enables plenty of future enhancements.
* start generalizing the transport interface to be independent of puffs
* move transport interface to read/write instead of ioctl. the
old one had legacy design problems, and besides, ioctl's suck.
implement a very generic version for now; this will be
worked on later hopefully some day reaching "highly optimized".
* implement libpuffs support behind existing library request
interfaces. this will change eventually (I hate those interfaces)
large enough for GOT to be larger than 8k.
While here kill redundant PIC ifdefs in setjmp.S - sparc "call"
instruction is piccy by itself.
Tested by martin@
of size constants for sparc64.
This code still produces many, many lint warnings due to "may loose accuracy"
when mixing long/int, and also warnings related to <<.
-falign-functions=32, since these two really get hammered on. To make them
faster needs a threadreg or TLS, unless there is a way to tell gcc that a
library-local (pthread__threadmask) variable does not need to be PIC.
preparing to sleep on a mutex are slow in relative terms, so this allows
us to recover from short lock holds without blocking, while not wasting
too much time on longer holds.
kernel to the file server for silly things the file server did,
e.g. attempting to create a file with size VSIZENOTSET. The file
server can handle these as it chooses, but the default action is
for it to throw its hands in the air and sing "goodbye, cruel world,
it's over, walk on by".
Can be used by applications that have their own SIGINT (et al)
handlers and want to exit in a manner that correctly
signals to the parent that the process was terminated by a signal.
See http://www.cons.org/cracauer/sigint.html for more info.
Discussed on tech-userlevel@.
architecture to provide asm versions of the RAS operations.
We do this because relying on the compiler to get the RAS right is not
sensible. (It gets alpha wrong and hppa is suboptimal)
Provide asm RAS ops for hppa.
(A slightly different version) reviewed by Andrew Doran.
