[ECOS] Re: NIOS2 toolchain build failure under Cygwin

[ECOS] Re: NIOS2 toolchain build failure under Cygwin

[Øyvind Harboe]

>> I believe I'm seing the same segmentation fault.
>>
>> Did you find a way to resolve this problem?
>
>Sort of:  Use Linux.

Cheat! :-)

>> My first thoughts was to try to revert to an older GCC version for
>> CygWin or worst case attempt a cross-build from Linux.
>
>I just switched to Linux.  Once I get everything else ironed
>out, I'll mess with Cygwin again (assuming my client really
>wants me to).

I disabled precompiled headers while configuring the toolchain. That
did the trick.

>Building eCos for NIOS2 is the biggest mess I've ever seen: A
>Shell script wrapper for a Java program that generates a CDL
>file that generates a shell script that generates a Perl script
>that calls a Java program that generates include files, etc.
>etc.
>
>What a pile.

I don't know why Altera thinks it needs to be that way.

Though I can see how a soft-CPU with a dynamic number of peripherals
would be a poor impeadance match with eCos static cdl files.

I never quite understood why eCos considers a specific HAL part of
eCos. I always viewed the HAL as part of the application. Although
final PCB's might strongly resemble a particular evaluation board, I
wouldn't expect it to be exactly like the evaluation board in the
general case. Never happened to me anyway. The stuff that can be
shared between HALs and that does not change between HALs seems to
belong(as in making the whole shebang more easily maintainable) in
eCos.

BTW, at first glance I couldn't even find eCos in the Nios2 6.0 beta.

-- 
Øyvind Harboe
http://www.zylin.com

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: NIOS2 toolchain build failure under Cygwin

[Grant Edwards]

In gmane.os.ecos.general, you wrote:
>>> I believe I'm seing the same segmentation fault.
>>>
>>> Did you find a way to resolve this problem?
>>
>>Sort of:  Use Linux.
>
> Cheat! :-)
>
>>> My first thoughts was to try to revert to an older GCC version for
>>> CygWin or worst case attempt a cross-build from Linux.
>>
>>I just switched to Linux.  Once I get everything else ironed
>>out, I'll mess with Cygwin again (assuming my client really
>>wants me to).
>
> I disabled precompiled headers while configuring the toolchain. That
> did the trick.

How did you do that?  I couldn't find any "configure" options
that mentioned precompiled headers.

>>Building eCos for NIOS2 is the biggest mess I've ever seen: A
>>Shell script wrapper for a Java program that generates a CDL
>>file that generates a shell script that generates a Perl script
>>that calls a Java program that generates include files, etc.
>>etc.
>>
>>What a pile.
>
> I don't know why Altera thinks it needs to be that way.

They seem to be real big on the theory that you should be able
to sit down at a GUI click a few times to configure hardware,
click a few times to build software, and you're done.  It works
fine as long as you want to build something they've already
thought up and pre-configured, but the second you want to build
something that isn't one of the included demos, the whole thing
collapses of it's own weight.

Even if you do manage to click on enough of the right things
in the right order to build eCos and an eCos application,
there's no way you can document and automate the a build
procedure so that you've a hope in hell of being able to build
the same thing next week or of the guy in the next cube being
able to build the same thing this week.

> Though I can see how a soft-CPU with a dynamic number of
> peripherals would be a poor impeadance match with eCos static
> cdl files.

There's sure got to be a better way to deal with it than what
they've got now.  It's taken me a lot head-banging to get to
the point where I've got a shell script that can repeatably
configure and build RedBoot from the command line.

Now I've got to figure out what portions of the NIOS tree has
to be archive along with the eCos source tree to provide the
input files that are needed to create all of the CDL files on
the fly.

> I never quite understood why eCos considers a specific HAL
> part of eCos.

