Re: newtmgr fs command fails in sim
Hi Jacob, 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. Came back to this again today writing some internal documentation. I do agree this leads to some potentially false conclusions, especially to someone new to Mynewt since 'CONFIG_NFFS' sounds like it may well do what the comment is saying, and it's part of the official FS documentation here: https://mynewt.apache.org/latest/os/modules/fs/fs.html#description I missed that myself, but appreciate you pointing it out since it may have cause a problem in the future that might not have been obvious at first glance. K.
Re: newtmgr fs command fails in sim
Hi Jacob, Excellent point about the flash usage, and figuring out how to perhaps make it easier for packages to play well together in a single filesystem without hijacking the config system out of necessity. 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) Kevin
Re: newtmgr fs command fails in sim
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 wrote: > > > > > > > > > On Jul 6, 2018, at 5:49 PM, Kevin Townsend > 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 >
Re: newtmgr fs command fails in sim
Hi, On Fri, Jul 6, 2018 at 6:24 PM marko kiiskila wrote: > > > > > On Jul 6, 2018, at 5:49 PM, Kevin Townsend > > 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
Re: newtmgr fs command fails in sim
> On Jul 6, 2018, at 5:49 PM, Kevin Townsend 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.
Re: newtmgr fs command fails in sim
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 Kevin
Re: newtmgr fs command fails in sim
Hi Kevin, On Fri, Jul 06, 2018 at 02:41:17PM +0200, Kevin Townsend wrote: > I'm doing some initial development using only the simulator (for > convenience sake), and was testing out 'newtmgr fs' support to quickly > get data to and from the simulator. > > My sim target is setup to use NFFS using mostly default values: > > # NFFS filesystem > FS_CLI: 1 # Include shell FS commands > CONFIG_NFFS: 1 # Initialize and configure NFFS into the > system > NFFS_DETECT_FAIL: 2 # Format a new NFFS file system on > failure to detect > > Everything works fine from shell when I start the .elf file and create > an NFFS file in code, and I can see the file and contents via cat: > > ls /cfg > 604693 5 /cfg/id.txt > 604693 1 files > 604900 compat> cat /cfg/id.txt > 5678 > > But when I try to do anything with 'newtmgr fs' (up or down) I always > get *error 5*, which I assume corresponds to > https://github.com/apache/mynewt-core/blob/master/fs/fs/include/fs/fs.h#L72: 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). Did you enable the `FS_NMGR` syscfg setting? Chris
