Raspberry Pi 3B+
Timothy Baldwin (184) 242 posts |
Bq. Is it considered a microkernel or a monolithic? Such terms cannot be easly applied to RISC OS as there is no user/kernel security boundary in RISC OS. By standard terminology all the modules are part of the kernel, and arguably all the applications as well. This, combined the filesystems and device drivers run in the same thread as the caller, means RISC OS is a modular monolithic kernel design. The RISC OS Kernel source is in apache/RiscOS/Sources/kernel and includes some graphics rendering, the command line interpreter and memory management. It does not include task switching and scheduling (which is considered a kernel task in microkernels) nor filesystems. |
Rick Murray (539) 13862 posts |
Applications normally run with a lower level of privilege than kernel/modules; although this may not mean much when just about anybody can scribble into OS workspace and if not, the OS is quite happy to bump any old user mode code up to supervisor level with One Simple Trick… As for the kernel type, I’d say monolithic is the closest match, but as you’ll see, it’s a kind of an interesting hybrid that doesn’t neatly fit into a specific category.
RISC OS is a single user single process system (you’ll easily spot the single global graphics context…) with a multitasking desktop environment bolted on. The entire desktop world is magical smoke and mirrors to convince an application that it is the only application running, mapped at address &8000, and to manage to do this for dozens of applications. It’s quite clever how it was made to work, but as has been said above, the kernel only knows of a single process. The task switching magic happens elsewhere. |
Jared Falvo (6086) 35 posts |
One image I saw represented the kernel as a large center circle, with the modules as smaller circles surrounding it, connected by lines (spokes?). Thus, if that representation were accurate, what does JUST that central kernel actually do, assuming no other modules were connected/activated/enabled? |
Jeffrey Lee (213) 6048 posts |
The RISC OS 5 kernel has the following responsibilities:
In my opinion the first four and a half are what the kernel should be doing, while the rest is starting to stray into monolithic kernel bloat territory. If you were to boot a ROM containing just the HAL + kernel, it would in theory drop you at a terminal prompt (assuming you have some way of seeing it – e..g. video driver in the HAL, or a build with the serial debug enabled). But since the kernel is reliant on external modules for a lot of things, it’s hard to say how much will work. |
Jared Falvo (6086) 35 posts |
I looked at the FreeBSD Raspberry Pi port and it appears to be both 64-bit as well as SMP. If making the RISC OS kernel the same (64-bit/SMP) is such an arduous/impossible/expensive task, why not just use the FreeBSD one and modify it to function with the rest of RISC OS? Or are the two kernels so radically different, you might as well ask a monkey to install a 747 jet engine into a VW bug? :-D |
Steve Pampling (1551) 8182 posts |
Among other things. Have a look at the source code. When you get over the mixture of C, assembler and other and realise that the order that I gave isn’t representing the relative quantities you might see the nature of one aspect of the task you describe. Then start digging in to how things inter-relate you will see what Jeffrey was talking about. Most of all – RISC OS is not a flavour of Linux. It isn’t even a distant relative. |
Jared Falvo (6086) 35 posts |
But, would it be possible to take what is known (the 64-bit/SMP aspects of FreeBSD) and convert them to the code format (Assembly language) of RISC OS, replacing the non-64-bit/SMP part(s) of the kernel? License-wise, it shouldn’t be an issue, but does anybody know how to “translate” from one into the other? I’m only thinking of how to simplify the “upgrade process” by taking what others have already done and simply adapt it to RISC OS. I did not intent to sound like I was wanting RISC OS to be “mangled” such as I might have made it sound. :-( |
Rick Murray (539) 13862 posts |
No, not really. Converting the older 26 bit code to 32 bit was a pain but it was possible because the two were essentially similar. Instead of PC+PSR, they were separate so code needed to be modified not to touch PC (in other words, don’t push bit 28 to set V flag, etc). ARM 32 to ARM 64 is nothing like that. The two are quite different, and I liken doing a conversion to porting RISC OS to MIPS, not out of hyperbole but in order to demonstrate exactly how different the two are. With our limited developer resources, the best way to run RISC OS on 64 bit is probably going to be emulation. Anything else is……. |
Jared Falvo (6086) 35 posts |
Rick – Limited Developer Resources (LDR)… is that in actual manpower (people who know how to do it or number of said individuals) or financial? If we have the people but not the finances, that’s a problem. But if you simply don’t HAVE the people, that’s a worse problem. |
Chris Mahoney (1684) 2165 posts |
At the recent show, Andrew from ROD was saying something to the effect of “we have funding to build a new browser but we can’t find anyone to do the work”. I’d imagine that finding kernel developers would also be tricky, if not more so. |
Chris Evans (457) 1614 posts |
AIUI There are people who have RISC OS experience and the necessary skills to do big project development of the OS and apps but finding someone who ‘currently’ has the time is a problem. Someone who hasn’t RISC OS experience but does have the necessary skills could be found but finding them is no easy quick task and they would cost more due the extra time required to learn how RISC OS works. n.b. One active RISC OS developer told me a while back that he was keeping an eye on a particular bounty and when the amount got to a particular figure he would claim it, if other work permitted. |
mikko (3145) 124 posts |
Hi Chris, Which bounty was that and what was the figure? Knowing the first fact at least might give that bounty a boost – especially during this period where ROOL are matching any contributions made. .. |
Andrew Rawnsley (492) 1445 posts |
Echo-ing what mikko just posted, if people are thinking about a bounty, they should drop us a line at RISC OS Developments. We have plans for development of the OS, and want to work with people to further it. Availability of willing/able programmers is our number one problem, so if anyone would like to do application or lower level development work, please talk to us. |
Chris Evans (457) 1614 posts |
“Hi Chris, Which bounty was that and what was the figure?” If someone who ROOL/ROD took seriously made such an offer then they could publicise it and as you say I’m sure it would get a boost. IIRC it was a bounty that has since been claimed, I don’t know if it was by the developer I was talking to over a year ago. |
Jared Falvo (6086) 35 posts |
A little over 1 yr. later… If someone were to be crazy enough to even attempt what I have mentioned, where would you start, in the source code tree? I’ve downloaded the Source Code tree for Raspberry Pi. And I definitely want to get as “fast and tight” as possible, so I’d like to keep everything written in Assembly Language, if possible. So (I assume) I’d start in the path: BCM2835 > RiscOS > Sources > Kernel > s If you wanted to start at the lowest level. The very beginning of the boot sequence and the most basic aspects of the kernel itself… is that where you would start? Does that specific directory have the files necessary for that? |
Richard Walker (2090) 432 posts |
Does any of this help? https://www.riscosopen.org/wiki/documentation/show/Developer%20documentation |
Jeffrey Lee (213) 6048 posts |
Yes, that’s the right place for the kernel sources. Kernel startup starts with the RISCOS_Start routine in s.HAL. However note that RISCOS_Start is called from the HAL (RiscOS.Sources.HAL.BCM2835, execution starts in s.Top). So if you’re going for 64bit support you’ll also need to modify/replace the HAL. The way I’d start with this is to strip the kernel down to the bare minimum (i.e. the first four/five things from my earlier post), moving all of the other functionality into one or more modules. Then you can replace the stripped-down kernel with a 64bit, SMP-capable version with minimal effort. Then once that’s working correctly (with the rest of the OS running in 32bit mode on a single core) you can start updating the rest of the OS, one module at a time. |
Michael Grunditz (467) 531 posts |
Wow.. I need to ask which compiler that could work with 64bit.. I mean when binary is supposed to cooperate with the rest of riscos? Wow.. I need to ask which compiler that could work with 64bit.. I mean when binary is supposed to cooperate with the rest of riscos?But I guess you can have a -BIN binary that loads rest of OS after switching to 32bit. There are problems , like how to deal with SWI’s. |