It sure would be a lot easier to manage if the HAL was separate
from the main eCos tree.  Have a huge tree of "off the shelf"
stuff with one modified file and one buried directory of
"custom" stuff is a real PITA to manage in a production
environment.

> I always viewed the HAL as part of the application.

I would go that far.  We build a lot of different applictions
all based on the same target board and eCos/HAL combination.
Still, it would be a lot easier to manage if the HAL wasn't
mixed in with the "generic" stuff.

> Although final PCB's might strongly resemble a particular
> evaluation board, I wouldn't expect it to be exactly like the
> evaluation board in the general case. Never happened to me
> anyway. The stuff that can be shared between HALs and that
> does not change between HALs seems to belong(as in making the
> whole shebang more easily maintainable) in eCos.
>
> BTW, at first glance I couldn't even find eCos in the Nios2
> 6.0 beta.

It's buried pretty deep.

-- 
Grant Edwards                   grante             Yow!  .. I want FORTY-TWO
                                  at               TRYNEL FLOATATION SYSTEMS
                               visi.com            installed within SIX AND A
                                                   HALF HOURS!!!

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: NIOS2 toolchain build failure under Cygwin

[Andrew Lunn]

> It sure would be a lot easier to manage if the HAL was separate
> from the main eCos tree.  Have a huge tree of "off the shelf"
> stuff with one modified file and one buried directory of
> "custom" stuff is a real PITA to manage in a production
> environment.

ecosconfig understands ECOS_REPOSITORY being a list of directories.
So you could have a repository of your own which just contains your
HAL.

The configtool however does not understand the list thing. However,
since you are talking about build scripts, i doubt that matters for
you.

        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: NIOS2 toolchain build failure under Cygwin

[Grant Edwards]

In gmane.os.ecos.general, you wrote:
>> It sure would be a lot easier to manage if the HAL was separate
>> from the main eCos tree.  Have a huge tree of "off the shelf"
>> stuff with one modified file and one buried directory of
>> "custom" stuff is a real PITA to manage in a production
>> environment.
>
> ecosconfig understands ECOS_REPOSITORY being a list of directories.
> So you could have a repository of your own which just contains your
> HAL.

Cool.  How did I not know that?  

That would solve the problem very nicely: one "stock"
repository and one "custom" one containing HALs and whatever
other packages are too ugly (or just not generally useful
enough) to make it into the standard source tree.

> The configtool however does not understand the list thing.
> However, since you are talking about build scripts, i doubt
> that matters for you.

Hmm.  

It would matter to me personally, but I think in the past there
have been customers who used the configtool to customize the
product's firmware.  It sure would be easier to maintain if the
"custom" stuff was in a separate repository.  I think it would
be worth giving up the configtool -- especially since it's
somebody else that doing the giving up.  ;)

Right now when we decide to sync our eCos repository with the
"official" one, there always seems to be glitches.

-- 
Grant Edwards                   grante             Yow!  .. bleakness....
                                  at               desolation.... plastic
                               visi.com            forks...

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: NIOS2 toolchain build failure under Cygwin

[Andrew Lunn]

On Wed, Aug 09, 2006 at 09:31:36AM -0500, Grant Edwards wrote:
> In gmane.os.ecos.general, you wrote:
> >> It sure would be a lot easier to manage if the HAL was separate
> >> from the main eCos tree.  Have a huge tree of "off the shelf"
> >> stuff with one modified file and one buried directory of
> >> "custom" stuff is a real PITA to manage in a production
> >> environment.
> >
> > ecosconfig understands ECOS_REPOSITORY being a list of directories.
> > So you could have a repository of your own which just contains your
> > HAL.
> 
> Cool.  How did I not know that?  

Im not sure its actually documented somewhere. It is something Bart
added a few years back. Im guessing eCosCentric use it internally to
keep customer specific packages seperate from there customer
independent packages.

