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 [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de _______________________________________________ Help-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-hurd
