[GSoC project] Implementation of ISO9660 filesystem

[Joel Sherrill]

Christophe.. none of this should particularly scare you off. :-D
It is just the way open source is.

Any refactoring for file system infrastructure clarity
improvements you and your mentor encounter
should be included.   I don't personally see the
mount issue as part of your GSoC proposal.  If you
want to include it as potential "bonus work" if
you get done early, then do so.  But it is
independent of the ISO9660 file system.

--joel

On 04/04/2011 05:57 AM, Christophe Huriaux wrote:
> 2011/4/4 Sebastien Bourdeauducq<sebastien at milkymist.org>:
>> Hi,
> Hi,
>
>
>> On Mon, 2011-04-04 at 10:25 +0200, Christophe Huriaux wrote:
>>> develop an ISO9660 filesystem implementation into RTEMS.
>> Have you had a look at the internal RTEMS filesystem APIs yet?
>>
>> Maybe you'd like to start by improving them, instead of (painfully)
>> writing new code for the current APIs which will increase the cost of
>> switching to a more sane filesystem API in the future (which I hope will
>> happen).
>> In particular, the eval_path system should disappear (it means a lot of
>> code duplication, pain and C string manipulation woes and bugs which
>> could easily be avoided), and the filesystem lacks locking (e.g. opening
>> a file then deleting it from another task breaks the FS and may crash
>> the complete system).
>    In fact while discussing about my project on IRC the eval_path and
> filesystem locking problems in the actual filesystem API have been
> pointed out, but apparently things to refactor are not easily
> listable, that's why I proposed to refactor filesystem helpers while
> developing this new filesystem.
>
>    It would provide additional goals to my project (as a "side effect"
> of my implementation), but I'm not currently able to determine how
> much time I will need to spend on these tasks, since I'm not really
> aware of what I'll need to do, that's why API improvement  is part of
> the project without being really detailed in my proposal.
>
>
>> A good example to draw ideas from is the FUSE API:
>> http://www.ibm.com/developerworks/linux/library/l-fuse/
>>
>> Regards,
>> Sebastien
>>
>> PS: I'm not participating in GSoC this year. I have simply ported YAFFS2
>> to RTEMS and I had a bad experience (in fact I'm still having it, we
>> recently found some more bugs which I suspect are eval_path related) due
>> to the poorly designed API. Just sharing my thoughts - deciding whether
>> to go with the current API or improving it isn't up to me.
>>
>>
>     As far as i know Chris Johns had similiar problems when
> implementing RFS and have also a fresh insight of what things should
> be fixed. Both of your guidances would be useful for me.
>
>
> Regards,
> Christophe Huriaux
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985