Tools for eCos 2.0

Tools for eCos 2.0

[Jonathan Larmour]

Hi overseers,

One of the things the eCos project needs for our upcoming release are 
prebuilt GNU tools for some of our primary targets. The burden of having 
to build tools, especially for windows users, can be quite large. Our 
users are embedded developers, not GNU enthusiasts per se! Rebuilding 
toolchains isn't something we expect them to have to do, and we've had to 
spend a huge amount of time helping and supporting people who do it over 
the years.

So as part of our next major release (2.0) we are intending to integrate 
support for downloading some prebuilt toolchains... and since eCos comes 
from sources.redhat.com, so should these tools. These tools would only 
really be usable with eCos though - although built in a standard way, we 
have removed newlib which should scupper most other folk's chances of 
using them as generic tools.

However eCos is big enough already (16Mb even in .tar.bz2 form!), and 
these tools will no doubt be popular - at least one tools download per 
eCos download. So in the interests of general harmony and peace for 
everyone on s.r.c :-) we think it is best all round that there's a limit 
on the download bandwidth to act as a deterrent to using s.r.c instead of 
a mirror.

WU-FTPD supports this in /etc/ftpaccess using the throughput directive. 
It's best to apply that just to where these tools would live, probably 
/sourceware/ftp/anonftp/pub/ecos/gnutools/

I've been thinking of something like:

