On 23/1/19 5:50 pm, Sebastian Huber wrote: > On 22/01/2019 23:42, Chris Johns wrote: >> On 23/1/19 5:34 am, Joel Sherrill wrote: >>> I don't object. >> Is executive the right abstraction? Both terms are an abstraction because we >> have a single address space and literal or formal interpretation breaks >> down. I >> see the physical separation as an implementation detail. > > Real-Time Executive for Multiprocessor Systems or RTEMS already has executive > in > its name.
The name has evolved over time. > I don't think that the kernel/user space separation and system calls > are an implementation detail. It is a hardware enforced feature which > characterizes a whole group of operating systems. The name kernel is quite > overloaded. It sure is. > I would like to avoid that someone thinks about RTEMS as a micro > kernel which would be totally wrong. I think there will always be a level of confusion. >> Which term is the better abstraction of what the rtems.git repo is? This is >> the >> critical piece to resolve. > > Ok, this is a different issue. The problem is that in rtems.git is a > collection > of different things. It contains the RTEMS executive (everything which deals > with threads, interrupts, synchronization and inter-thread communication), a > legacy network stack, file systems, device drivers, memory allocators, > compression libraries, hash libraries, shell, etc. I think calling this stuff > "kernel" is imprecise. It is imprecise but what is a precise single word or term to explain this? >> >> I have been using kernel as the reference to the 'rtems.git' repo. Using >> 'rtems' >> as a name to refer to the 'rtems.git' repo is not enough as the term 'rtems' >> has >> a much broader scope these days and it's meaning is ambiguous to new users. >> RTEMS OS is also too board and ambiguous. I selected the term 'kernel' >> because >> it represents a formal set of interfaces that RTEMS provides without being >> specific about a piece of provided functionality. It also follows the RSB >> build >> set name I created years ago. The single term is strategic, it is attempting >> to >> use a language that maps to the steps you need to take and repos you need to >> access. The Executable section of the User Manual outlines the stages: >> >> https://docs.rtems.org/branches/master/user/exe/index.html >> >> A key focus of this section is to show the steps a user needs to take to >> build >> an application. They are building the tools, building the "kernel", >> optionally >> building 3rd party packages and then building an application. I include >> libbsd >> as a 3rd party package to be consistent and to show to users the RTEMS >> operating >> system can also contain 3rd party packages and those packages can serve as >> examples for others. >> >> We sit in a middle state at the moment, we have things in the rtems.git repo >> that could be separate packages, the legacy networking stack, parts of >> libmisc, >> or we have packages like libbsd that could be part of rtems.git. I suspect in >> time removing packages from the rtems.git repo will aid certification because >> there is less code to audit or review and remove. This however means we need >> a >> strong package builder or these packages as well as external 3rd party >> packages. >> Hmm, maybe the term 3rd party packages is wrong and should be changed, but >> that >> is off scope for this thread. >> >> Joel and I have been reviewing the Eco-system and Executable section of the >> user >> manual using both terms and in a few spots "RTEMS operating system" should be >> used instead of 'kernel' so that language could be improved. In the >> Executable >> section the use of 'executive' seems to close to 'executable'. >> >> Note, the "Kernel" layer in the "Vertical Software Stack" figure should be >> expanded to be two layers, "Services" and "Executive". >> >> An important factor is the documentation needs to read well. >> >> For me the executive is the runtime thread management and control, I suppose >> the >> score set of files, and I think it would be awkward to group the shell as >> part >> of the executive. Referring to 'rtems.git' as the 'executive' repo somehow >> does >> not feel right. >> >> I am not sure there is a clear answer that perfectly defines what we have. >> There >> seems to be a lot of work to make this change including the RSB and I am >> wondering if it is worth the churn. > > I think it is worth the churn. If you don't name the important components > consistently in the documentation it is just confusing. Sorry, of course the work is worth it if we have a term to use. I was meaning for me kernel is only marginally better than executive so that change is not worth it. I think it is important to keep executive for the list you have provided below. >>> However, if you go back in time to the early RTEMS days, executive and >>> kernel >>> were used interchangeably. Both were less full-featured than what was >>> called an >>> OS back in those days. Now that RTEMS has file systems, networking, etc, it >>> is >>> proper under those old conventions to use OS for RTEMS now but the >>> concurrency >>> and synchronization minimal subset is an executive/kernel. >> Yes I agree we have used these terms equally over the years... >> >> https://docs.rtems.org/releases/4.5.0/rtemsdoc-4.5.0/share/rtemsdoc/html/FAQ/FAQ00006.html >> >> >> :) >> >>> But executive is better than kernel now as a term. Executives focus on >>> services >>> related to managing a thread set. >> How do we address the rtems.git repo? For example ... >> >> "Please refer to the code in the kernel repo" >> >> "Please refer to the code in the executive repo" >> >> "Please refer to the code in the OS repo" >> >> For me the executive sentence seems specialised while the kernel seem boarder >> but that could just be my ingrained view. > > What about "Please refer to the code in the RTEMS main repo"? Words like main are not great, it is like new or old. > I would definitely not call it "kernel repo" or "executive repo". Sure but it leaves a hole we need to fill. > The "OS repo" is also good. What about "RTOS", eg RTOS repo? This leave 'OS' as the collective term of the pieces we have and I think that is a good thing to have. > I think we should rename rtems-kernel-*.cfg to rtems-os-*.cfg in the RSB. rtems-rtos-*.cfg ? >> If we use executive is 'exec' as a shorted path ok? For example: >> >> /opt/work/chris/rtems/exec/rtems.git >> >> If 'executive' is used we are again extending path names and we there can be >> issues even on Linux, ie Ada builds and Windows. > > The directory structure proposed in the documents is another topic. I would > organize it like this: > > sandbox/5/ <- prefix > sandbox/src/examples > sandbox/src/libbsd > sandbox/src/rsb > sandbox/src/rtems sandbox/src/rtos > I am not absolutely sure if the Ada build is affected by long path names, but > it > had an influence on error messages produced by a failing build. OK. It is an issue on Windows. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
