Maybe Im misunderstanding, as Im personally digging into a bunch of fs
stuff right now myself..
But Kevins code snippet brings up something im thinking about. In his
comments he has
>
> CONFIG_NFFS: 1 # Initialize and configure NFFS into the
> system
>
I dont agree with that comment, whats thats actually doing is turning on
the config subsystem and telling it to create its own nffs. Then hes
coattail riding on config's nffs partition.
the 'way' to create your own nffs seems to be to disable config entirely,
because in the bsp config fcb and nffs both want to use FLASH_AREA_NFFS,
and then add
- "@apache-mynewt-core/fs/nffs"
But obviously it seems like youd be well within you're rights to share a
disk resource between a bunch of packages.
However the way config and most packages work is to take a whole flash area
for themselves and pass it to nffs or fcb or whatever, so they actually
dont seem to share very well? Maybe config should be less opinionated and
take a premade fs, which the user (or bsp) preconfigured as an fcb or fat
or nffs or whatever. Then it wouldnt feel like im using configs disk (and
if I turn config off, the disk I was using wouldnt go away)
I also think this fits into something else Im trying to figure out which is
multiple nffs partitions and external flash. The flash area concept doesnt
work at all for that currently.
On Fri, Jul 6, 2018 at 12:12 PM Andrzej Kaczmarek <
andrzej.kaczma...@codecoup.pl> wrote:
> Hi,
>
> On Fri, Jul 6, 2018 at 6:24 PM marko kiiskila <ma...@runtime.io> wrote:
> >
> >
> >
> > > On Jul 6, 2018, at 5:49 PM, Kevin Townsend <ke...@adafruit.com.INVALID>
> wrote:
> > >
> > > Hi Chris,
> > >> The error codes that come back in newtmgr responses are always (or at
> > >> least should be) MGMT_ERR codes:
> > >>
> https://github.com/apache/mynewt-core/blob/42bb5acc2f049d346c81f25e8c354bc3c6afefd4/mgmt/mgmt/include/mgmt/mgmt.h#L65
> > >>
> > >> `MGMT_ERR_ENOENT` is indicated when the newtmgr command isn't
> recognized
> > >> (it is also used for other conditions; seems like we should have a
> > >> dedicated error code for "command not supported).
> > > Thanks for the point, and the quick reply!
> > >
> > > Command not supported would be more helpful, yes, but not a major
> problem.
> > >> Did you enable the `FS_NMGR` syscfg setting?
> > > That was indeed the problem. I did dig through the various packages
> looking at the CFG values, but didn't notice that one. Works great in the
> sim now with:
> > >
> > > # Enable newtmgr commands.
> > > STATS_NEWTMGR: 1 # Enable stats over newtmgr
> > > LOG_NEWTMGR: 1 # Enable log over newtmgr
> > > CONFIG_NEWTMGR: 1 # Enable config over newtmgr
> > > FS_NMGR: 1 # Enable 'fs' access from newtmgr
> > >
> > > It's a shame the naming is sort of inconsistent (inner OCD self
> speaking), but that's a minor detail. :P
> > >
> >
> > I know what you mean. There’s other examples of the same. But then
> renaming these would
> > break people’s build targets. Which is not nice :)
> >
> > Although I guess we could do this if we gave people enough warning.
>
> We can introduce new setting and set its default value to old setting,
> i.e.:
>
> syscfg.defs:
> FS_NEWTMGR:
> value: 'MYNEWT_VAL_FS_NMGR'
>
> This way people can continue using old settings for now and then
> transition to new settings. Would be good if old value can be marked
> as deprecated and newt would emit warning if deprecated setting is
> overriden in other package.
>
> I did similar change in RTT already:
>
> https://github.com/apache/mynewt-core/commit/67c430c5ecc8ac06af256e5d1bd487d3b6efdedc
>
> Best,
> Andrzej
>
