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 n
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.2006/
We shouldn't add such interfaces to Mach. The set of interfaces
should be the minimum required such that we are still able to
concisely articulate the set of desirable and useful operations. That
IPC is slow on Mach is well understood. The solution is not to
minimize the use of Mach IPC but to u
On 1/25/06, Marco Gerards <[EMAIL PROTECTED]> wrote:
> > Please note, though, that we obviously need to modify the hurd and/or
> > the libc to let the system use it.
>
> Can't it be implemented as another store class or so? In that case it
> can be used in the Hurd without affecting current system
Gianluca Guida <[EMAIL PROTECTED]> writes:
> 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
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
