-
Notifications
You must be signed in to change notification settings - Fork 6.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New software configuration and provisioning mechanism #77638
Comments
An additional use case is buffer sizes for instances of CHAT (at command handling), CMUX (uart multiplexing), UARTs etc. A CMUX instance can have multiple channels, where only one needs a huge buffer (for network traffic for example) and others require small buffers for typically AT commands. |
Initial Use Cases:
Sources:
Targets:
Documentation:
|
my comment copy pasted from the Arch WG chat as requested:
and
|
For network configuration, without having run-time configuration, the whole thing can be done in Kconfig, e.g.
Where |
Arch WG:
|
Note on images build for MCUboot: Note on using external, out of image, blob: I have also a question: how to avoid using RAM for things that always be constant for a device? For example you may not change embedded MAC or serial number of device, yet when accessing these, from what has been written during provisioning, the device will have to load them to RAM, at least temporarily. This also brings cost of enabling Flash API and other subsystems required, for device to get the factory provisioned info, even if every unique instance of a device only reads the info and never attempts to store updates, or chooses other subsystem of storage (like FS). |
Thanks @carlescufi for subsuming our discussion. A few corrections to avoid misunderstandings:
Not exactly. I don't use the software/hardware distinction myself. I was rather saying that almost all properties that we introduce change at the same frequency as driver software and not at the same frequency as vendor hardware. From a well-established encapsulation perspective this indicates a requirement to keep driver-specific properties apart from vendor-specific properties and de-facto standardized stable Linux properties (as different files, not as different formats). I was citing others who had laid out alternative heuristics to define the sw/hw line:
I pointed out that as long as we do not have an intersubjectively observable heuristic that defines the line between sw and hw, each maintainer will define their own personal criteria as we observe in practice. I disagreed with @nashif that we have only few properties that are contended. I'd rather say that almost all newly introduced properties are contended as @decsny has confirmed based on practical experience over the last few months.
I mentioned that this is part of the solution space. Others have voted for protobuf or Thrift.
I responded, that we cannot cleanly define per property whether they are "provisioning only" or "build only". On a per-app basis this line will change considerably in practice. Maybe I misunderstood what was proposed, but if it means that we'd introduce another "a priory" (ontological) distinction then I'd strongly oppose such a strategy. Here a few examples others mentioned in earlier discussions:
I could immediately think of products (apps) or use cases (tests, debugging) where those properties would not fit those categories. I therefore argued that any attempt to bind properties to a specific configuration source or target is conceptually flawed and will not work in practice. The fix is: Define a common abstract data model for everything closely tied by encapsulation rules to software programming models (which includes drivers) based on well-established normalization rules (i.e. shared entities and properties) independently from any specific representation or usage context. This can be done w/o any ontological assumptions with mathematical precision and has therefore been well-established best practice in application configuration for decades. This model then needs to be serializable from/to multiple files on a per use-case and encapsulation basis and/or overlayed at any level. The settings subsystem is part of the solution space but was introduced to the discussion. That's why I voted against having to depend on the settings subsystem for all configuration as it severly limits extensibility of the config subsystem and introduces unnecessary complexity and resource usage to certain use cases like tests or simple custom applications that otherwise won't need it. I vote for technology that allows us to flexibly merge/split serialization from/to any sources/targets depending on specific application requirements. Several technologies with excellent UX exist for all proposed serialization formats to implement such a merge/split from/to a common intermediate representation. I mentioned that as a bonus, this will make it easier to switch between alternative source and target representations at dev-time (e.g. for easy reproduction of bugs and debugging with minimal dependencies).
Not only B. Mesh, my comment was including BLE proper as both seem to support the settings subsystem as config target according to @jhedberg. This becomes even more interesting when adding secure storage or large-scale provisioning systems as possible config sources. I also mentioned several other immedately relevant use cases introduced to the discussion by others and that are not yet part of the use case list.
I added to this that IMO tooling will be 90% of the maintenance effort and will be mostly shared between all use cases discussed so far (including init and net config). Assuming a common intermediate representation, sourcing from different formats and serializing into different targets can be added flexibly at very low cost. A common intermediate representation will help to debug the configuration space (similarly to .config and merged DTS) no matter whether done in YAML, JSON or DT. I therefore vote for extracting and re-using existing DT tooling (not format) and re-use it for whatever configuration system and hopefully common intermediate format we decide upon. Any addition to the DT and/or config world will then equally profit both sides, ie. we can expect that DT tooling will benefit from improvements in the config area, too (e.g. UX improvements, validations, bindings, documentation, etc.). This also has obvious advantages from the user perspective as a lot of target-side and tooling knowledge could be re-used, independently of context. UPDATE: To clarify as I was probably misunderstood here - I didn't argue for any specific tooling solution here although I admit that I can be read that way. I was just arguing to share tooling among different configuration requirements which is in the problem space, not in the implementation space as I'm not saying anything specific about how such shared tooling should look in the end. OTOH let's be realistic: Any shared tooling will need to build on top of what we have but I admit that such a statement is in the solution space and not required right now. So sorry if I was misread in that sense. As long as those use cases and basic requirements (including those mentioned in my first comment) are not explicitly made part of the RFC I'll find it very hard to agree to any configuration system. They are all immediately relevant to the initial use cases mentioned by the OP and are therefore part of a "minimal set" as required by this issue. And please note that none of those requirements favors DT over YAML (or whatever other solution space technology) in any way. UPDATE: Edited to ensure feedback given further down has been included in the argument. |
you need to provide some context and details here, I have no idea what @decsny said and where he said it and in what context. |
why would you use a tooling for a format if you are not using the format itself? Also, we established that runtime is important, most of the DT tooling is build time and based on macros. |
@nordicjm @de-nordic I think your comments are really relevant but they both rather belong to rather specific solution spaces unless we extract abstract requirements from those examples. I find it hard myself to cleanly distinguish between problem and solution w/o loosing sight of feasibility. But it would be nice if we tried to keep very specific implementation problems always linked to more abstract requirements as I understood @carlescufi 's approach. @nordicjm In more abstract terms you're making the case - if I understand correctly - that almost any source format will be able to represent an abstract data model (including Kconfig) and that we should not introduce additional formats unless required for a good reason (i.e. simplicity and UX as a requirement). @de-nordic If I understand you correctly you're requiring at a more abstract level that configuration needs not only to integrate with the settings subsystem alone but also with other subsystems (e.g. MCUBoot signing in your case). From a requirements perspective this confirms that we cannot tie the configuration subsystem target to a single subsystem alone. It must be sufficiently open to integrate with whatever target and process we already have or invent in the future. |
Sure: #76902 (comment) |
No, I'm stating that without runtime configurability (i.e. provisioning and able to change it) the entire network configuration PR is moot because no tooling is required, static configuration can be wholly done in Kconfig, thus the prime feature that this must support is provisioning |
Not introducing new dependencies or minimizing dependencies should be a requirement. IIRC it was mentioned somewhere, but I cannot find it here. (Side note, we already use CBOR implementation and IMO it fits better to use it as a DTB alternative). |
Considerable parts of DT tooling are not specific to DT as a source format (which as such I'm not questioning). Re-using those parts not only means less maintenance cost but also considerable re-use of existing community knowledge. Just a few examples off of the top of my head w/o trying to be complete:
I'm sure I could find more examples if looking at the code. But I think this is enough to make the point. |
This is very vague and a general obvervation which might be valid and to the point but this needs to be supported with examples that show whether this is going from bad to worse or something manageable that can be tolerated depending on the use case and context. If someone thinks this is a serious problem that needs attendion, someone needs to open an issue with examples and bring this to the attention of everyone. |
I think florian is referring to my engagement of him on #76902, he mentioned that I was taking a definition for a software and hardware distinction as for granted, I just responded to him that since I have been on the DT reviewer list for a while, I actually did see that it was quite a gray area and everybody seems to have different opinions. As far as the point that florian is trying to make, I have not created a compiled list of detailed examples to support his argument, which IMO sounds a bit zealous but I think his spirit is going in the right place regardless, it's an important issue (as everybody interested in this thread would agree I think). And to be clear, I would not say that almost all newly introduced properties are contended, that is a bit of an exaggeration, but there are multiple cases:
|
just a nother note here, can we please STOP talking about implementation and formats and DTS please? thought we had a good discussion yesterday while remaining at a high level and now we are going down the path again talking tooling and formats, this is very disruptive. |
you should quote reply whoever you're talking to with what specifically you think is not relevant. |
too much to quote reply. hint: I am not referring to you, just seen your message :) |
I do think it's not productive to make vague statements about people's discussion being irrelevant, it doesn't help not to be specific, you want to avoid discouraging the participation you actually do want by being too broad with your meta-criticism of the discussion |
where am I being vague?
I am saying we need to first collect requirements before we go into implementation details and the discussion is shifting toward what was already discussed in the issues that were abrubtly closed. Why at this stage people are "voting" for implementations and formats and tooling without first agreeing on the requirements? Why is this discussion shifting toward how DTS is being used or mis-used? |
I'm not disagreeing with you that we need to talk about the requirements before proposing myriads of solutions, but a lot of these requirements are going to come from observations of weaknesses about the current implementation we have, so saying not to talk about it at all is too vague. Clearly there is some direction of the discussion above that you didn't like and I think it would be more useful to be more specific about what direction it went that you didn't like and by who. On the other hand, if by your quoted request you really flatly think that any mention of DT or implementation (especially the current) is irrelevant, then I tend to disagree for the reason I just gave. |
and how does a "vote"" for an implementation in a discussion about requirements and as you say, weaknesses in such implementations help here? We will get there, sooner or later, but when this forum goes into the same rabbit hole about the same topic and the same arguments, most of us will just give up and lose interest. Some DTS topics being touched on here deservee their own issues and tracks. |
Yes, I admit this was an exaggeration. Sorry for that. :-( It's enough that there are many instances to make my argument.
IMO a sufficiently large part of changes are made due to driver-specific features for existing hardware to support the argument that those properties should be packaged with drivers rather than hardware. This is established encapsulation practice, why deviate? Does not invalidate your argument, though. I acknowlege that we try hard to make our configuration models independent of specific vendors and Zephyr driver programming models. But for custom out-of-tree drivers or custom hardware this model often won't match project requirements.
I said the same thing above - so why re-iterate? There was nothing deviating being brought to the discussion in the meantime except for your own questions re DT and tooling, right? I therefore have to say that it's at least partly your fault if the discussion has been digressing again from the problem space. You just got what you asked for, IMO. Arguing about the software/hardware distinction is in the problem space, focussing on DT as a format is not. Also feasibility cannot be completely excluded from our discussion.
I don't agree. Yesterday's discussion brought no new arguments, only repetitions of what had been said earlier (except for the truly original proposal to forget about config altogether and do everything in Kconfig). It's a pity that so many contributions were ignored by most participants. We need to do our homework before we attend arch WG meetings. There are many who have participated in the meta-discussion but have not provided much own substantial contributions or comments on arguments that are already on the table.
IMO this amounts to weaseling. Everybody might implicitly feel indirectly accused unless you make this specific.
I personally find this comment a bit unfair. Many others (including myself) have made this point over and over including specific examples. @decsny's comment was embedded in an RFC that pointed to specific examples and only confirmed the observations made there. And his new comment is equally balanced and well argued. But here some specific examples then as you asked for those:
There are at least two PRs and one RFC where this argument has been brought forward in the context of this topic alone not counting all the unrelated PRs where the hardware/software line has been questioned by commenters in other contexts. @nashif It would also be nice to get your personal requirements list or at least some confirmation of existing requirements that others have mentioned. This would add tangible content to the discussions rather than just focussing on the meta-discussion alone (which I otherwise find worthwile, too btw, but not exclusively so). Edit: Updated to the latest state of the discussion include arguments given by others. |
I think we are having a misunderstanding here, I am not saying that I think we should be voting on implementations or even proposing them, what I'm saying is that observation of the current implementation is going to be an important source of deriving requirements since most of the motivation for talking about this issue seems like it stems from the limitations people are discovering with the current state of things. That's why I asked you to clarify what you were talking about, since your meta-criticism sounded to broad to me since I personally think discussion of the current implementation is relevant to requirement gathering, but your brief request to filter discussion if taken completely as worded would exclude discussion of that. As for what anybody else in this thread is talking about, I'm not defending the direction anybody is taking, I honestly only skimmed what's going on because I got pinged like 5 times, and it sounded like I needed to clarify my quotation. edit: late proofread reword |
@decsny do you really feel targetted here? I emphasized that all of this might be true and valid, but we need specific examples and we need to discuss this on a different track if it is really that bad.
right, and I will not provide examples because I am not making any claims or arguments, you are the one making them. |
Before most of us give up they'll have to make their first substantial contribution or at least refer explicitly to what others have brought to the table. ;-) We have a lack of people listening to each others' argument and a lack of original content. If you think others are contributing the wrong things to the discussion why don't you simply say the right things rather than making such a fuss here. |
no, i don't feel targeted, from the comment he's referring to that was before I even came to this thread, and you're not wrong that specific examples are needed. Which is why in my original response to all the pings I specifically clarified in response to the claim that I knew about all this that I do not have a compiled list of examples, that would take time and effort which I have not had the luxury to spend. And I want to be clear also based on some comments in this thread that I personally don't desire to be the vehicle for an appeal to authority about what's being discussed here and don't completely see what value it adds anyways, since another point of what I was trying to say above is that those experiences I've seen a lot from being a reviewer, I would expect should also to have probably been commonly seen also by everybody else interested in this issue. |
Now that we all seem to converge on a common problem statement (pending a few more examples I trust will be easy to find) we can hopefully see what the essence of this back and forth would be wrt the concern of this issue. Requirements:
What I mean by precise has been explained in this comment, see the definition of "axiomatic" vs. "ontological": Our configuration space must be accompanied by easy-to-observe (axiomatic) heuristics that refer to intrinsic properties of our software rather than relying on extrinsic "real world" concepts that cannot be mapped to code artifacts without contextual interpretations that we will by definition (and backed by a lot of research) never be able to agree upon objectively. I've shown that the distinctions and concepts I'm proposing (feature selection vs. configuration, normalization, encapsulation) can be mostly automated or at the very least be defined with mathematical precision. The same can not be said about distinctions like hw vs sw or provisioning vs build time properties. At least not until someone has come up with a heuristic that really represents what we actually do. Note that I've shown that heuristics that have been proposed so far are quite obviously not good enough. I'm of course open to being proved wrong or convinced otherwise. But certainly not by "hand wavy" concepts that no one has been able to define precisely so far. |
Chris and I spoke up yesterday to explain this requirement once again. I've not heard myself withdrawing it, so it remains on the list, like yours and those of everyone else. We can prioritize it down into the future, but I don't see the slightest reason why we should eliminate requirements just because you feel like it.
I think I was rather clear about that. I'll certainly remind you if it happens again. |
@nashif I've got the feeling this could be a new requirement, or even two. Could they be described like this?
|
Chris or anyone else with input and requirements should add them directly and should not need a proxy or a mediator. I am not, and have not requested "elimination" of anything. It is fully OKAY to question requirements and their significance to the ongoing discussion of the high level requirements and determinging where we are going with this shall not be derailed because something can be done or is feasible or sounds interesting.
If you think I have been disrespectful, abused some power/authority or anything else, file a complaint please. You seem to be accusing me of something and if I am at fault, it needs to be dealt with immediately. I do not want to wait until "next time". |
right, but those are already fullfilled requirements, so are we trying to change how we do configuration in general, for everything? |
The general area of discussion here is configuration, which of course also includes the already existing methods for configuration. I am at this point not saying we should change something, I am only collecting all the requirements we have for this area. What we then keep as it is or change will depend on how we prioritize possibly conflicting requirements. And we will of course also have to weigh in the necessary implementation effort and the possible benefits. |
Please calm down now - I'm not trying to prove you wrong, I'm just preserving my own interest. The complaint is dealt with at the appropriate level - immediately and openly where it originated rather than behind your back.
Please note, that I'm behind this requirement, too. |
no, I am not calming down. I take this very seriously. You are making very serious accusations here and that can't be let go like this. You can go behind my back, you have my blessing.
Ok. To quote you verbatim in the meeting yesterday:
|
@fgrandel as the chair of the Architecture WG, I must emphasize that my goal is to make all voices heard. This is not always easy, and even less so in the context of a cross-continent, cross-company audio conversation over the internet. Requesting your turn to speak is generally mandatory in these meetings, and for the most part always respected. I am always trying to improve the flow of the meeting, so all suggestions welcome, but in no case have I given priority to specific participants because of reasons that could be considered non-technical, including, as you put it, "authority". Some people extend themselves more, and are more proactive to request their speaking turn multiple times during the call, but the Architecture WG call is open to all and considers all contributions under the exact same light and importance. |
Yes, I remember. I've changed my mind, and you know why. |
Yes I know, and I really appreciate it. You're not at all the target of my critique. It's the people talking down others aggressively and those giving heart emojis to each and every statement that serves their personal interest, no matter whether it has merit for the question at hand or not. |
I take my own decisions as I see fit. In the meantime I perceive your statement as an open menace. Not the kind of behavior that convinces me that you're willing to talk to me at eye's height. Meta: I prefer to confront the people concerned in the open rather than escalating this anywhere. Like that everyone else is free to observe what is happening and build their own opinion. I think our respective behaviors speak for themselves. Ever heard of the likability vs. respect/competence dilemma? - I currently very much feel caught in it. That being said, I'm certainly not free of weak points, so please, feel free to point them out with respect. Maybe you can come out of the defense and tell me what you think are good team working behaviors? The behaviors you currently show are not among those on my personal list. Remember that point on the rule list that you like to cite? Accept critique gracefully... In any case I think this meta-topic has rightfully accompanied our discussion and I hope we can address it more seriously in the future in the same way we usually address technical problems. This is not only about you @nashif , several others have shown similar behaviors. I've been equally outspoken about those. In that sense I've consistently stated a few rules that I think will help us to work more constructively as a team:
These are not meant to replace the rules that you and others like to cite so frequently. They are meant to make them work in practice. By these rules @benediktibk and I have assembled a full list of requirements in a few hours that beats everything else that has been contributed so far in this discussion. Your diagram was a great contribution, too, but the way you dealt with how I tried to build upon it constructively (!) to achieve a similar team result illustrates the differences in behaviors and outcome quite well. |
For the static case this works nicely. :-) Now a few more detailed design questions:
Am I assuming correctly that the settings frontend won't care where the data comes from, so basically the backend would check whether there is an image with updated data and uses that to instantiate the configuration dynamically? If the backend finds one, it distributes that data, otherwise it falls back to the statically configured default...
a) For the case that we don't need to write back to the store we could have multiple sources, each encapsulating the knowledge of one subsystem. No problem. b) For the case that we need to write back: As far as I understand we currently can only have a single destination (i.e. writable) backend. Am I assuming correctly that in this case we'd either have to extend the settings subsystem to support multiple destinations or we'd have to implement something like a "delegating backend", i.e. interested subsystems would have to register themselves with the backend so that it can save data on their behalf w/o the backend having to "know" about all the subsystem details. Is my understanding correct? Have I overlooked something? Any more ideas how to design this elegantly in practice? Advantages of this approach I discovered while thinking about it:
So overall I'm quite convinced that this is the right way to go to cover all requirements we currently know of. @nashif If this is what you mean by a "configuration subsystem abstraction layer", then we're on the same page. |
Yes, the data could even come from an "online" source. As soon as the subsystem struct or part of it would need to be changeable, a memcpy to a non const struct could be used.
There are several ways to tackle this: the dst (destination) backend is used by the settings system when a
IMHO the settings system might require some changes to simplify the switching between backends (registering and unregistering srcs and dst), reworking some of the naming (e.g. The method of how the Another advantage is that direct support of multiple static configurations can be done. There are just multiple "const structs" defined and switching between them is just a change of a pointer. |
Thanks @Laczen, all your suggestions make sense to me. Very helpful. Just one question to confirm my understanding:
When you say "based on yaml", you mean something similar to what Jukka did? I.e. a python script that takes in a YAML configuration file and generates C code files or snippets? |
Yes. As a personal note I really like the "configuration" method used in esphome, where it is even possible to add code to the yaml files. Leaving devicetree for the hardware setup and just enable parts in the overlay (or have them enabled based upon an entry in the yaml). Move all non-hardware setups (also e.g. partitions as well as buffers, ...) out of dts and governed by a subsystem that is configured by yaml files. For easy configuration of subsystems (that as standard should be multi-instance) they could all provide a macro to create a subsystem item (passing any configuration option trough the macro) so that the translation from yaml to config is just filling up a(multiple) macro call(s). Access to hardware should be done through a subsystem that can also be used as the layer to provide buffers,... As a downside this would probably make much of the tooling that has been added on top of dts obsolete, it might not result in the smallest image and I am certain this is not inline with the idea's of some maintainers and developers. But then again, this is a personal note, all of the formulated ideas can be selected or rejected and I am sure there will be areas where they do not apply. |
Thanks for those considerations and proposals! IMO there cannot be enough ideas on the table (personal or not). I mean, you clearly do not express them at the expense of other people's ideas and arguments. We are deep into solution space here, but it helps me to think more clearly about higher level ideas, when I have a few potential implementation options in mind.
That's the one sentence I didn't understand. All the rest seems clear to me.
Can you point me to a docs page where this is explained? |
I am in the same position, small solutions proposals help me figure out the global approach
Let's take the example of a uart. This is clearly a device. To use it with a circular buffer to store data this circular buffer can be added to the driver (needing configuration in dts/Kconfig) or it could be added to a layer above the driver (e.g. a serial subsystem), with configuration in the new config system. Now for a uart this might be overkill, but it is only the idea that I'm trying to explain.
|
I Like this example, I personally use esphome and get what you are saying here and that is basically the direction i was thinking as well.
This is what I refer to above in a previous comment: "Each subsystem or software component, where applicable, should be configurable both using Kconfig for static and initial so we are on the same page, i.e. to configure some LED, you need a LED service that supports configuration, to toggle some GPIOs you will need a GPIO service etc... |
@nashif Do I understand you correctly that you're speaking about application facing services here? Something like the existing net mgmt service - just more generic so that it can be used to configure any subsystem? If that assumption is correct: Would you also migrate, say, net mgmt, to this same approach? |
more like net_config |
I wanted to refer to this statement, but could quickly find it :). |
I've moved the requirements to a separate document that I link from the PR description |
Comments on list of requirements:
Not really many of the requirements even talk about the topic of discussions, there's not enough relevant requirements to draw any conclusion from |
No problem. Feel free to add the really relevant ones yourself. That's why we have that list. :-) Dropping requirements later or prioritizing them down is easy. Overlooking a relevant one would be bad, though. |
I agree with @nordicjm, we should clarify this requirement. My intention while writing was that configuration data, which is loaded during runtime for instance from an SD card, should be verified. This is important in combination with the requirements for the signed images.
I would not consider this as a duplicate. Fulfilling CR3 will probably help UR12, but one can still think of an unnecessary complex configuration system which is hard to understand, although it has automatically generated documentation. For the comments from @nordicjm on CR4 and CR5 I kind of agree, it would really help if we could maybe split them up into a few smaller ones? @fgrandel Overall I understand the comments from @nordicjm that he prefers not to change anything devicetree related at all. This is definitely a valid requirement, which I have tried to reflect with UR5. But this might contradict other requirements, like for instance CR1 and CR2. Therefore, I ask you to keep your mind open at this stage. And of course feel free to refine the requirements or add new ones, if you think some are missing. |
Architecture WG meeting
|
Introduction
This issue deals with a topic that has been the center of multiple previous discussions and existing issues and PRs. This is an attempt at briefly summarizing the problem in order to solve it in a way that is agreeable to all potential users and developers alike.
IMPORTANT: Please keep the discussion around this particular feature in this GitHub issue, so that we do not have to collect feedback from multiple sources.
Problem description
Zephyr currently lacks a mechanism to configure multi-instance software components at compile-time well above the hardware. Instead, as described multiple times, we have:
A third mechanism is therefore required. This issue describes the use cases and requirements in order to end up concluding with a final proposal.
Zephyr also lacks a provisioning mechanism, which would be able to generate a pre-compiled "image" of the data that is required in order to provide the required data for certain subsystems to execute.
Use cases
The following use cases have so far been identified:
We foresee additional users of this mechanism in the future, but the two use cases above exist today and require a solution.
Requirements (WIP)
Requirements document
Proposed diagrams
@nashif:
@fgrandel:
The text was updated successfully, but these errors were encountered: