can we include dosfs?

[Ed Sutter]

At various points in time I've used both of these.
Don't recall any significant issues with either, but then I personally didn't use them
much, I just did the ports for other users.  Also, there's a JFFS implementation
that I wrote from scratch (just referring to JFFS docs).  Again, I didn't use that
much either; primary user there as I recall was Bill Gatliff (many moons ago).

Not sure what "CLI" you're talking about, but if its something I wrote, you're
welcome to use any of it.
Again, I apologize for my "off-line" state...
Too much stuff going on in and out of work to do much here.
Ed
>
> On Jun 19, 2016 8:51 PM, "Ben Gras" <beng at shrike-systems.com <mailto:beng at shrike-systems.com>> wrote:
> >
> > On Mon, Jun 20, 2016 at 4:33 AM, Chris Johns <chrisj at rtems.org <mailto:chrisj at rtems.org>> wrote:
> > > On 20/06/2016 12:24, Ben Gras wrote:
> > >>
> > >> I'm looking at building umon from RSB, to replace uboot, the next step
> > >> to mainlining all the beagle bsp support.
> > >
> > >
> > > Great.
> > >
> > >> It seems umon doesn't read FAT filesystems. Does anyone see any
> > >> license objection to including
> > >> dosfs.c (http://www.zws.com/products/dosfs/) as seems to have happened
> > >> with the original umon?
> > >
> > >
> > > How does that implementation compare with
> > > http://elm-chan.org/fsw/ff/00index_e.html? This is used by Xilinx in the
> > > first stage bootloader.
> >
> > They look similar enough. They both rely on some low-level device
> > access functions
> > to be provided by the user, which is fine. The license isn't terribly
> > clear I think:
> >
> > / FatFs module is a free software that opened under license policy of
> > / following conditions.
> > /
> > / Copyright (C) 2016, ChaN, all right reserved.
> > /
> > / 1. Redistributions of source code must retain the above copyright notice,
> > /    this condition and the following disclaimer.
> > /
> > / This software is provided by the copyright holder and contributors "AS IS"
> > / and any warranties related to this software are DISCLAIMED.
> > / The copyright owner or contributors be NOT LIABLE for any damages caused
> > / by use of this software.
> >
> > Do you think we can include it?
>
> Looks like MIT more or less to me. So no license issues that I see.
>
> Review the one Chris suggested though.
>
> > The dosfs license is, though unfortunately not any standard license,
> > clearer with
> > the no-strings-attached language, and I know it has been hooked up to
> > umon before,
> > so that seems lower-risk to me at the moment.
>
> What's the license say?
>
> > > I also have a JFFS bootloader implementation that can be added so umon can
> > > be booted from a JFFS2.
> > >
> > >> Can we then include the original umon CLI interface or is that a
> > >> license issue? If so I can re-implement it.
> > >
> > >
> > > I do not know and yes it would be nice to use what is available.
> >
> > Let's see what Ed says about including the CLI code. It is e.g.:
> >
> > http://users.ece.utexas.edu/~mcdermot/arch/projects_fall_09/Team_07/umon-1.17/umon_main/target/common/fatfs.c <http://users.ece.utexas.edu/%7Emcdermot/arch/projects_fall_09/Team_07/umon-1.17/umon_main/target/common/fatfs.c>
>
> +1
>
> >
> > > Chris
> > > _______________________________________________
> > > umon-devel mailing list
> > > umon-devel at rtems.org <mailto:umon-devel at rtems.org>
> > > http://lists.rtems.org/mailman/listinfo/umon-devel
> > _______________________________________________
> > umon-devel mailing list
> > umon-devel at rtems.org <mailto:umon-devel at rtems.org>
> > http://lists.rtems.org/mailman/listinfo/umon-devel
>
>
>
> _______________________________________________
> umon-devel mailing list
> umon-devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/umon-devel


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/umon-devel/attachments/20160620/36607f9c/attachment-0002.html>