Date: Tue, 05 Jan 1999 17:24:54 -0700 From: Wes Peters <wes@softweyr.com> To: Terry Lambert <tlambert@primenet.com> Cc: bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. Message-ID: <3692AD56.224F04D4@softweyr.com> References: <199901052353.QAA19601@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3692AD56.224F04D4>