Date: Mon, 09 Apr 2001 20:38:38 -0700 From: Bakul Shah <bakul@bitblocks.com> To: Terry Lambert <tlambert@primenet.com> Cc: freebsd-chat@FreeBSD.ORG Subject: Re: Clash of Titans - Tale of two Morons Message-ID: <200104100338.XAA17959@thunderer.cnchost.com> In-Reply-To: Your message of "Tue, 10 Apr 2001 02:08:26 -0000." <200104100208.TAA26155@usr01.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> I was really disappointed that FreeBSD never really bit the hard > RT bullet, back when there was opportunity for it to do so. When > John Dyson went off on his "new kernel" crusade originally, the > reason I didn't participate was that it wasn't going to support > hard RT. I just didn't really see the point, unless it was going > to be able to do something that the current kernel could not, and > lacking RT is the number one deficiency in FreeBSD, in my opinion. 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). 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. > The problem with FreeBSD is that a lot of the lower level code is > not deterministic with regard to running time. People will now > argue endlessly about whether PC hardware can run Hard RT, I'm > sure. I believe you! Way back when I have debugged a QNX based Intel286 system that was used for speech synthesis where hard realtime is a must -- IIRC the phonemes were fed by the s/w to the sound card at the correct rate! > You can do the same thing in FreeBSD, fairly trivially; I don't > see how it's much different than portals; someone was complaining > the other day about FreeBSD not having the Windows "control panel" > feature, where you are not actually looking at a filesystem object, > you are looking at a DLL loaded into your shell as a shell > extension; I pointed out portals and got back "Oh.". 8-). Can you do the equivalent of # Create a tar file $ cd / $ tar cf /sys.tar sys # mount the tar file $ mount -t <foo> /my-sys sys.tar $ cd /my-sys/i386 Makefile conf ibcs2 isa pci apm i386 include linux svr4 You need the ability to deliver open/close/read/write/lseek etc. calls to the portal object. I didn't think you could do that with portals. A code sample that points me in the right dir will be gratefully accepted. If the tar image contains a special device I should be able to use it as a special device! I should be able to use this fs via nfs or make it participate in filesystem overlays (incorrectly called the `union' file system). One should be able to implement compressed or encrypted file systems as well. -- bakul 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?200104100338.XAA17959>