From owner-freebsd-hackers Sun Apr 20 06:34:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA21108 for hackers-outgoing; Sun, 20 Apr 1997 06:34:38 -0700 (PDT) Received: from phobos.illtel.denver.co.us (abelits@phobos.illtel.denver.co.us [207.33.75.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA21103 for ; Sun, 20 Apr 1997 06:34:35 -0700 (PDT) Received: from localhost (abelits@localhost) by phobos.illtel.denver.co.us (8.8.5/8.6.9) with SMTP id GAA04710; Sun, 20 Apr 1997 06:35:48 -0700 Date: Sun, 20 Apr 1997 06:35:47 -0700 (PDT) From: Alex Belits Reply-To: Alex Belits To: James Mansion cc: "John S. Dyson" , freebsd-hackers@freebsd.org Subject: Re: Price of FreeBSD (was On Holy Wars...) In-Reply-To: <335A00EF.E5A@wgold.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 20 Apr 1997, James Mansion wrote: > I would have though that some very minor performance hit would be > worthwhile if you could make it much easier to: > - add new file systems, preferably layered too > - add support for native interpreted systems, such as Java Oh, that can justify inefficiency in kernel. > - add new system calls I don't think, adding system calls like popen(2) and gethostbyname(2) (*) will be a valid reason for inefficient implementation of existing ones. > - add new 'objects' that can be integrated into select() or > poll() [in particular, threads and synchronisation primitives] select() (BSD) and poll() (SysV) work on sets of file descriptors (RTFM what is a file descriptor in anything unixlike), and if system doesn't do it exactly that way, it's broken. Posix vs. BSD select() behavior incompatibility is a known problem, but now there is no reasonable way to "fix" it in either direction -- at least people know it and write portable code. > (Oh yeah, and I absolutely refuse to write anything in C when I > have C++ to hand, and I'd kinda appreciate an ability to reuse my Good > Stuff) In kernel? You don't have C++ anywhere close to your hands when you write kernel. > It would seem that we are in danger of 'proving' that a tightly coupled > monolithic system can have much better performance characteristics than > a modular one with 'traffic cops' (such as the HAL) in the middle. But > then that's hardly news, nor would it be news that the upgrade and > release process got steadily more painful as the complexity/entropy > increased. Microkernel systems can be as efficient as monolithic ones. Modularity doesn't necessary mean such "extreme" as microkernel design either. And Microsoft can make an OS based on any kind of design concept and it will crawl -- it's Microsoft after all. > Your choice, guys, and the product is at least successful at the moment, > but it seems like (the top of?) a slippery slope to me. "Tight coupling" isn't a correct word for what you are trying to describe, "messy design" is. And there can't be any questions, should anyone fix it or not -- already some things are getting cleaner, so I assume, people realize that. At what extent it could be done, is a different question, but justifications that you given for inefficient implementation aren't valid. -- Alex (*) for some strange people who didn't get it -- popen(3) and gethostbyname(3) are library functions that no sane person can put into kernel, so they'll become "popen(2)" and "gethostbyname(2)".