Date: Tue, 5 Jan 1999 23:53:55 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: wes@softweyr.com (Wes Peters) Cc: tlambert@primenet.com, bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. Message-ID: <199901052353.QAA19601@usr05.primenet.com> In-Reply-To: <36929290.2909A074@softweyr.com> from "Wes Peters" at Jan 5, 99 03:30:40 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
So it's a bit more than a curiousity. Also, FreeBSD has strong
Japanese support, and uITRON would only make it stronger.
> If you read the RTEMS license page, it is GPL'ed with an exception, and
> that exception allows you to create and distribute your product, linked
> with RTEMS, without restraint. In effect, they're using the LGPL with
> no source distribution clause.
>
> 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.
> Whether this is a problem or not depends on your system architecture. In
> embedded systems, where the interactions between parts of the architecture
> are generally both simpler and more limited than in a large, general-
> purpose computer, contention on the critical objects often is not much
> of a consideration, because the various system objects have such limited
> interactions. This is also true of, for instance, I/O processors
> communicating with a main system processor.
>
> 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.
;-).
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...
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-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901052353.QAA19601>