Hi, On 1/25/06, Leonardo Pereira <[EMAIL PROTECTED]> wrote: > As I know, those interfaces already exists. So, I didn't understoo your "we > shouldn't add such interfaces to Mach". I do not understand why someone > would like to use IPC if we have an alternative that is faster than IPC. > This is not related to a good or bad IPC, but the use of good mechanisms.
Yes, the interface exists already (FIPC is actually disabled, but the device trap is already exported as syscall, even if commented in the headers). What would be needed to be done is the linkage of linux glue to those functionalities, which currently may work only with mach's native devices. Personally I like Neal's answer, because IMHO Mach's current need (for people still caring about it) is to be kept simple and possibly to be cleaned up of all the unused code that makes it looks even more hairy than what it is . Again, I know that feature would possibly lead to a speed up in I/O, which is very important, but current goal seems to be keeping the Hurd on Mach _alive_ and stable. And raw engineering (raw == not driven by design) certainly wouldn't help. 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