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.
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. > On Aug 29, 2016, at 7:29 PM, Christopher Collins <[email protected]> wrote: > > On Tue, Aug 30, 2016 at 12:35:31AM +0000, [email protected] wrote: >> Would you expect that everyone that writes a new core package, would add >> their init code to sys/sysinit package and include their package in the >> dependencies for sys/sysinit? Would that mean that if I include >> sys/sysinit as a dependency in my app (every app probably would), it >> automatically becomes dependent on all packages, or would this be special >> somehow and not be necessary. > > I think the sysinit package should have access to all packages in the > build. Newt would have to do some magic to arrange for this (perhaps a > setting in the pkg.yml file). The sysinit package wouldn't explicitly > depend on these packages, it would just use whatever is already getting > pulled in. > >> Does it make sense to have the sysinit.yml file include the "init method >> name² for the package and have newt build that sysintit.c file special for >> your target? This has the advantage that we are not coupling these >> projects together or using tons of ifdefs which make the code hard to read >> (its hard to teach my idea about defines that newt creates). It raises the >> issue of order though since we can¹t enforce an order if its generated >> like this. We would also have to make these a fixed prototype to make it >> easy (I think it would be easy to make the int foo(void)). > > That is not a bad idea at all. It does bother me that sysinit needs > code to initialize every core package, and this seems like a good > solution to that problem. > > You are right about the ordering issue. One option is for each system > package cto have a numeric "stage" setting. The sysinit code would > initialize every package in stage 1, before those in stage 2, and so on. > Within a stage, packages would be initialized in alphabetical order (or > whatever). > >> Would non-core packages put their init code in sys/sysinit? Or is this >> just for os-core stuff? > > I think if non-core packages can leverage the sysinit feature, then they > should. I was thinking it would just be core packages because sysinit > would need special code for each package. However, you init function > idea might be a way to solve this issue and allow other packages to use > it. > >> My preference is to put some thought into the yml file format for future. >> We¹ve got tons of packages and its may be a pain to make a drastic change >> later. We don¹t need to add the features now, just make sure the yml file >> has the hierarchy to support the things we are thinking about now. > > Thanks, > Chris
