RTEMS evolution was .. Re: bits/wordsize.h

[Joel Sherrill]

On 04/18/2011 03:29 AM, Wolfram Wadepohl wrote:
> I think we are talking about different things. I'm absolutely unfamiliar
> with FreeType and it may be that Ralf is totally right relating to
> FreeType. I don't know. That is not the thing I wanted to point out.
FWIW Freetype builds and works fine with RTEMS.  Microwindows
can use it and the RTEMS Graphics Toolkit includes it.
> Generally RTMES lacks in support of many widely available and also used
> features, if standard or not, to implement control systems, which are
> tightly integrated into SCADA. Especially in networking I reached the point
> to make a decision about the future: RTEMS or GNU/LINUX.
RTEMS evolves and gets features as users have needs.  Some things
are implemented by volunteers but most of the volunteer activity
is focused on tools, testing, bug fixes, etc.  GSoC has been good to
us here because some large-ish projects have been done by these
students.  But some very important things are beyond the scope
of GSoC.

Support contracts with OAR primarily go toward helping the
user and fixing bugs.  These are really inexpensive and don't
really include room to do development.

So larger issues are usually tackled by someone doing it themselves
or paying the core developers to do it.  OAR, Embedded Brains, and
Chris Johns are the primary ones doing this.  Some recent activities
and pending work include:

+ Embedded Brains has a USB stack port and TCP/IP stack update
that requires some more work to be merged.  Beyond the obvious benefits
of having a USB and updated TCP/IP stack, this will address a number of
issues including IPV6.  But this really needs some sponsorship to get
merged cleanly.

+ OAR recently completed a BSP for the RAD750.  If you are
interested in this, please contact me.  It has export restrictions
and we cannot legally include it in the main distribution.

+ OAR is currently working on adding SMP support for a user.  This is
to support SMP on LEON3 and pc386. It is planned to be a
working but "straight-forward" effort.  In other words, fancy SMP
scheduling algorithms, processor affinity, etc are being left for
future work.

+ Chris Johns is working on dynamic loading which adheres to the
POSIX dl* interface and is as light as possible with on target requirements.

+ Chris and I did a lot of work on the shell and file systems for
a pair of users between 4.9 and 4.10.

+ Chris implemented the RTEMS File System for a user (RFS).

There is no big sugar daddy for RTEMS.  Each major improvement
is paid for by some user who needs it.  The above is just a list
of recent improvements that I know were paid for by users.
> It is not the matter of a simple definition. We must frequently implement
> 3rd party code into the system, mostly developed for Windows or GNU/LINUX
> sytems.
>
What features, etc do you need?  What problems do you need
solutions to?

RTEMS requirements are generally POSIX and user needs.
> In the automation world a system works for 10 or 15 years but not as a
> static one, rather as a dynamic. So we have to keep track in control
> software with the evolution and roll out releases to incorporate all the
> new technologies if standard conform or not.
>
> Just as an example: I learned that the networking stack is an very old BSD
> relict and many RTEMS user would apreciate a current stack including IPv6.
> But no one takes the effort to update to a current release. For a small to
> medium sized enterprise, like us,  this project is also too big.
>
Would you be willing to team with another user to sponsor it?
If 3-4 users came together to pay for this project, it could be
done easily.

Would you be willing to use it if included but marked experimental?

I want us to address user requirements.

> What I want to point out is, that the community is currently not able to
> carry out this work. When we are faced with IPv6 as a asolutely _must_
> _have_? In months, years, decades?
>
Agreed.  It is a must have and I think the solution is to have
a group of users sponsor the effort.
> Not the decision about bits/wordsize.h is in my mind. Shall we stay with
> RTEMS or shall we move to GNU/LINUX. I'm convinced of RTEMS but it gets
> harder and harder to convince others (managagement, sales, customers). And
> I do not know how RTEMS evolve, neither direction nor timeline. And this
> makes it difficult to get funds for development of RTEMS components.
>
What type of roadmap do you want?  Personally, I can't put dates
on things that are unfunded and unstaffed.  I know what is desirable
but not when it will happen.

In very broad terms, here are what you can expect in the next
major release (off the top of my head) given the current development
underway and likely to be completed:

+ SMP
+ dynamic loading
+ better test coverage
+ improved autobuilders
    - daily builder of all BSPs (already in place)
    - coverage tester
+ newer development tool versions
     - ARM may be moved to EABI
+ support for more languages
     - Go yes
     - Obj-C maybe
     - GCJ possible GSoC project
+ more example programs
+ Updated Mongoose HTTPD
+ Updated packages in RTEMS Addon Packages
    - added GNU Scientific Library

If I forgot something, please ping me.  I notice a lot of that isn't on
the 4.11 wiki page.

If you can offer suggestions on what you would like to see as a Roadmap
or improvements in communication, I would like the suggestions.

Thomas Doerfler and I have discussed before having multiple users
team together to sponsor some piece of major work.  If enough are
willing to do this, IPV6 should  be in the next release.
> Ralf Corsepius schrieb:
>> On 04/18/2011 08:06 AM, Wolfram Wadepohl wrote:
>>> this is the time to jump into the discussion and open a more 'political'
>>> thread.
>>>
>>> Yes, Ralf is right. In theory. On the other hand Sebastien is right,
>>> because he wants to get a widely used part of software working on 'his'
>>> (i. e. our) RTEMS.
>>> The resulting question is IMHO essential for the future of RTEMS in
>>> industrial projects: How much non standard but widely used 'junk' do we
>>> adopt or allow? And how get we this done?
>> Well you can expect us to rucksack RTEMS with hacks to work around bugs
>> in arbitrary applications.
>>
>> Please check freetype's sources: As far as I can gather, what they are
>> doing is to utilizes a non-documented, glibc private, internal define to
>> derive some pointer sizes - This approach lacks generality and will
>> inevitably fail somewhere.
>>
>>
>> As others previously said, this situation is far from being unusal. It's
>> a bug in an application, nothing more, nothing less and nothing to fret
>> about.
>>
>> It's what system-integrators and packagers (esp. under Linux) deal with
>> every day.
>>
>> C.f. favorite OS's FLOSS packages and you'll find that many of these
>> packages require patches, whose only purpose is to adopt packages to
>> their OS's specifics, because the upstream maintainers did not take
>> something into account.
>>
>> That said: Providing upstreams with feedback about such issues (and
>> possibly to send patches/fixes), is one of the foundations FLOSS is
>> based on.
>>
>> Ralf
>>


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985