> It would matter to me personally, but I think in the past there
> have been customers who used the configtool to customize the
> product's firmware.  It sure would be easier to maintain if the
> "custom" stuff was in a separate repository.  I think it would
> be worth giving up the configtool -- especially since it's
> somebody else that doing the giving up.  ;)

At the time it was added, John commented that it required some work to
make configtool support this. So i was never added. To me it seems
like the configtool is unmaintained anyway. If it stays like this, i
would suggest it is dropped in the next official release. This is a
shame given that there has been some recent interest in bringing it up
to date with recent versions of xWidgets and make it build using
automake.

        Andrew
 


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: NIOS2 toolchain build failure under Cygwin

[Bart Veer]

>>>>> "Oyvind" == =?ISO-8859-1?Q?=D8yvind Harboe?= <ISO-8859-1> writes:

    <snip>

    >> Building eCos for NIOS2 is the biggest mess I've ever seen: A
    >> Shell script wrapper for a Java program that generates a CDL
    >> file that generates a shell script that generates a Perl script
    >> that calls a Java program that generates include files, etc.
    >> etc.
    >> 
    >> What a pile.

    Oyvind> I don't know why Altera thinks it needs to be that way.

    Oyvind> Though I can see how a soft-CPU with a dynamic number of
    Oyvind> peripherals would be a poor impeadance match with eCos
    Oyvind> static cdl files.

According to the design, CDL files do not have to be static. CDL is
embedded in a general-purpose scripting language, Tcl. Conceptually
that gives it the flexibility to adapt to changing hardware, including
reconfigurable systems. The problems are:

  1) the CDL implementation is still incomplete, for a variety of
     reasons I do not intend to go into here.

  2) not all the concepts behind CDL are widely understood, leading to
     flawed approaches like generating static CDL files.

    Oyvind> I never quite understood why eCos considers a specific HAL
    Oyvind> part of eCos. I always viewed the HAL as part of the
    Oyvind> application. Although final PCB's might strongly resemble
    Oyvind> a particular evaluation board, I wouldn't expect it to be
    Oyvind> exactly like the evaluation board in the general case.
    Oyvind> Never happened to me anyway. The stuff that can be shared
    Oyvind> between HALs and that does not change between HALs seems
    Oyvind> to belong(as in making the whole shebang more easily
    Oyvind> maintainable) in eCos.

I assume you are referring here specifically to platform HALs.
Architectural, processor and variant HALs obviously belong in the eCos
repository, they can be re-used across multiple platforms.

Typically there will be information in the platform HAL which other
packages will want to know at compile-time. For example the cpu speed
on a particular board is typically a characteristic of the platform
HAL but that information may be needed in various places, e.g. in
serial drivers when converting baud rates to register values. If you
make the platform HAL part of the application then the only way eCos
packages can get hold of that kind of information is at link-time via
variables or functions. That has code-size and performance penalties.

You also need to consider what happens from a maintainer's
perspective:

1) how do you build and run the tests for a given platform if the
   platform details are held in application space?

2) similarly how do you build RedBoot (assuming RedBoot is appropriate
   for the target hardware)?

3) how do you make coherent releases for a given platform, e.g. a
   standard evaluation board?

Having platform HALs makes some things a lot easier, even if at times
it may make life a bit more difficult for application developers
porting to custom hardware.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: NIOS2 toolchain build failure under Cygwin

[Øyvind Harboe]

