All of these requests share the same message type as at least one server
manages those requests in the same handler, just by checking the actual
type of the request, and then acting upon it.
Change-Id: I17337b4c67ae209523574c22ccc108cf5f1e65e9
These two request are handled by the same function in some FSes, which
prevents us from using two different kinds of messages.
Change-Id: Ib2fc80bdd56ef67db6b4c51cf8963353a761aab1
These two request are handled by the same function in some FSes, which
prevents us from using two different kinds of messages.
Change-Id: Iede3a0251d8d84ca7f121c56f30f42b045b0c737
This implements a near noop setpgid, unless the use is one equivalent
to setsid, in which case it will behave as such.
Also activates setpgrp, which is implemented in terms of setpgid.
Change-Id: I84411cb1957351aa1d3985623cd9e69bdf6f8d4c
The goal is to prevent a name collision with the expected mount/umount
function signatures, if we decide one day to allow any application
using those to work on MINIX.
At this moment the caller has to start the required services, but if we
implement that logic inside the mount/unmout function, this would allow
any application to call those function successfully.
By renaming those now, we prevent a possible ABI break in the future.
Change-Id: Iaf6a9472bca0dda6bfe634bdb6029b3aa2e1ea3b
This cause in some software to assume we are linux, as this is rightly
only used there.
By default hide it behind _MINIX_SYSTEM, until we have removed traces
of it from getpeereid/[gs]etsocketopt and replaced it by the NetBSD
mechanism.
Change-Id: Iacd4cc1b152bcb7e90f5b1249185a222c90351d6
The get and set context calls where wrongly assuming that the value
of arguments passed on the stack where kept unmodified.
Change-Id: I779b08d7f5a6472c5e9dc351ae44abb2acafb3bd
The setcontext method did not alway set the return value to 0 after
restoring the desired context. Specially When calling setcontext with
the _UC_IGNSIGM and the _UC_IGNFPU flags the return value would be non
zero.
Change-Id: Iec7f8d6a680950aa53e3c88c86e03f65005e66b2
Currently we don't accept writable file mmap()s, as there is no
system in place to guarantee dirty buffers would make it back to
disk. But we can actually accept MAP_SHARED for PROT_READ mappings,
meaning the ranges aren't writable at all (and no private copy is
made as with MAP_PRIVATE), as it turns out a fairly large class of
usage.
. fail writable MAP_SHARED mappings at runtime
. reduces some minix-specific patches
. lets binutils gold build on minix without further patching
Change-Id: If2896c0a555328ac5b324afa706063fc6d86519e
