Hi Will, Oops, somehow I missed this response. Your feedback is greatly appreciated. I have some comments below.
Thanks, Chris On Tue, Aug 30, 2016 at 09:23:45AM -0700, will sanfilippo wrote: > Just a few comments. Overall I think it looks great. > > 1) Task priorities > I like the concept of “any” and I also wonder if there should be the > concept of “highest”. The user should have the ability to see all the > tasks and the priorities they have been assigned and they should be > able to override them (it seems from your mail that all this would be > the case). If two packages are included that have priority “highest”, > that is a conflict that the developer should have to resolve. I dont > know if there is also a need to reserve some priority numbers for the > OS itself but I would say not to start. (I realize you wrote this email before I sent my most recent proposal, so my comments should be read in that context. I apologize for any confusion I cause here. By the way, after some thought, I don't think the task priority system I described in my last email is very good. Rather than using special "PRIORITY_" values to distinguish these settings from others, the setting definition should indicate that it is a task priority setting. The setting values would then just be plain numbers or "any". This would leave more room for additional "special" settings, rather than assuming that task priorities are the only ones.) Would the "highest" value be different from a value of 0? The task priority system that I described in my most recent email detects duplicate values among all priorities. I can think of at least one real benefit for a "highest" value: it eliminates the uncertainty of whether priorities start at 0 or 1. I am not sure this is a good enough justification for another special value, though! > 2) Interrupt priorities > This is always a fun thing and I think sort of belongs in the init > discussion. I think they are like task priorities in a way and I think > it is difficult to assign deault priorities to them. Well, that is not > entirely true. We could have something like highest, lowest, etc and > the tool, knowing the architecture and the possible priorities, > assigns them. And just like tasks, the users can override them. I completely agree - syscfg should specify interrupt priorities. I think the mechanism here could be mostly identical to how task priorities are specified, with one exception: no prohibition against using the same priority twice. The system would allow multiple interrupts to be configured with the same priority.