On 09 Aug 2006 16:20:23 +0100, Bart Veer <bartv@ecoscentric.com> wrote:
> >>>>> "Oyvind" == =?ISO-8859-1?Q?=D8yvind Harboe?= <ISO-8859-1> writes:
>
>     <snip>
>
>     >> Building eCos for NIOS2 is the biggest mess I've ever seen: A
>     >> Shell script wrapper for a Java program that generates a CDL
>     >> file that generates a shell script that generates a Perl script
>     >> that calls a Java program that generates include files, etc.
>     >> etc.
>     >>
>     >> What a pile.
>
>     Oyvind> I don't know why Altera thinks it needs to be that way.
>
>     Oyvind> Though I can see how a soft-CPU with a dynamic number of
>     Oyvind> peripherals would be a poor impeadance match with eCos
>     Oyvind> static cdl files.
>
> According to the design, CDL files do not have to be static. CDL is
> embedded in a general-purpose scripting language, Tcl. Conceptually
> that gives it the flexibility to adapt to changing hardware, including
> reconfigurable systems. The problems are:
>
>   1) the CDL implementation is still incomplete, for a variety of
>      reasons I do not intend to go into here.
>
>   2) not all the concepts behind CDL are widely understood, leading to
>      flawed approaches like generating static CDL files.

I knew that, but forgot while I wrote what I did. I can see how a
non-TCL guru would want to generate CDL instead of understanding the
finer point of TCL+CDL :-)

Is there a fundamental reason why CDL should not be generated?

Java + Eclipse beats the crap out of TCL + vi when in terms of a
development environment :-)

>     Oyvind> I never quite understood why eCos considers a specific HAL
>     Oyvind> part of eCos. I always viewed the HAL as part of the
>     Oyvind> application. Although final PCB's might strongly resemble
>     Oyvind> a particular evaluation board, I wouldn't expect it to be
>     Oyvind> exactly like the evaluation board in the general case.
>     Oyvind> Never happened to me anyway. The stuff that can be shared
>     Oyvind> between HALs and that does not change between HALs seems
>     Oyvind> to belong(as in making the whole shebang more easily
>     Oyvind> maintainable) in eCos.
>
> I assume you are referring here specifically to platform HALs.

More specifically a HAL for a customer specific PCB. Those HALs
belongs in the application space.

Evaluation boards, quite possibly in eCos.

> Architectural, processor and variant HALs obviously belong in the eCos
> repository, they can be re-used across multiple platforms.

Makes sense.

> Having platform HALs makes some things a lot easier, even if at times
> it may make life a bit more difficult for application developers
> porting to custom hardware.

I would consider custom hardware the common case and not the exception
for deeply embedded applications.

-- 
Øyvind Harboe
http://www.zylin.com

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: NIOS2 toolchain build failure under Cygwin

[Grant Edwards]

In gmane.os.ecos.general, you wrote:

> I knew that, but forgot while I wrote what I did. I can see how a
> non-TCL guru would want to generate CDL instead of understanding the
> finer point of TCL+CDL :-)

I can sympathise with somebody who has issues with TCL.  I
tried to learn it once and failed.  It's the only language that
defeated me.  Except for maybe COBOL -- and I blame that on the
2-day turnaround time for compile attempts.

> Is there a fundamental reason why CDL should not be generated?
>
> Java + Eclipse beats the crap out of TCL + vi when in terms of a
> development environment :-)

Possibly, but I've yet to see a computer powerfull enough to
run Java+Eclipse. Python + Jed is the best. :)

> More specifically a HAL for a customer specific PCB. Those
> HALs belongs in the application space.

I don't really think "application space" is the right place.
I've got quite a few customers who work in "application space"
and the last thing the world needs is them messing about with
the HAL.

To me, having them in a separate repository seems like the way
to go.

> Evaluation boards, quite possibly in eCos.

I don't have any objection to having "standard" HALs in the
standard eCos repository.  The problem we've run across (not
huge, but persistent) is in integrating custom HALs into the
single repository model.

-- 
Grant Edwards                   grante             Yow!  Is a tattoo
                                  at               real, like a curb or a
                               visi.com            battleship? Or are we
                                                   suffering in Safeway?

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: NIOS2 toolchain build failure under Cygwin

[Bart Veer]

