Date: Sun, 20 Apr 1997 06:35:47 -0700 (PDT) From: Alex Belits <abelits@phobos.illtel.denver.co.us> To: James Mansion <james@wgold.demon.co.uk> Cc: "John S. Dyson" <toor@dyson.iquest.net>, freebsd-hackers@freebsd.org Subject: Re: Price of FreeBSD (was On Holy Wars...) Message-ID: <Pine.LNX.3.95.970420055530.4103B-100000@phobos.illtel.denver.co.us> In-Reply-To: <335A00EF.E5A@wgold.demon.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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)".
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.95.970420055530.4103B-100000>