[RFC] GNU Mach's forgotten speed ups.

[Gianluca Guida]

Hi,

There are two piece of code which are giving me problems (I am looking
out for code cleaning in the device section).

These piece of code implements some possible speed up unused at the
moment. They are:

- device-write trap: it uses a specific syscall to write to device (as
opposed to IPC to emulated device server). To me it seems a speed up
not only for jumping the IPC overhead, but even because it copies data
directly from userspace to I/O buffer (memory that's used by device
driver directly).
This is definitely a nice feature. It adds, though, some architectural
concern for designers and and it's actually unsupported by linux glued
drivers. Anyways, adding support for this call to linux glue drivers
seems to me quite straightforward.

- Fast IPC: This is another I/O speedup, but for ethernet devices. It
adds two more syscalls fipc_send and fipc_recv, for sending and
receiving packets from eth devices to userspace. Now I haven't looked
at it too much, since I am quite clueless on IPC stuff (Sergio, do you
know this thing?). It supports only Mach's native ethernet drivers,
which expands to 'none' in our case. Porting this to Linux drivers
seems -- I haven't had a serious look at it, but code seems very
complicated -- not so straightforward.

Well, I would like to hear from the community/maintainers what I
should do with this code. If we don't plan to use this I would be
happy to remove it, since they're forcing some export of functions
that should be internal and generally increasing code size, length and
complexity.
If we want to use it or to test it, I can work to implement these
features to linux drivers too. In the case of device trap, that
shouldn't take more than one day, for the FIPC, I actually don't know.
Please note, though, that we obviously need to modify the hurd and/or
the libc to let the system use it.

So, what do you think?

Gianluca

--
It was a type of people I did not know, I found them very strange and
they did not inspire confidence at all. Later I learned that I had been
introduced to electronic engineers.
                                                  E. W. Dijkstra