[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Date: Thu, 01 Oct 2009 18:10:39 -0500
- From: strauman at slac.stanford.edu (Till Straumann)
- Subject: 4.10 Approaching
Ralf Corsepius wrote:
> On 10/01/2009 04:02 AM, Kate Feng wrote:
>> Ralf Corsepius wrote:
>>> On 09/30/2009 06:54 PM, Kate Feng wrote:
>>>> Ralf Corsepius wrote:
>>>>> On 09/30/2009 05:36 PM, Feng, Kate wrote:
>>>> Please advise.
>>> Are using home-grown toolchains based on the contents of
>>> ftp://ftp.rtems.org/pub/rtems/SOURCES/4.10 ?
>>> Its contents is a bit outdated, I haven't managed to keep it uptodate,
>>> because the rapid development binutils, newlib and gdb currently are
>>> subject of kept me busy otherwise (building binary toolchains). (
>>> Which OS are you using?
>> I am in the stage of having both RHEL5 and the latest
> Compare for my other mail.
> I would seriously advise you to use the prebuilt CentOS5 rpms on RHEL5.
> On Ubuntu, you can try "alien"ized CentOS rpms.
>>> May-be the toolchain you need already exists pre-built.
>> However, I always had to build the binary from source code just in
>> case something is missing. See the patches I sent in 2009 for the
>> They might not apply to others' applications, but they are important
>> for my applications, although it could be time consuming to
>> apply patches, rebuild and rebuild.
> Well, you might be aware that these patches of yours are controversal?
I actually would really recommend the HAVE_BLKSIZE patch - which
BTW has been recommended for a looong time; see e.g.,
libfs/src/nfsclient/README. It greatly improves stdio on any blocked
msdosfs and NFS already do provide the necessary blocksize information.
IMFS currently sets the blocksize to 0 for directories. zero is also
the default if a filesystem does not set/provide a blocksize.
newlib stdio correctly handles the case of a zero blocksize but
some 'fseek()' performance gain could be achieved by using
BUFSIZ/1024 in these cases.
I can't really see *anything* controversial in this case.
> rtems-users mailing list
> rtems-users at rtems.org