Date: Tue, 10 Apr 2001 15:11:51 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: bakul@bitblocks.com (Bakul Shah) Cc: tlambert@primenet.com (Terry Lambert), freebsd-chat@FreeBSD.ORG Subject: Re: Clash of Titans - Tale of two Morons Message-ID: <200104101511.IAA06540@usr05.primenet.com> In-Reply-To: <200104100338.XAA17959@thunderer.cnchost.com> from "Bakul Shah" at Apr 09, 2001 08:38:38 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> My usual gripe is about system complexity (and FreeBSD is > only one of the things I complain about!). FreeBSD seems far > too complex for the functionality it provides but I don't see > that changing significantly without a bottom up redesign. I > assume that hard realtime is something one can't do in a very > complex system like FreeBSD except in a very limited sense so > there is no point in worrying about it until you have a tiny > kernel with a known bound on non-preemptability (how long you > block threads out). The main problem is kernel preemption. John's focus was on a fine grained SMP kernel, following a bottom-up redesign. But if you look at it, kernel reentrancy as a result of another processor entering, or as a result of preemption by a higher priority (RT priority) process are really equivalent. In fact, it is _easier_ to do kernel preemption than it is to do CPU reentrancy, since you don't have to deal with memory barrier instructions, like you have to when you implement synchronization primitives between CPUs. I admit that FreeBSD is far more complex than it needs to be; I recently spent some time stepping through the entire bootstrap process, from when the loader jumps to btext, through to the machine entering protected mode and getting the VM system up and operational. There is a hell of a lot of cruft in there, particularly when you consider the number of "magic" values it has lying around. Logically, it boots in real mode, crafts a VM that looks like physical memory following IPL, relocated to the kernel base address, and starts running in that VM, after which it sets up an abstract virtual memory system on top of the hardware VM management on top of the physical. It goes through a hell of a lot of redunant and parallel calculation to get there, though, and the answers aren't always equal, unless you use the right Kung-Fu, and sometimes not then. > But this can only happen if a small group of like-minded > people devote a bunch of time to it and *finish* the task > (just because it is fun to do). Most people won't see a need > for such a redesign and it has to be done in a skunkworks > mode. Most people probably don't see the need for it, even after it is complete, so there's always that risk, too. 8-). Running the OS hosted on a tight RT kernel written by someone else is a common approach, but it's far from satisfactory; an RT kernel is only as good as what you can use it for, and if you lack deterministic time device drivers, you might as well pack it in, because you're going to have no one to talk to, and I/O as a result of external events, and operations which themselves result in external events, is the name of the game. I think that one of the things we will see out of the WRS acquisition of BSDI is BSDI or a subset thereof (e.g. eBSD) being ported to be hosted on top of the VxWorks system; I don't think this would be very satisfying, overall, but I expect it to be "good enough" for enough people that it will prevent something better from happening. Whether we see FreeBSD steered away from the embedded market will be worth watching closely. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104101511.IAA06540>