>>>>> "Oyvind" == =?ISO-8859-1?Q?=D8yvind Harboe?= <ISO-8859-1> writes:

    Oyvind>> Though I can see how a soft-CPU with a dynamic number of
    Oyvind>> peripherals would be a poor impeadance match with eCos
    Oyvind>> static cdl files.

    >> According to the design, CDL files do not have to be static. CDL is
    >> embedded in a general-purpose scripting language, Tcl. Conceptually
    >> that gives it the flexibility to adapt to changing hardware, including
    >> reconfigurable systems. The problems are:
    >> 
    >> 1) the CDL implementation is still incomplete, for a variety of
    >> reasons I do not intend to go into here.
    >> 
    >> 2) not all the concepts behind CDL are widely understood, leading to
    >> flawed approaches like generating static CDL files.

    Oyvind> I knew that, but forgot while I wrote what I did. I can
    Oyvind> see how a non-TCL guru would want to generate CDL instead
    Oyvind> of understanding the finer point of TCL+CDL :-)

    Oyvind> Is there a fundamental reason why CDL should not be
    Oyvind> generated?

With configurable h/w there are two main ways of handling things:

1) have a separate tool which takes the h/w definition file and
   generates static CDL, the HAL header files defining things like I/O
   addresses and interrupt vectors, etc. Then run up ecosconfig or the
   graphical configuration tool, as desired.

2) have an intelligent CDL script which processes the h/w definition
   file, either directly or by invoking a separate utility and reading
   its output, and generates the appropriate configuration options in
   memory. In addition have a define_proc which will create the HAL
   header files etc.

Approach (2) involves one less step for the user so there is less to
go wrong. It also maintains the idea of a read-only component
repository as far as application developers are concerned. The
generated CDL options only live in memory, there is no need to write
them to a file. The generated HAL headers live in the build tree
alongside other generated headers like <pkgconf/system.h>. So from the
eCos perspective everything pretty much works the same as with more
traditional h/w targets.

Writing the intelligent CDL script is obviously going to be more
challenging. There is also the problem of telling that script where
the h/w definition file is located, but that should not be a major
obstacle.

So although there is nothing to stop people from generating static CDL
scripts, I do consider it to be a sub-optimal solution. If a CDL/Tcl
guru is required there is always http://www.ecoscentric.com/develop.shtml

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: NIOS2 toolchain build failure under Cygwin

[Øyvind Harboe]

On 09 Aug 2006 21:05:33 +0100, Bart Veer <bartv@ecoscentric.com> wrote:
> >>>>> "Oyvind" == =?ISO-8859-1?Q?=D8yvind Harboe?= <ISO-8859-1> writes:
>
>     Oyvind>> Though I can see how a soft-CPU with a dynamic number of
>     Oyvind>> peripherals would be a poor impeadance match with eCos
>     Oyvind>> static cdl files.
>
>     >> According to the design, CDL files do not have to be static. CDL is
>     >> embedded in a general-purpose scripting language, Tcl. Conceptually
>     >> that gives it the flexibility to adapt to changing hardware, including
>     >> reconfigurable systems. The problems are:
>     >>
>     >> 1) the CDL implementation is still incomplete, for a variety of
>     >> reasons I do not intend to go into here.
>     >>
>     >> 2) not all the concepts behind CDL are widely understood, leading to
>     >> flawed approaches like generating static CDL files.
>
>     Oyvind> I knew that, but forgot while I wrote what I did. I can
>     Oyvind> see how a non-TCL guru would want to generate CDL instead
>     Oyvind> of understanding the finer point of TCL+CDL :-)
>
>     Oyvind> Is there a fundamental reason why CDL should not be
>     Oyvind> generated?
>
> With configurable h/w there are two main ways of handling things:
>
> 1) have a separate tool which takes the h/w definition file and
>    generates static CDL, the HAL header files defining things like I/O
>    addresses and interrupt vectors, etc. Then run up ecosconfig or the
>    graphical configuration tool, as desired.
>
> 2) have an intelligent CDL script which processes the h/w definition
>    file, either directly or by invoking a separate utility and reading
>    its output, and generates the appropriate configuration options in
>    memory. In addition have a define_proc which will create the HAL
>    header files etc.
>
> Approach (2) involves one less step for the user so there is less to
> go wrong. It also maintains the idea of a read-only component
> repository as far as application developers are concerned. The
> generated CDL options only live in memory, there is no need to write
> them to a file. The generated HAL headers live in the build tree
> alongside other generated headers like <pkgconf/system.h>. So from the
> eCos perspective everything pretty much works the same as with more
> traditional h/w targets.
>
> Writing the intelligent CDL script is obviously going to be more
> challenging. There is also the problem of telling that script where
> the h/w definition file is located, but that should not be a major
> obstacle.
>
> So although there is nothing to stop people from generating static CDL
> scripts, I do consider it to be a sub-optimal solution. If a CDL/Tcl
> guru is required there is always http://www.ecoscentric.com/develop.shtml

