[PATCH 2/5] JFFS2: Import from eCos

Sebastian Huber sebastian.huber at embedded-brains.de
Mon Sep 16 07:17:38 UTC 2013


On 2013-09-15 04:12, Chris Johns wrote:
> Sebastian Huber wrote:
>> On 2013-09-14 00:54, Chris Johns wrote:
>>> Where is the device support ?
>>
>> I didn't import the flash device drivers from eCos. See <rtems/jffs2.h>
>> in the RTEMS support patch for the device support. The application has
>> to provide the flash access operations.
>>
>
> Would it make sense to have drivers added to libchip for commonly used devices ?

Yes, a flash driver frame work is definitely something we need in RTEMS.  We 
have one for NAND flashes which uses a similar structure than Linux MTD.  We 
may also contribute this in the future, but currently I have no time for this.

For the NOR flashes there is some support in the eCos code base, so we should 
consider to make use of it.

>
> Where can we find a real driver for a real device ? I feel we need real drivers
> as examples in RTEMS.

The file system tests work with a RAM based NOR simulator.  If you have a flash 
driver, then its pretty easy to provide the interface for JFFS2.

>
> I do not like the "application" needing to handle this. I think BSPs should
> provide drivers and not applications. The device is specific to a board and it
> is the role of the BSP to handle this sort of thing. If I use a BSP that has
> suitable flash devices I would expect the BSP to contain the support. It may be
> the application that enables and configures the support given a correctly
> working and mapped set of drivers from the BSP.

Using the current approach with a function pointer based interface is flexible 
(e.g. you can use whatever you want) and makes it possible to provide the JFFS2 
support without a flash driver framework.  I currently don't have the resources 
for a flash driver framework for RTEMS.  This might be also something for the 
next GSoC.

>
> I regretted not providing a real driver interface to the flash memory in the
> flashdisk block device. Having a real device interface means it can be opened
> and managed without the file system, for example erasing or testing the devices.
>
>>>
>>> Clause 2 concerns me.

This is a standard 2-clause BSD license.

>>>
>>> Is mixing GPLv2+exception and a BSD type license like this ok ?
>>>
>
> ??

Yes, the original red-black tree implementation is under BSD license.  The 
later contributions are under GPLv2+exception.

>
>>
>> This LICENSE file is part of the Linux import patch.
>>
>
> Found it. Thanks.
>
> Do any of the files that contain the reference to the LICENSE file get installed ?
>
> Chris

What do you mean with installed?

The only header file visible to applications is the <rtems/jffs2.h> file which 
is under the RTEMS license.  Everything else is only required to produce the 
JFFS2 object files.

-- 
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.



More information about the devel mailing list