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: Logging (again!)
+1 ... this all seems very reasonable to me. The lower the learning curve to get started the better, and most people have simple logging needs to get started. On Fri, 6 Jul 2018 at 00:18, Christopher Collins wrote: > Hello all, > > My logging obsession continues. I have submitted a giant PR > (https://github.com/apache/mynewt-core/pull/1249) which changes all > existing packages to use the modlog facility rather than directly call > into the `sys/log` API. I think this is the right direction, but it is > a somewhat major change, and I am certainly open to feedback. > > I see two benefits of this change: > > * For simple logging to the console, apps don't need to define and > register a log. Just use `MODLOG_DFLT` to log a message. > > * Most packages don't need to define and expose a log object, and the > application doesn't need to register it. The package just writes log > messages to its reserved log module ID. This eliminates the need for > every app to register the `ble_hs_log` and `oc_log` log objects, for > example. > > Here is what I personally would like to see in Mynewt, going forward: > > 1. Every package uses modlog; nothing uses the log API directly > (except for modlog itself :) ). > > 2. Applications that just want to log to the console just use the > `MODLOG_DFLT` macro. This macro writes a printf-style string to the > "default" module, which routes to the console unless remapped. > > 3. If a library needs to log messages, it defines a log module syscfg > setting for each module it uses. It is important that syscfg is used > here so that the user can override them in case two packages choose the > same module ID(s). > > 4. Newt adds two new syscfg setting types: > * log_module_owner > * log_module > > `log_module_owner` is used to stake out a unique module ID. If two > `log_module_owner` settings specify the same number, that indicates a > conflict in the module number space, and newt can abort the build with a > meaningful error. > > `log_module` is used when a package wants to log to "someone else's" > module. Newt doesn't complain if one or more `log_module` settings have > the same value as a `log_module_owner` setting. > > A new command would be added to newt to display all assigned log module > IDs in a target. > > All comments welcome. > > Thanks, > Chris >
Re: Logging (again!)
+1 This all seems quite reasonable to me. > On Jul 5, 2018, at 3:18 PM, Christopher Collins wrote: > > Hello all, > > My logging obsession continues. I have submitted a giant PR > (https://github.com/apache/mynewt-core/pull/1249) which changes all > existing packages to use the modlog facility rather than directly call > into the `sys/log` API. I think this is the right direction, but it is > a somewhat major change, and I am certainly open to feedback. > > I see two benefits of this change: > > * For simple logging to the console, apps don't need to define and > register a log. Just use `MODLOG_DFLT` to log a message. > > * Most packages don't need to define and expose a log object, and the > application doesn't need to register it. The package just writes log > messages to its reserved log module ID. This eliminates the need for > every app to register the `ble_hs_log` and `oc_log` log objects, for > example. > > Here is what I personally would like to see in Mynewt, going forward: > > 1. Every package uses modlog; nothing uses the log API directly > (except for modlog itself :) ). > > 2. Applications that just want to log to the console just use the > `MODLOG_DFLT` macro. This macro writes a printf-style string to the > "default" module, which routes to the console unless remapped. > > 3. If a library needs to log messages, it defines a log module syscfg > setting for each module it uses. It is important that syscfg is used > here so that the user can override them in case two packages choose the > same module ID(s). > > 4. Newt adds two new syscfg setting types: >* log_module_owner >* log_module > > `log_module_owner` is used to stake out a unique module ID. If two > `log_module_owner` settings specify the same number, that indicates a > conflict in the module number space, and newt can abort the build with a > meaningful error. > > `log_module` is used when a package wants to log to "someone else's" > module. Newt doesn't complain if one or more `log_module` settings have > the same value as a `log_module_owner` setting. > > A new command would be added to newt to display all assigned log module > IDs in a target. > > All comments welcome. > > Thanks, > Chris
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
BLE security/encryption/passkey authentication
Hello all, Is there any documentation regarding the security aspects of Nimble (.e.g pairing, bonding, passkeys etc)? The mynewt documentation covers the basic advertising and GATT systems quite well, and am happily using those, but I'm struggling to find any information on the security side of things. Amr
newtmgr fs command fails in sim
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: $ newtmgr -c serialsim fs download /cfg/id.txt id.txt Error: 5 The newtmgr connection is fine and of course the app is running: $ newtmgr conn show Connection profiles: serialsim: type=serial, connstring='/dev/ttys002' And here is a proof that newtmgr is behaving properly and is properly configured: $ newtmgr -c serialsim stat nffs_stats stat group: nffs_stats 0 nffs_gccnt 5 nffs_hashcnt_ins 0 nffs_hashcnt_rm 52 nffs_iocnt_read 13 nffs_iocnt_write 0 nffs_object_count 1 nffs_readcnt_block 0 nffs_readcnt_copy 0 nffs_readcnt_crc 1 nffs_readcnt_data 2 nffs_readcnt_detect 6 nffs_readcnt_filename 0 nffs_readcnt_format 0 nffs_readcnt_gccollate 22 nffs_readcnt_inode 21 nffs_readcnt_inodeent 0 nffs_readcnt_object 0 nffs_readcnt_rename 1 nffs_readcnt_update Is it normal that the fs support doesn't work in the simulator? Perhaps the commands only work with FatFS, although I'd prefer to use the smaller NFFS for now. K.
