Re: Creating new interfaces for specific servers

[Marcus Brinkmann]

On Wed, Jun 12, 2002 at 04:36:33PM +0200, Ludovic Courtès wrote:
> From my understanding, the current policy is to try not to have too many
> interfaces and to try as much as possible to use the existing one. Is it
> correct?

Yes.

> If yes, to which extend should people avoid creating new interfaces?

As much as it makes sense.  This is really a question of judgement.  ioctls
make sense for compatibility with existing systems is worthwhile, and in
that case it even makes sense to use a ioctl (or better the RPC directly)
rather than inventing a new similar interface.

However, if we talk about large sets of interfaces that were invented by
individual systems and where portability is not an issue, then it may be
better to design a good interface from ground up.

For example, for the console server it almost looked like I would need new
interfaces.  But now I am halfway through implementing it and it seems I can
use the existing interfaces with only a few extenstions (two more flags in
the notification interface that are potentially useful to other servers,
too).  Ok, I have it easier as I use shared memory and a data structure to
pass some data.  But that doesn't change the fact that I did not need
another RPC.

It's a matter of finding the right design principles.  For shared memory, we
probably only need one or two new RPCs, the rest is covered by file system
operations (the new RPCs would be io_close, and something that informs the
server about the PID of the caller, similar to io_set_owner).

It's often possible to reuse interfaces, but sometimes it is just not
possible or feasible.  We don't want to make everything look like a nails. 
But we don't want to make every nail different ;)

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de