All sounds good. I am fine with 0 seeing as you detect conflicts but we have had discussions about allowing tasks to have the same priority and doing some form of time slicing/round-robin/whatever. If we did that we would need a way of saying “my task is special and you cant have a priority the same as mine”. We can punt on that for now too :-)
IRQ stuff all good. > On Sep 2, 2016, at 8:49 AM, Christopher Collins <[email protected]> wrote: > > 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.