throughput /var/ftp /pub/ecos/gnutools/* * 8192 0.5 *

which restricts downloads to 8192 bytes/sec for the first tools download, 
and half that each time for each subsequent one. Given that tools sizes 
are about 10-15Mb, that seems like about the maximum level of pain ;-), 
although if people didn't mind a higher byterate, obviously we wouldn't 
mind! We only expect people to download one tool in general of course.

The only slightly annoying thing is that you can't stop it applying to 
mirrors as well, without a lengthy field at the end - it doesn't use the 
classes :-|. That's probably not that much of a problem though - we intend 
these files to change very infrequently.

Out of interest, right now we're looking at 5 toolchains for Linux and 
Windows, giving a grand total of 116Mb, which is a fair whack of FTP space 
too, but we don't really expect this to grow much at least.

Anyway, I just wanted to run this by overseers to check for any comments. 
Obviously if people think this is overkill and just allowing unrestricted 
downloads would be fine, then we're not going to object :-).

Jifl
-- 
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

Re: Tools for eCos 2.0

[Christopher Faylor]

[Reply-To set to overseers]
On Wed, Feb 19, 2003 at 08:52:42PM +0000, Jonathan Larmour wrote:
>One of the things the eCos project needs for our upcoming release are
>prebuilt GNU tools for some of our primary targets. The burden of having
>to build tools, especially for windows users, can be quite large. Our
>users are embedded developers, not GNU enthusiasts per se!
>[snip]
>However eCos is big enough already (16Mb even in .tar.bz2 form!), and
>these tools will no doubt be popular - at least one tools download per
>eCos download.
>[snip]
>Anyway, I just wanted to run this by overseers to check for any comments. 
>Obviously if people think this is overkill and just allowing unrestricted 
>downloads would be fine, then we're not going to object :-).

Cygwin disallows direct downloads from sources.redhat.com, relying on
mirrors to handle this.  Without this restriction cygwin would probably
consume a significant portion of the bandwidth of sources.redhat.com.

I don't think there is any reason why eCos should be taking up a
disproportionate amount of bandwidth if, as you suspect, it will be
popular.  So we may decide to enforce the mirrors-only rule here.

I'm not sure that I understand the argument of users not being "GNU
enthusiasts".  Since you are targeting a technical audience, I don't see
why this is an issue.

I assume that you will be dealing with the GPL issues.  You will be
providing sources for all of the binaries you produce, right?  Are the
sources included in your disk space estimate?

On a more personal note, if you are going to be providing binaries that
duplicate anything that is already available in a cygwin release then I
would strongly object to that.

Finally, if you are using this in any way as a distribution method for a
commercial venture then I think it is not appropriate for
sources.redhat.com.

cgf

Re: Tools for eCos 2.0

[Jonathan Larmour]

Christopher Faylor wrote:
> 
> Cygwin disallows direct downloads from sources.redhat.com, relying on
> mirrors to handle this.  Without this restriction cygwin would probably
> consume a significant portion of the bandwidth of sources.redhat.com.
 >
 > I don't think there is any reason why eCos should be taking up a
 > disproportionate amount of bandwidth if, as you suspect, it will be
 > popular.  So we may decide to enforce the mirrors-only rule here.

I don't think it should either. It may not even happen! Introducing a 
download bandwidth limit seems like the best compromise as it guarantees 
it won't use a disproportionate amount of bandwidth in case it does.

There will undoubtedly be a rush as a new release comes out, which is 
primarily what we want to mitigate, but that won't be representative for 
policy afterwards. In particular, when the release is announced we can't 
guarantee all the mirrors will have updated (we'll delay the announcement 
a few days but we can't make people wait forever). That doesn't apply so 
much to cygwin as it updates piecemeal - it doesn't _really_ matter if 
people have diff 2.7.2-1 versus 2.7.2-2.

I'd like disallowing downloads entirely to be something we can use later 
if we find the situation to definitely warrant it. If we do it straight 
away, we'll never know whether it was warranted or not. Right now we're 
only concerned about mitigating the effect on sources.redhat.com at the 
time of the announcement.

Incidentally, I found some out of date stuff on 
<http://sources.redhat.com/mirrors.html> :

- ftp.freesoftware.com is no more

- ftp.carfield.com.hk doesn't appear to work, although www.carfield.com.hk 
does.

- You could rename the funet.fi link to use sources.redhat.com instead of 
sourceware.cygnus.com now

- Japan's sysg.kek.jp doesn't appear to work

- Norway's ftp.pvv.ntnu.no is no more

- ftp.sun.ac.za's link should be 
ftp://ftp.sun.ac.za/mirrorsites/sourceware.cygnus.com/pub/

- ftp.sdn.co.za doesn't appear to work, although that really could be just 
temporary

- Taiwan's ftp1.sinica.edu.tw link should be 
ftp://ftp1.sinica.edu.tw/pub3/GNU/CYGNUS/

- sunsite.org.uk no longer mirrors sourceware

- unix.hensa.ac.uk should now instead be: 
ftp://ftp.mirror.ac.uk/sites/sources.redhat.com/pub/ and 
http://www.mirror.ac.uk/sites/sources.redhat.com/pub/

Hope this helps.

> I'm not sure that I understand the argument of users not being "GNU
> enthusiasts".  Since you are targeting a technical audience, I don't see
> why this is an issue.

Our audience is embedded developers. They want to build eCos and we've put 
in a lot of effort to make building eCos as easy as possible. They know 
how to develop embedded applications.

However we don't expect them to have to understand how to deal with 
building toolchains. We already have detailed instructions on building a 
toolchain, but we get frequent messages due to problems with building the 
tools. Helping people build tools isn't meant to be an issue for us or for 
them. Just like you wouldn't expect cygwin users to build their packages 
from scratch and wouldn't want to have to deal with the resulting problems 
if you did. :-)

Also remember this is the _only_ eCos site. Any impediments we throw in 
people's way stops people using eCos *at all*, and instead more likely to 
go with their proprietary closed source alternative.

> I assume that you will be dealing with the GPL issues.  You will be
> providing sources for all of the binaries you produce, right?  Are the
> sources included in your disk space estimate?

Ah yes, I didn't include those as to be honest I don't expect many people 
to download them with the prebuilts there. It's just one set of sources 
for the whole lot. The total comes out as 38Mb (gcc-core, gcc-g++, 
insight, binutils), but since most of these are just official releases we 
_could_ just distribute the small number of patches against them. But 
naturally we'd prefer to distribute the true sources we used.

> On a more personal note, if you are going to be providing binaries that
> duplicate anything that is already available in a cygwin release then I
> would strongly object to that.

Only if you distribute arm-elf-gcc and we didn't know it :-). These are 
just builds of gcc, insight and binutils for cross targets.

> Finally, if you are using this in any way as a distribution method for a
> commercial venture then I think it is not appropriate for
> sources.redhat.com.

Nope. It's just free software and a free public release. Yes my employer 
is contributing most of the effort for this next release of eCos, but in 
exactly the same way as Red Hat, Code Sourcery or many other companies do 
towards other free projects.

Ta,

Jifl
-- 
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine