[PATCH 8/9] fsdsosfsname01: Ensure endian correctness

[Ralf Kirchner]

Forgot an important point below.

Kind Regards
	Ralf Kirchner

Am 04.06.2013 10:08, schrieb Ralf Kirchner:
> 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.
Purpose of this images is to ensure that we are endian correct. Thus the
images get created ONLY on a little endian target. Then on the target to
be tested the test generates the same image in a RAM file system and
compares it against the saved images from the header files.
>>
>> 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.