If you close the source, I might as well use VxWorks.
Many people are just arriving at the real-time and embedded party.
Getting people to contribute commits them in ways beyond money and economics.
There are some things that die if you hold them too tightly.
Our biggest concern where I work is that our vendors of "software" -- usually meaning services -- will not be able to keep up with our demands and we will have to do work here on infrastructure that we would rather someone else provided.
Having source is a security blanket that we can pack our own parachute , if need be, but we would rather focus on our areas of expertise as a corporation, and get help in other areas.
We have several time " bought " software that we though included a specific port or "Board Support Package", complete with development environments and support contracts, only to be told that the BSP was not a product, just an unsupported example, that the tool chain was now obsolete, and we must change in mid project, and that our support contract did not cover getting responses in finite time, and that all our problems would be solved if we could suddenly sign a consulting agreement.
You might want to get your investors to read "Under the Radar,
by Red Hat's Robert Young. The part where he was talking to Intel
money people about giving away software was both humorous and informative.
The project I current work on is an example of why having source is important.
We needed a real-time data base package on embedded Linux node, and started with one we have source to for Solaris on Sparc.
The port has involved changing some kernel parameters involving things like shared memory, buffer queue depth, semaphores, etc.
In modifying these things, I was concerned about inducing inefficiency or bugs.
Reading kernel source led me to see the implications of our changes and the limits on them; I also found a latent kernel source bug in how message related parameters are defined that would be catastrophic in our case while not affecting users with short queue depths.
So I have avoided having my (legal) change break existing code, and saved a full design cycle over just having header information, etc.
Also, our project started on a closed X86 Unix which required long cycle times through the vendor to change anything. We cannot meet our schedules and go through that [extended] hoops that they require to effect change.
So all our embedded nodes now run O/S's for which we have source.
Regards,
Mike
[EMAIL PROTECTED] wrote:
On Sun, Jun 25, 2000 at 10:49:11PM +0200, Bernhard Kuhn wrote:
> [EMAIL PROTECTED] wrote:
> >
> > We have an experimental RTL V3 with an option to turn off Linux
> > on one PC. Measured latencies are very low -- but this is early code.
> > If you are interested in testing please send email to me.
>
> Very interessting!
>
> I´d like to have a look at it, because i intend to
> modify the kernel-scheduler in the following way
> (if i ever have enough time to do so :-) )
>
> o user-spaces processes, kernel-threads and linux-interrupts
> should be fixable to specific CPUs.Ingo did Linux interrupts already for 2.3 x86. The others should be easy.
BTW: We are under enormous pressure from potential funders who argue that
we need to abandon open source entirely to keep Lineo from simply riding
us down. I expect RTAI in the future will have done PPC ports
before RTLinux and etc. I'm attempting to manouver around both this problem
and funder demands. We will see.> o Additionaly to the usual time-sharing "nice-value", a
> priority is assigned to user-space processes, resulting
> in somewhat i would call a "hierarchical priority encoded
> preemptiv time sharing scheduler" :-)I have a solution to this, but [see above]
> This surely wouldn´t apply to machine control systems, but
> is intended for multimedia (happy fragging!) ... i know
> that there are several other projects out there, that care
> especialy about the second point (red linux, qlinux),
> but AFAIK, nobody cares about the first one ...RedLinux contains RTLinux 0.9 code, I don't know the others. But [see above]
>
> BTW: how was you talk in San Jose?Packed. Very interesting.
--
---------------------------------------------------------
Victor Yodaiken
FSMLabs: www.fsmlabs.com www.rtlinux.com
FSMLabs is a servicemark and a service of
VJY Associates L.L.C, New Mexico.-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
-- Alcatel USA Internet: [EMAIL PROTECTED] 1000 Coit Road Plano, Texas 75075 **** The opinions expressed are not those of DSC Communications, Inc **** "Keep things as simple as possible, but no simpler". A. Einstein
begin:vcard n:cravens;mike tel;home:(972) 423-9463 tel;work:(972) 477-7077 x-mozilla-html:TRUE adr:;;1000 Coit Rd;Plano;Tx;75075;USA version:2.1 email;internet:[EMAIL PROTECTED] title:Senior Software Engineer x-mozilla-cpt:;-10560 fn:[EMAIL PROTECTED] end:vcard