I'm not convinced that it is better to solve this in the TCL domain.
There are very few engineers who can or want to use TCL(I certainly
try to hide those skills so I don't get that sort of work :-) as
opposed to other solution domains where static cdl files can be
generated. I'm not sure why it is important that a repository is write
only. It's better to have this problem solved in a slightly
sub-optimal programming language where multiple engineers can actually
touch the code.

ecos.ecc is generated, modified and still part of my source code/goes
into source control, so why not a dynamic HAL as well? Especially
since a generated HAL can be part of a seperate eCos repository...

(The fact that ECOS_REPOSITORY can support multiple repositories
surprised me and has me hatching evil plans as I write :-)





-- 
Øyvind Harboe
http://www.zylin.com

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Configtool with mulitiple repository support...

[Andy Jackson]

> On Wed, Aug 09, 2006 , Andrew Lunn wrote:
> At the time it was added, John commented that it required some work to
> make configtool support this. So i was never added. To me it seems
> like the configtool is unmaintained anyway. If it stays like this, i
> would suggest it is dropped in the next official release. This is a
> shame given that there has been some recent interest in bringing it up
> to date with recent versions of xWidgets and make it build using
> automake.

I think that it is a shame that this situation exists as I use the 
Configtool exclusively as my build tool for both the eCos library and our
actual end applications. Anyway, as such I have wanted the mulitple 
repository feature for some time now and so was delighted to discover that 
it is already supported in the CDL library. To that end I have created a 
version of the Configtool that supports two repositories. This is largely 
because it best suits my current way of working, but it could be extended to 
support more if there was demand.

If anyone wants to try it, I have put an executable (cygwin only) up on our 
web site (www.xylanta.com) and I would welcome the feedback regarding 
problems etc. I believe that it can co-exist happily along side a single 
repository version, but there is no warranty :-). There are no patches at 
present as the changes are not particularly clean as I couldn't resist 
reformating large chunks of the code, but I'm happy to make them available 
or contribute them if they are likely to be of use.

In addition to the multiple repository feature, the executable also includes 
a few other fixes and enhancements such as the ability to add/remove 
hardware packages if desired.

    Andy..


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: NIOS2 toolchain build failure under Cygwin

[Grant Edwards]

In gmane.os.ecos.general, you wrote:

> I believe I'm seing the same segmentation fault.
>
> Did you find a way to resolve this problem?

Sort of:  Use Linux.

> My first thoughts was to try to revert to an older GCC version for
> CygWin or worst case attempt a cross-build from Linux.

I just switched to Linux.  Once I get everything else ironed
out, I'll mess with Cygwin again (assuming my client really
wants me to).

Building eCos for NIOS2 is the biggest mess I've ever seen: A
Shell script wrapper for a Java program that generates a CDL
file that generates a shell script that generates a Perl script
that calls a Java program that generates include files, etc.
etc.

What a pile.

-- 
Grant Edwards                   grante             Yow!  I HAVE a towel.
                                  at               
                               visi.com            

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss