I was not referring to hw drivers in general; just the BLE stack. I just dont really know what suspend/resume would mean to the BLE stack. Well, I am referring mainly to the controller… I guess it could mean things to the host. I am not strongly against it; I just think if we move it there then things like create, open, close, suspend, resume should make sense to do to the driver. If suspend and resume dont do anything but the rest do, that is fine as well. Just musing :-)
> On Sep 15, 2016, at 6:44 PM, Sterling Hughes <[email protected]> wrote: > > I was suggesting it be moved to hw/drivers/nimble. > > It’s similar to how other OSes do it, they tend to have the hw drivers in the > drivers directory, even for the networking stack components. I don’t feel > strongly about it, but thought, why shouldn’t we keep to convention. > > I definitely think the HW drivers should use our device framework, unless > there is a compelling reason not to. It will allow there to be a central > registry of drivers, and if the BT stack needs to be suspended/resumed, > that’s a logical place to hook it in? > > Sterling > > On 15 Sep 2016, at 18:39, will sanfilippo wrote: > >> Just a nit; I need to digest this a bit more but will net/nimble/drivers be >> moved to drivers/nimble or hw/drivers/nimble? >> >> I am also not sure why you would move what is in there into the drivers >> directory and make it conform to the standard drivers as I am not sure what >> that would mean for the BLE stack but we could do it if folks thought it a >> good idea. >> >>> On Sep 15, 2016, at 3:50 PM, Sterling Hughes <[email protected]> wrote: >>> >>> Hey, >>> >>> I wanted to get this kicked off, so we can make the changes fairly quickly >>> after the sterly_refactor merge next week (while still giving enough time >>> for discussion.) >>> >>> Please take this as a _rough_ first cut proposal. I want people to >>> bikeshed this discussion, mainly because I only want to do this re-org once >>> in the foreseeable future :-) >>> >>> Proposed changes (on top of the sterly_refactor and develop branch.) >>> >>> - IP and Wi-Fi support is moved from libs (e.g. libs/inet_def_service, >>> libs/wifi_mgmt) and placed in the net/ directory. >>> >>> - Any IP stack is moved into net/ip >>> >>> - net/nimble/drivers is moved to drivers/nimble. These drivers are >>> modified to conform to our driver framework. >>> >>> - libs/tinycrypt and libs/mbedtls are placed in crypto/mbedtls, >>> crypto/tinycrypt >>> >>> - libs/bleuart is placed in net/nimble/host/profiles >>> >>> - libs/bootutil, libs/boot_serial are both placed in boot/ along with >>> apps/boot >>> >>> - elua is completed removed from mynewt-core. mynewt-core should provide >>> the core engine for any scripting language (JS, Lua, Python), but not >>> bundle one by default. >>> >>> - drivers is moved to hw/drivers, libs/cmsis-core is moved to >>> hw/arch/arm/cmsis-core >>> >>> - fcb is moved from sys/fcb to fs/fcb >>> >>> - libs/console and libs/shell are moved to sys/console and sys/shell >>> >>> - examples/ TLD is created, and libs/flash_test, libs/crash_test, >>> apps/blecent, apps/bleprph, apps/bletest, apps/bletiny, apps/bleuart, >>> apps/blinky, apps/slinky are all moved to examples. >>> >>> - libs/os is moved to TLD “os” (or core/os? kern/os?) >>> >>> - libs/testreport and libs/testutil are moved to a TLD “test/“ >>> >>> - libs/util is broken up into crypto/hash (base64, crc), time/datetime >>> (datetime.c), and TPQ is deleted (where do we put cbmem? sys/defs? I think >>> we should probably migrate queue.h from OS there too.) >>> >>> - libs/imgmgr moved to mgmt/, libs/newtmgr moved to frameworks/newtmgr >>> >>> - coap broken out of libs/iotivity and placed into net/. >>> >>> - libs/iotivity broken into frameworks/oic. >>> >>> - sys/mn_socket is moved to net/ >>> >>> - sys/reboot: should this be moved to boot or somewhere else, or just >>> remain in sys/ >>> >>> Best, >>> >>> Sterling >>
