rtapi: Can we run with realtime guarantee?
uspace: Ask gcc for the semantics we want

I know that hm2 uses casts in a way forbidden by gcc without
-fno-strict-aliasing.  I suspect that there are places that depend on
wrapping semantics for signed arithmetic, such as in encoder wraparound,
which is what -fwrapv asks for.
rtapi: provide rtapi_io.h

.. which provides the full {in,out}[bwl] APIs, with and without
rtapi_ prefix.
uspace: implement dummy request/release region

.. in that they always succeed, but there's no effective prevention of
concurrent access to the same I/O ports by the kernel as there is in
kernel space.
uspace: implement EXPORT_SYMBOL_GPL

.. for now, this does not enforce the GPL linking
semantic, but this does not mean that violating
the GPL linking semantic is OK
uspace: implement additional MODULE_xxx macros used by hostmot2
serport: use <rtapi_io.h>

.. now this component is buildable for uspace with comp --install
serport: build for uspace
rtapi: provide additional portability headers

.. this set is sufficient to allow modified hostmot2
and hm2_test components to build.
uspace: implement rtapi_delay
hostmot2: build hostmot2 and hm2_test for uspace
rtapi: document new headers
build: we'll require libudev from now on
uspace: implementation of PCI APIs

.. and other APIs sufficient to build and run
hm2_pci hardware (tested with 5i20)

This work is based heavily on the PCI implementation in the "ubc3" branch,
a part I think was mostly based on Michael Buesch's work.
hm2_pci: rtapi-prefix APIs and enable for uspace
hm2-idrom: Adapt test to uspace

.. by getting the load-error messages from the right place
rtapi: document new header
rtapi: Move parport up from hal_ to rtapi_

.. there's nothing hal-specific about it, aside
from the call to hal_comp_name to get a name to hang on it.
rtapi: document rtapi_parport
uspace: implement rtapi_parport