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 _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd