Re: [OpenWrt-Devel] [LEDE-DEV] per-cpu IRQ stack on MIPS
On 2017-01-11 00:34, Jason A. Donenfeld wrote: > Hey folks, > > You might considering backporting this patchset to the LEDE/OpenWRT kernel: > > http://www.spinics.net/lists/mips/msg65937.html > > It prevents crashes when lots of different networking drivers are > stacked on top of eachother, like gre+l2tp+somethingelse. I've pushed the backport of these changes to my staging tree at https://git.lede-project.org/?p=lede/nbd/staging.git;a=summary I've already tested it on a MT7621 board and it works fine, please test it on more devices. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Data_Model_Structure_Proposal_for_OpenWRT
Hi Lada, Thank you for your feedback. The initial goal of this proposal is presenting the idea of adopting a data model structure which addresses the issue 1 given in the proposal and then defining data models based on this structure which addresses issue 2 given in the proposal. The JSON example given in the proposal was just to demonstrate an example how configuration properties and methods of an entity could be hosted in a single structure and how that structure could be used to generate UBUS objects. If the idea is embraced by the community, the next step would be diving into the technical details such as should an OpenWrt specific data model structure be designed or should it be based on an existing data model language e.g YANG. Looking forward to your further feedback as the topic moves forwards. Regards, Sukru From: openwrt-devel [openwrt-devel-boun...@lists.openwrt.org] on behalf of Ladislav Lhotka [lho...@nic.cz] Sent: Monday, January 9, 2017 5:14 PM To: openwrt-devel@lists.openwrt.org Subject: Re: [OpenWrt-Devel] Data_Model_Structure_Proposal_for_OpenWRT Hi, I agree with you analysis and, moreover, I believe that network management community has gone a long way to provide tools for both areas that you mention: * RESTCONF protocol: https://tools.ietf.org/html/draft-ietf-netconf-restconf * YANG data modelling language: https://tools.ietf.org/html/rfc7950 RESTCONF (that should become an RFC soon) could be the integrating layer for configuration and state data, but also for RPCs and asynchronous notifications. YANG is not exactly JSON but close, and it is IMO quite a poweful language for this domain. In the long run, it might also help in implementing standard data models in OpenWRT. These models are currently being developed not only in IETF but also in IEEE, BroadBand Forum, and elsewhere. I will be happy to help with this stuff. Cheers, Lada Forwarded Message Subject: [OpenWrt] Data_Model_Structure_Proposal_for_OpenWRT Date: Mon, 9 Jan 2017 11:22:45 + From: Sukru Senli To: open...@lists.prplfoundation.org CC: openwrt-devel@lists.openwrt.org Dear OpenWrt community, As we know OpenWrt is gaining popularity among industry players, especially in residential gateway world. Being one of these industry player who has been developing OpenWrt based software for over five years now and being a devoted user of the two core components, UBUS and UCI, as Inteno, we see two obstacles in OpenWRT on its way to be the undisputed choice for the majority of the gateway vendors: Configuration of an entity and data collection from the same entity cannot be achieved via single object: - For any on-top applications Inteno or third party developers build (WebGUI, remote applications etc.) we have to interact with both UBUS and UCI (libuci or uci object on ubus) to be able to control a single entity. This makes it more difficult for developers as they have to know not only what ubus objects but also what uci files and sections they must interact with, and interacting with two components increases the number of the code they have to write. It also makes it quite complicated in terms of access control towards an entity of the software. There are no ubus data models defined for controlling the entities: If there were data models defined for how to configure/control the different entities of the software (network, wireless. voice etc.), any application built on top of this data model would seamlessly work across different platforms and OpenWRT based systems as long as the applications controlling these entities were following the data model. Moreover, a defined data model for ubus based on a data model structure which addresses the first problem, UCI would no longer be mandatory which makes OpenWRT much easier to adapt to for many vendors out there. We believe the solution to these problems would be developing a data model structure towards OpenWRT's ubus with features such as: - JSON based, well formatted, easy to use/understand - supports auto code and document generation - contains version, properties (configuration), methods, valid data types/ranges, error codes per object - allows configuration, data collection and actions within the same object as opposed to OpenWRT today where ubus methods + UCI (using ubus uci object or libuci or /sbin/uci directly) are used. Supporting such a data model structure, the ultimate goal would be to create an OpenWrt data model to be standardized (ubus objects for controlling network, wireless, voice etc.) in order to achieve compatibility across different OpenWrt based systems. IN THE ATTACHMENT, you will find the proposal in PDF format with more technical
Re: [OpenWrt-Devel] Data_Model_Structure_Proposal_for_OpenWRT
> On 11 Jan 2017, at 14:45, Sukru Senli wrote: > > Hi Lada, > > Thank you for your feedback. > > The initial goal of this proposal is presenting the idea of adopting a data > model structure which addresses the issue 1 given in the proposal and then > defining data models based on this structure which addresses issue 2 given in > the proposal. > > The JSON example given in the proposal was just to demonstrate an example how > configuration properties and methods of an entity could be hosted in a single > structure and how that structure could be used to generate UBUS objects. > > If the idea is embraced by the community, the next step would be diving into > the technical details such as should an OpenWrt specific data model structure > be designed or should it be based on an existing data model language e.g YANG. Sure, hopefully the existence of standard tools might help in deciding. Lately, we've had internal discussions in my company whether to do something along these lines for our Turris project. Thanks, Lada > > Looking forward to your further feedback as the topic moves forwards. > > Regards, > Sukru > > > From: openwrt-devel [openwrt-devel-boun...@lists.openwrt.org] on behalf of > Ladislav Lhotka [lho...@nic.cz] > Sent: Monday, January 9, 2017 5:14 PM > To: openwrt-devel@lists.openwrt.org > Subject: Re: [OpenWrt-Devel] Data_Model_Structure_Proposal_for_OpenWRT > > Hi, > > I agree with you analysis and, moreover, I believe that network > management community has gone a long way to provide tools for both areas > that you mention: > > * RESTCONF protocol: > https://tools.ietf.org/html/draft-ietf-netconf-restconf > * YANG data modelling language: > https://tools.ietf.org/html/rfc7950 > > RESTCONF (that should become an RFC soon) could be the integrating layer > for configuration and state data, but also for RPCs and asynchronous > notifications. > > YANG is not exactly JSON but close, and it is IMO quite a poweful > language for this domain. > > In the long run, it might also help in implementing standard data models > in OpenWRT. These models are currently being developed not only in IETF > but also in IEEE, BroadBand Forum, and elsewhere. > > I will be happy to help with this stuff. > > Cheers, Lada > > Forwarded Message > Subject: [OpenWrt] Data_Model_Structure_Proposal_for_OpenWRT > Date: Mon, 9 Jan 2017 11:22:45 + > From: Sukru Senli > To: open...@lists.prplfoundation.org > CC: openwrt-devel@lists.openwrt.org > > Dear OpenWrt community, > > As we know OpenWrt is gaining popularity among industry players, > especially in residential gateway world. Being one of these industry > player who has been developing OpenWrt based software for over five > years now and being a devoted user of the two core components, UBUS and > UCI, as Inteno, we see two obstacles in OpenWRT on its way to be the > undisputed choice for the majority of the gateway vendors: > > Configuration of an entity and data collection from the same entity > cannot be achieved via single object: > - > For any on-top applications Inteno or third party developers build > (WebGUI, remote applications etc.) we have to interact with both UBUS > and UCI (libuci or uci object on ubus) to be able to control a single > entity. This makes it more difficult for developers as they have to know > not only what ubus objects but also what uci files and sections they > must interact with, and interacting with two components increases the > number of the code they have to write. It also makes it quite > complicated in terms of access control towards an entity of the software. > > There are no ubus data models defined for controlling the entities: > > If there were data models defined for how to configure/control the > different entities of the software (network, wireless. voice etc.), any > application built on top of this data model would seamlessly work across > different platforms and OpenWRT based systems as long as the > applications controlling these entities were following the data model. > Moreover, a defined data model for ubus based on a data model structure > which addresses the first problem, UCI would no longer be mandatory > which makes OpenWRT much easier to adapt to for many vendors out there. > > We believe the solution to these problems would be developing a data > model structure towards OpenWRT's ubus with features such as: > - JSON based, well formatted, easy to use/understand > - supports auto code and document generation > - contains version, properties (configuration), methods, valid data > types/ranges, error codes per object > - allows configuration, data collection and actions within the same
[OpenWrt-Devel] [RFC][netifd]: Support for 802154 devices
Hey Folks, I saw that netifd isn't able to fully manage 802154 devices. At the moment it lacks the understanding of wpan settings and definition. If it would be in a separate file it would look like: /etc/config/wpan config wpan-device radio0 option type 'mac80215' option channel '11' option disabled '0' / '1' config wpan-iface option device 'radio0' option pan_id '0xbeef' I figured two ways to implement this. The approach #1 is to follow the logic in wireless.h/c which wraps calls to the kernel driver in mac80211.sh & netifd-wireless.sh. The approach #2 is to replicate the wpan-tools code which would add a dependency to libnl. I'm wondering which approach to follow in doing this task? Regards, Anatoliy ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel