Date: Mon, 21 Apr 1997 09:47:00 -0700 (PDT) From: Alex Belits <abelits@phobos.illtel.denver.co.us> To: James Mansion <james@westongold.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Price of FreeBSD (was On Holy Wars...) Message-ID: <Pine.LNX.3.95.970421092604.14219A-100000@phobos.illtel.denver.co.us> In-Reply-To: <335B8BFB.D65@westongold.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 21 Apr 1997, James Mansion wrote: > 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. Then it's invalid justification. Or you mean that supporting interpreters can be an _excuse_ to have the rest of system inefficient? > 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. Then implement them through file descriptors and/or signals (I use that all the time), and the problem is solved. And, please, not in the kernel. > > > (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. You can want it as much as you please -- it doesn't work in kernel, and there already was a discussion in this ML about that. > > > 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. Why? Microsoft ever made well-designed and/or efficient OS? > > > 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. 5 years ago 286 with DOS was "good enough" for that purpose. It's not an application by what quality of OS design can be judged. > 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. It's possible to make things nice and efficient. Neither Microsoft nor BSD kernel are examples of such thing been done perfectly, but breaking working code to replace it by "nice" but inefficient thing with such ridiculous purposes as mentioned by you will be stupid. > > -- > > 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. I've mentioned _extreme_ cases that don't belong to the kernel in anything that even distantly resembles unix. -- Alex
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.95.970421092604.14219A-100000>