[PATCH 8/9] fsdsosfsname01: Ensure endian correctness

Ralf Kirchner ralf.kirchner at embedded-brains.de
Tue Jun 4 08:08:12 UTC 2013


Hi Cynthia,
Please see my replies below.

Kind Regards
	Ralf Kirchner

Am 03.06.2013 16:55, schrieb Rempel, Cynthia:
>>
>>> On 05/31/2013 03:42 PM, Ralf Kirchner wrote:
>>>> diff --git a/testsuites/fstests/fsdosfsname01/image_bin_le_multibyte.h
>>>> b/testsuites/fstests/fsdosfsname01/image_bin_le_multibyte.h
>>>> +/*
>>>> + *  Declarations for C structure representing a disk image
>>>> + *
>>>> + *  WARNING: Automatically generated -- do not edit!
>>>> + */
>>>> +#ifndef IMAGE_BIN_LE_MULTIBYTE_H_
>>>> +#define IMAGE_BIN_LE_MULTIBYTE_H_
>>>> +
>>>
>>> AFAIU, this code qualifies is a hex dump of some binary, seemingly having been
>>> generated by some seemingly unfree tool.
>> It is generated from init.c if PRINT_DISK_IMAGE != 0.
> 
> Thanks Sebastian for the clarification :)
> 
> Could a rule in the Makefile.am be added to generate testsuites/fstests/fsdosfsname01/image_bin_le_multibyte.h and then not include the file in the repo?
> If the file is needed for comparing a new build vs. the working build (for testing purposed), then it makes sense to keep image_bin_le_multibyte.h...
The problem is that from within the test (running on a simulator like
SIS) we do not have access to the file system of the PC on which the
test gets executed. This is why the current handling is:
If PRINT_DISK_IMAGE != 0, print the disk images to the console and from
there copy them manually into the header files.
It might be possible to activate this from the Makefile but due to the
missing file system access it would still remain a semi-automatic
process. This is why I did not take the time to investigate further into
activating this from the Makefile.
> 
> Could the line 
> + *  WARNING: Automatically generated -- do not edit!
> 
> be changed to
> + *  WARNING: Automatically generated by init.c if PRINT_DISK_IMAGE != 0 -- do not edit!
I already did that ;-)
> 
>>>
>>> => In this shape this code violates the RTEMS license and may not be applied to
>>> RTEMS.
>>>
>>>
>>> Please reimplement this by using free tools.
>> So if I use notepad.exe on Windows to write RTEMS source code I violate the
>> RTEMS license?
> I suspect there was a little confusion on how the file was generated, but it appears Sebastian cleared that up quite well.
> Cindy
> --
> Sebastian Huber, embedded brains GmbH
> 
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
> 
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
> 
> 
> 
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
> 


-- 
--------------------------------------------
Embedded Brains GmbH
Ralf Kirchner          Dornierstr. 4
D-82178 Puchheim       Germany
email: ralf.kirchner at embedded-brains.de
Phone: +49-89-18 94 741-17
Fax:   +49-89-18 94 741-08

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.



More information about the devel mailing list