Date: Mon, 21 Apr 1997 16:47:07 +0100 From: James Mansion <james@westongold.com> To: Alex Belits <abelits@phobos.illtel.denver.co.us> Cc: freebsd-hackers@freebsd.org Subject: Re: Price of FreeBSD (was On Holy Wars...) Message-ID: <335B8BFB.D65@westongold.com> References: <Pine.LNX.3.95.970420055530.4103B-100000@phobos.illtel.denver.co.us>
next in thread | previous in thread | raw e-mail | index | archive | help
Alex Belits wrote: > > 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. I'm not sure I understand you. Adding such code *shouldn't* cause inefficiency. I'm saying that I'd rather lose a bit of efficiency and have a source code base that is cleanly structured, so that such enhancements are easy. Structuring to make such changes easy might well introduce 'inefficiency' (or rather, efficient solution of a different problem) > > > - 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. Try thinking before you write, huh? I'm arguing for a more modular approach, on the assumption that having a very clean modular design will introduce extra levels of indirection and data hiding, which will have a minor impact on performance. Maybe even a measurable impact in some cases. I'm saying its worth it. On AIX for example you can integrate the SysV message queues. On NT I have an ability to wait for multiple different types of object. It is useful to be able to wait for an event to be signalled, a timer to expire, a thread to end, or IO to be possible (as for select etc) in one place. Its a royal pain that you have this excellent IO multiplexing mechanism, and the POSIX threading and synchronisation facilities, but that they don't interoperate very tidily. This would be useful. I *know* that the current spec doesn't support it. I also know that it would be useful, and I might want to add it. But I can't (or won't) if the code is spaghetti. > > > (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. Why? (Assuming that the compiler works) Strong typing, reuse of collections and pattern implementations, exceptions, templates, its all worthwhile and I wouldn't be without it. Look at Doug Schmidt's work on communication frameworks if you are really so clueless that you don't understand why I'd want to use those facilities. > > > 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 Name one. The very requirement of the boundaries will introduce a cost that you could avoid with a direct function call. > 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. Well, that's as stupid and dumb a thing as its possible to say, really. > > > 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. I am saying that I would accept an inefficient implementation if there were a tradeoff. Efficiency isn't everything, even in a kernel. Its one reason why NT isn't very effieicnt - it doesn't need to be, to be successful, so long as it is 'good enough'. Which it clearly isn't as an enterprise server, but clearly is as, for example, a trader workstation. Of course, I'd rather have a super clean modular system that was the ultimate in efficiency too. Given the choice, I'd have a modular system any day though. > > -- > 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)". Huh. Can you make any sane justification for the woolly divide between libc and the kernel? One of the worst aspects of UNIX as we know it. James
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?335B8BFB.D65>