From owner-freebsd-hackers Tue Jan 5 16:25:53 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA10909 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 16:25:53 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA10904 for ; Tue, 5 Jan 1999 16:25:51 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id QAA11833; Tue, 5 Jan 1999 16:24:56 -0800 (PST) Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id QAA03090; Tue, 5 Jan 1999 16:24:55 -0800 Received: from softweyr.com by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL])) id RAA14095; Tue, 5 Jan 1999 17:24:55 -0700 Message-ID: <3692AD56.224F04D4@softweyr.com> Date: Tue, 05 Jan 1999 17:24:54 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 2.2.7-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert CC: bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. References: <199901052353.QAA19601@usr05.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > > Except that out here in the real world uITRON isn't even on the > > radar screen. I know it's supposed to be big news with the Japanese > > companies who created it, but the numerous projects being done here > > in the USA don't even consider it. At all. Ever. > > There are actually quite a number of uITRON OS's from US companies, > starting with eCOS from Cygnus, which is (basically) under a GPL > derivative license. > > The Intel Video Phone Reference Implementation comes with a uITRON > compliant OS from a US company ("Inferno" from Lucent): > > http://developer.intel.com/design/strong/webphone.htm On the other hand, their proposed new standard for "information appliances," with which I am *intimately* familiar, is based on VxWorks which is NOT uITRON compliant, and IS the biggest-selling (32-bit) embedded OS around. Unless AMX/PalmOS has overtaken it, but they're not uITRON compatible either. > So it's a bit more than a curiousity. Also, FreeBSD has strong > Japanese support, and uITRON would only make it stronger. But only a bit more than a curioustiy. Like most standards, it seems to standardize the stuff that didn't differ that much, and remain mute on the parts where you really NEED some standards. RTEMS and VxWorks have both chosen the path of implementing the Posix real-time interface as much as possible. I believe this is probably of more near-term benefit, and probably more long-term benefit as well. It certainly makes it much more straightforward to port UNIX network servers into the embedded space. > > The original RTEMS license was much more Berkeley like, but they found > > a couple of "clients" who were not contributing fixes back and it > > sorta ticked them off, so they went with this instead. Go figure. > > Yeah. The problem is that they are using BSD TCP/IP code, and as a > result, the requirement for source distribution is highly questionable. > If you don't have a legally valid license to use the stuff, you don't > have any license to use the stuff. I've spoken with Joel about this a couple of times, but it doesn't seem that they will move to clean it up until someone calls them on it. Since the networking stack was lifted straight from FreeBSD, maybe I should put my FreeBSD-Advocate hat on and call the head honcho? Nah, it just doesn't bother me all that much. > > RTEMS remains a good example of a working object-locking system that > > can scale quite easily to a moderate number of processors. > > OK, I'll buy that, if you'll buy that SVR4 is a good example of a > working object-locking system that can only scale to 4 processors. > > ;-). Except as hacked by Sun. See, i.e., E10000. ;^) > The problem is that FreeBSD is more similar in the tasks it runs to > SVR4 than it is to an RTOS. Even with RT features, I think this > would stay true... I don't dispute that at all, just your statement that object locking is inherently bad. It's only bad if it interacts badly with the system you're trying to develop. -- Where am I, and what am I doing in this handbasket? Wes Peters +1.801.915.2061 Softweyr LLC wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message