From owner-freebsd-chat Mon Apr 9 20:38:44 2001 Delivered-To: freebsd-chat@freebsd.org Received: from thunderer.cnchost.com (thunderer.concentric.net [207.155.252.72]) by hub.freebsd.org (Postfix) with ESMTP id E2EF637B422 for ; Mon, 9 Apr 2001 20:38:41 -0700 (PDT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by thunderer.cnchost.com id XAA17959; Mon, 9 Apr 2001 23:38:38 -0400 (EDT) [ConcentricHost SMTP Relay 1.10] Message-ID: <200104100338.XAA17959@thunderer.cnchost.com> To: Terry Lambert Cc: freebsd-chat@FreeBSD.ORG Subject: Re: Clash of Titans - Tale of two Morons In-Reply-To: Your message of "Tue, 10 Apr 2001 02:08:26 -0000." <200104100208.TAA26155@usr01.primenet.com> Date: Mon, 09 Apr 2001 20:38:38 -0700 From: Bakul Shah Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > 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 /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