[PATCH 8/9] fsdsosfsname01: Ensure endian correctness

[Gedare Bloom]

On Sun, Jun 2, 2013 at 6:54 AM, Ralf Corsepius <ralf.corsepius at rtems.org> wrote:
> 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
>> new file mode 100644
>> index 0000000..bb0e565
>> --- /dev/null
>> +++ b/testsuites/fstests/fsdosfsname01/image_bin_le_multibyte.h
>> @@ -0,0 +1,3051 @@
>> +/**
>> + * @file image_bin_le_multibyte.h
>> + *
>> + * @ingroup [GROUP NAME]
>> + *
>> + * @brief [SHORT DESCRIPTION OF MODULE]
>> + */
>> +
>> +/*
>> + * Copyright (c) 2013 embedded brains GmbH.  All rights reserved.
>> + *
>> + *  embedded brains GmbH
>> + *  Dornierstr. 4
>> + *  82178 Puchheim
>> + *  Germany
>> + *<rtems at embedded-brains.de>
>> + *
>> + * The license and distribution terms for this file may be
>> + * found in the file LICENSE in this distribution or at
>> + *http://www.rtems.com/license/LICENSE.
>>
>> + */
>> +
>> +/*
>> + *  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.
>
The hex dump is just data. I have a pretty good idea how this file was
generated. I agree we should include the sources, and probably a
helper script to regenerate it, but I don't think it is required to do
so. Correct me if I'm wrong.

> => In this shape this code violates the RTEMS license and may not be applied
> to RTEMS.
>
I don't see how it violates the license. Please clarify.

>
> Please reimplement this by using free tools.
>
This seems like an irrelevant request.

> Ralf
>
>
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel