@kolla

Quote:

kolla wrote: @matthey Quote: big improvement over Linux with a monolithic kernel It’s still a monolithic kernel - real-time doesn’t imply microkernel. Also, the mentioned real-time paches are at last being merged into main these days Secondly - have SpaceX equipment been so high up that radiation hardened processors have been needed yet? Certainly most of their activities have been in rather low orbits, within protecting of earth’s magnetic fields etc.

The water can protect against radiation and provide cooling.

Immersion cooling is putting the electronic components directly inside a bath of coolant so the coolant needs to be nonconductive. Mineral oil and 3M Engineered Fluids (Novec, Fluorinert, etc) are examples of coolants which could be used.

Refer to 2017 https://www.imeche.org/news/news-article/hardening-space-computers-with-software

The supercomputer, called Spaceborne Computer, contains two servers and no modifications to its hardware. A water-cooled enclosure will further help it deflect radiation while the software will have to meet Nasa’s strict standards, in place to protect spacecrafts and astronauts.

Last edited by Hammer on 24-Nov-2024 at 11:32 PM.
Last edited by Hammer on 24-Nov-2024 at 11:31 PM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

Why images are still screwing threads on amigaworld?. Not everyone has a 55" or greater screen in order to visualize the posts.

_________________
Amiga 1200 desktop. Apollo 030/50 Mhz 8mb ram + ClassicWB + Wb 3.1
Amiga 500 + ACA500plus 8mb + 30gb CF
Raspberry Pi 3b+ and Amibian 1.4
Mac Mini G4 1GB Ram with the butterfly!!

kolla Quote:

Do you even grasp what the concept of "real time" means? Because it really seems like you don't.

The problem with a monolithic kernel containing much of the OS including drivers is that the OS operates in supervisor mode and can not respond to I/O interrupts for long periods of time. One of the techniques to improve interrupt response times is to optimize the most commonly executed kernel code to reduce the time executing the code. There are other techniques like conditionally compiled Linux kernel code to disable the MMU so the uClinux fork is no longer necessary.

https://en.wikipedia.org/wiki/μClinux

Linux was not designed for "real time" response times and without a major redesign will never be as good of a RTOS as OSs designed for fast response times like FreeRTOS and the AmigaOS. Turning a RTOS like the AmigaOS into a workstation/server OS like Linux can be challenging too.

kolla Quote:

Sure, as does living closer to the magnetic poles (I've been operating servers at 78°)... but there's also a vast difference between "radiation" and "radiation".

Right. There are different levels of radiation in and out of Earths atmosphere. Solar activity varies and there can be other sources of radiation too.

Yssing Quote:

Maybe it is about time to ditch PPC and go for RISC-V

SiFive is doing a good job of catching up to ARM and the more open, less controlled, more flexible and cheaper to produce RISC-V hardware has some appealing advantages. The disadvantages of a less mature, less standard and a weak performance ISA should be considered too. The maturity will consider to increase but less standard and weak performance disadvantages will remain. For porting the AmigaOS to RISC-V, the big endian support is less than ARM but ARM is reducing their big endian support as well despite trying to become more standardized.

Hammer Quote:

The water can protect against radiation and provide cooling.

Dense materials provide the best radiation shielding but are heavy. Liquids may be able to provide radiation shielding and cooling in some environments but it may be unnecessary at high earth altitudes and in space where it may be cold enough already.

@matthey
Quote:

OSs designed for fast response times like FreeRTOS

The main point of of RTOS is not to have “fast reponse times� (whatever “fast� is), but reliable finite reponse times that are guaranteed. Again you drag uCLinux into this, notice how the words “real� and “time� are not present on the wiki page - uCLinux has nothing to do with RT. However, another monolithic OS does - VxWorks.

Last edited by kolla on 25-Nov-2024 at 08:05 PM.
Last edited by kolla on 25-Nov-2024 at 07:12 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

Quote:

matthey wrote: Maybe RISC ISAs are experimental. ...

It is well proofed when it was still called MIPS, the PS1 used it, the Ubiqui router I wrote a program for used it too.

@kolla

Quote:

kolla wrote: @matthey Quote: So throw everything in a big fat monolithic kernel and optimize it? Do you even grasp what the concept of "real time" means? Because it really seems like you don't.

"monolithic kernel" and "real-time kernel" are two completely separated concepts.

The last recent set of patches introduced on Linux seems to have added "real-time" support on it, despite being a monolithic kernel. How much real-time I've no idea, because I haven't go deep on the technical aspects. But since Linux is a monster, I doubt that it can compete with other RT OSes.

kolla Quote:

The main point of of RTOS is not to have “fast reponse times� (whatever “fast� is), but reliable finite reponse times that are guaranteed. Again you drag uCLinux into this, notice how the words “real� and “time� are not present on the wiki page - uCLinux has nothing to do with RT. However, another monolithic OS does - VxWorks.

Response time is one measure for a real time OS. All of the following times are in microseconds.

OS | response time | latency | latency jitter
Win_XP 200 848 700
Win_CE 20 99 89
Linux 14 98 78
RTAI 5 11 7
Neutrino 20 35 32
uC/OS-II 2 3 2
VxWorks 4 13 10

A Real Time Operating Systems (RTOS) Comparison
https://www.lisha.ufsc.br/wso/wso2009/papers/st04_03.pdf

Real Time Application Interface (RTAI) is called real time Linux in the article. What is the solution to the Linux monolithic kernel problem?

https://www.lisha.ufsc.br/wso/wso2009/papers/st04_03.pdf Quote:

RTAI approach consists in isolating the operating system into domains, making the real time domain as the one with highest priority. Whenever a real time task needs to be executed, a tiny scheduler, also called a nanokernel, schedules this task, freezing the whole remaining system. When there are no pending real time jobs to be done, the other parts of the system, such as GUI and user interface are executed (Barabanov 1997). This solution is excellent, as most real time systems consists of a combination of tasks with soft and hard real time requirements (Labrosse 2002). This enables the use of a single computer to control both real time critical functions and user interface, networking or others features that can be added at any time without changing the real time performance

A nanokernel!

The analysis of Linux follows.

https://www.lisha.ufsc.br/wso/wso2009/papers/st04_03.pdf Quote:

3.5. Linux Linux is a free operating system, with a modular monolithic kernel where all the important parts of the operating systems are in kernel space, such as memory management, task scheduler, filesystem and device drivers. It is possible to dynamically add or remove parts and functions of the kernel using Linux Kernel Modules (LKMs). Linux kernel implements memory protection with the MMU aid. The evaluated Linux kernel was 2.6.18. Regarding real time systems, Linux is not a real time operating system, although, there is a low latency kernel patch called low-preempt patch that can be applied to the mainstream Linux to add soft real time capacity to the system. Linus Torvalds himself (Linux’s author) affirmed in 2006 that he would use Linux to control a laser cutting machine using this patch. However, adding more rigorous real time constraints, is not an easy task. Including hard real time guarantees in a kernel with millions of lines of code is very complex and could lead to errors. As the low-preempt patch is not fully adequate to transform Linux in a full real time kernel, better approaches should be used to solve this problem as it is discussed later in this article. Additionally, Ambike measured the clock resolution of popular systems such as Windows 2000 and Red Hat Linux 7.3, and obtained conclusive information to state that these systems are not good options for real time applications (Ambike et al. 2005). Despite the fact that Linux is not a RTOS, it showed good temporal behavior, but when high frequencies were applied to the interrupt input pin joint with ping flood, the system became unstable and crashed. The jitter was also relatively high, and could cause unexpected variations in real time systems that needs precision.

Linux performed better than Windows but crashing is a fail. It is an old article so maybe Linux has improved. If the real time patches were so good with no disadvantages, they would be used all the time. Real time OSs do not need to patch their kernels even though they may make compromises for more desktop like features.

Last edited by matthey on 26-Nov-2024 at 04:33 PM.

@matthey

Quote:

The evaluated Linux kernel was 2.6.18.

Please, that’s 18 years ago…

And also, that’s not the real-time Linux as we speak of it today, that’s RTAI, one of many alternative ways to run real-time environments along with Linux…

https://www.rtai.org - latest release 5.3, from May 2021 supporting up to Linux 4.19, from almost three years before. https://www.rtai.org/Announcements.html

When we speak of “the RT patchset�,we normally speak of this - with the Linux kernel itself being preemtible… not some nanokernel hiding below or beside.

https://bootlin.com/doc/training/preempt-rt/preempt-rt-slides.pdf

Quote:

The RT patch makes the kernel deterministic and preemptible… but the goal is not to have the lowest latency possible

Last edited by kolla on 26-Nov-2024 at 12:09 AM.
Last edited by kolla on 26-Nov-2024 at 12:07 AM.
Last edited by kolla on 25-Nov-2024 at 11:41 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@matthey

Quote:

The problem with a monolithic kernel containing much of the OS including drivers is that the OS operates in supervisor mode and can not respond to I/O interrupts for long periods of time. One of the techniques to improve interrupt response times is to optimize the most commonly executed kernel code to reduce the time executing the code. There are other techniques like conditionally compiled Linux kernel code to disable the MMU so the uClinux fork is no longer necessary.

1. SpaceX uses Linux kernel 3.2 (with real-time patches) on the primary flight computers of both Dragon and its rockets (Falcon 9 and Starship).

2. "We actually hire a lot of our best software engineers out of the gaming industry," said SpaceX CEO Elon Musk.

Falcon 9 is effectively a "gaming PC" interacting with the real world.

Reference
https://www.businessinsider.com/why-is-spacex-at-a-video-game-conference-2015-3?IR=T

Quote:

Title: What on Earth is SpaceX doing at a video game conference? "We actually hire a lot of our best software engineers out of the gaming industry," said SpaceX CEO Elon Musk, when Fast Company posed this question during the May 29 Dragon V2 unveiling. "In gaming there’s a lot of smart engineering talent doing really complex things. [Compared to] a lot of the algorithms involved in massive multiplayer online games…a docking sequence [between spacecraft] is actually relatively straightforward. So I’d encourage people in the gaming industry to think about creating the next generation of spacecraft and rockets."

As video games get more complex, you're dealing with physics and spatial analysis problems with the exact same C++ code you might use for rocket simulations at the SpaceX lab.

There are many experienced advanced 3D game engine programmers for X86 when compared to 68K or RISC-V.

The Amiga has been out of the 3D gaming business for a long time.

Last edited by Hammer on 26-Nov-2024 at 10:10 PM.
Last edited by Hammer on 26-Nov-2024 at 01:43 AM.
Last edited by Hammer on 26-Nov-2024 at 01:39 AM.
Last edited by Hammer on 26-Nov-2024 at 01:38 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@kolla

Quote:

kolla wrote: @matthey Quote: The evaluated Linux kernel was 2.6.18. Please, that’s 18 years ago… And also, that’s not the real-time Linux as we speak of it today, that’s RTAI, one of many alternative ways to run real-time environments along with Linux… https://www.rtai.org - latest release 5.3, from May 2021 supporting up to Linux 4.19, from almost three years before. https://www.rtai.org/Announcements.html When we speak of “the RT patchset�,we normally speak of this - with the Linux kernel itself being preemtible… not some nanokernel hiding below or beside. https://bootlin.com/doc/training/preempt-rt/preempt-rt-slides.pdf Quote: The RT patch makes the kernel deterministic and preemptible… but the goal is not to have the lowest latency possible

Have you read those slides? There are a lot of limits and problems, which are explained from slide n.42 to 56 (this in particular. At the very beginning).

It'd be good to have some benchmarks like the ones which Matt posted.

kolla Quote:

Please, that’s 18 years ago…

The paper I linked was published in 2009. The Bootlin slides you link below shows hardware using Cortex-A7 cores released in 2011.

kolla Quote:

And also, that’s not the real-time Linux as we speak of it today, that’s RTAI, one of many alternative ways to run real-time environments along with Linux… https://www.rtai.org - latest release 5.3, from May 2021 supporting up to Linux 4.19, from almost three years before. https://www.rtai.org/Announcements.html When we speak of “the RT patchset�,we normally speak of this - with the Linux kernel itself being preemtible… not some nanokernel hiding below or beside. https://bootlin.com/doc/training/preempt-rt/preempt-rt-slides.pdf

If a large monolithic kernel is made preemptable, then the whole monolithic kernel must be locked in memory as nonswappable, increasing the memory footprint. This may not be a problem for small embedded systems with few drivers and is not a problem for systems without a MMU. The Zephyr RTOS switched from nanokernel/microkernel designs to a monolithic kernel for example.

https://en.wikipedia.org/wiki/Zephyr_(operating_system) Quote:

Early Zephyr kernels used a dual nanokernel plus microkernel design. In December 2016, with Zephyr 1.6, this changed to a monolithic kernel.

Zephyr OS is 7-8 kiB of memory on ARM/AArc32 with preemptive multitasking where the monolithic kernel is going to be tiny.

https://docs.zephyrproject.org/2.6.0/samples/basic/minimal/README.html

Zephyr OS uses some Linux code and is developed by the Linux Foundation so is another Linux connected RTOS attempt even though it is not Linux. There is a 2024 comparison of RTOSs with Zephyr OS by Beningo which showed Zephyr having the worst RTOS performance of 4 RTOSs.

https://github.com/zephyrproject-rtos/zephyr/discussions/79785

Every OS makes tradeoffs with advantages and disadvantages including the AmigaOS. The 68k AmigaOS is not the smallest and probably does not have the best RTOS performance but it is one of the most standardized small systems that avoids the need to recompile most software and it is a better RTOS than Linux with a smaller footprint that would make it useful for embedded use. The 68k AmigaOS needs modernization to better compete in the embedded market but it is far more competitive than AmigaOS 4 is in the desktop market where Linux destroys it.

Hammer Quote:

As video games get more complex, you're dealing with physics and spatial analysis problems with the exact same C++ code you might use for rocket simulations at the SpaceX lab. There are many experienced advanced 3D game engine programmers for X86 when compared to 68K or RISC-V. The Amiga out of 3D gaming business for a long time.

Games and playing video can be considered soft real time applications as everything should remain synced. The 68k Amiga pioneered real time performance for games and video for low cost personal computer and embedded use.

cdimauro Quote:

Have you read those slides? There are a lot of limits and problems, which are explained from slide n.42 to 56 (this in particular. At the very beginning). It'd be good to have some benchmarks like the ones which Matt posted.

Considering the importance of RTOS benchmarks, it is surprising there are not more measurements and comparisons. I think developers would often choose a different RTOS and/or hardware if they had measurements and benchmarks. The 2024 RTOS Beningo report may be available without a subscription from the last link I posted above. These RTOS comparisons do not compare the hardware where some is better for RTOS use. One of the few hardware or system comparisons comes from Michael Schulz but is old.

https://kgsvr.net/andrew/amiga/amiga.diffnt.html#fast.switch Michael Schulz Quote:

A context switch on AmigaOS is much quicker than in some larger operating systems. Here are some context switch speeds for different machines/operating systems (in microseconds): 26 uS for 25MHz Amiga A4000/040 AmigaOS 3.1 71 uS for 100MHz Pentium Linux 1.2.13 89 uS for 233MHz AlphaStation 255/233 Digital Unix 3.2 102 uS for 150MHz DEC 3000/300 OSF/1 2.0 106 uS for 66MHz Snake HP-UX 9.x 126 uS for 25MHz Amiga A2000/030 AmigaOS 2.1 128 uS for 40MHz Viking SunOS 4.1.3 131 uS for 167MHz SPARC Ultra-1 Solaris 2.5 210 uS for 33MHz 486 386BSD 0.1 212 uS for 50MHz RIOS AIX 3.2

It should be easier with so little choice today. Just ARM, RISC-V and x86-64 architectures and a hand full of OSs.

@matthey

Quote:

matthey wrote: If a large monolithic kernel is made preemptable, then the whole monolithic kernel must be locked in memory as nonswappable, increasing the memory footprint. This may not be a problem for small embedded systems with few drivers and is not a problem for systems without a MMU. The Zephyr RTOS switched from nanokernel/microkernel designs to a monolithic kernel for example. https://en.wikipedia.org/wiki/Zephyr_(operating_system) Quote: Early Zephyr kernels used a dual nanokernel plus microkernel design. In December 2016, with Zephyr 1.6, this changed to a monolithic kernel. Zephyr OS is 7-8 kiB of memory on ARM/AArc32 with preemptive multitasking where the monolithic kernel is going to be tiny. https://docs.zephyrproject.org/2.6.0/samples/basic/minimal/README.html Zephyr OS uses some Linux code and is developed by the Linux Foundation so is another Linux connected RTOS attempt even though it is not Linux. There is a 2024 comparison of RTOSs with Zephyr OS by Beningo which showed Zephyr having the worst RTOS performance of 4 RTOSs. https://github.com/zephyrproject-rtos/zephyr/discussions/79785

Guess what...

But maybe kolla could explain it: after having reported a link about the RT patch integrated in the Linux kernel, he might have automagically acquired knowledge about how OSes work and what RT means...
Quote:

Every OS makes tradeoffs with advantages and disadvantages including the AmigaOS. The 68k AmigaOS is not the smallest and probably does not have the best RTOS performance but it is one of the most standardized small systems that avoids the need to recompile most software and it is a better RTOS than Linux with a smaller footprint that would make it useful for embedded use.

It's good for embedded use, but the Amiga OS isn't a RTOS. By (its API) definition.
Quote:

The 68k AmigaOS needs modernization to better compete in the embedded market but it is far more competitive than AmigaOS 4 is in the desktop market where Linux destroys it.

AROS has already "modernized it": it could be a good starting point.
Quote:

cdimauro Quote: Have you read those slides? There are a lot of limits and problems, which are explained from slide n.42 to 56 (this in particular. At the very beginning). It'd be good to have some benchmarks like the ones which Matt posted. Considering the importance of RTOS benchmarks, it is surprising there are not more measurements and comparisons.

It's not a surprise: it's expected.

In fact, talking about RT for an OS is very easy, trumpeting fabulous things, but honouring the "R" could become very hard and showing that a very different picture...
Quote:

I think developers would often choose a different RTOS and/or hardware if they had measurements and benchmarks. The 2024 RTOS Beningo report may be available without a subscription from the last link I posted above. These RTOS comparisons do not compare the hardware where some is better for RTOS use. One of the few hardware or system comparisons comes from Michael Schulz but is old. https://kgsvr.net/andrew/amiga/amiga.diffnt.html#fast.switch Michael Schulz Quote: A context switch on AmigaOS is much quicker than in some larger operating systems. Here are some context switch speeds for different machines/operating systems (in microseconds): 26 uS for 25MHz Amiga A4000/040 AmigaOS 3.1 71 uS for 100MHz Pentium Linux 1.2.13 89 uS for 233MHz AlphaStation 255/233 Digital Unix 3.2 102 uS for 150MHz DEC 3000/300 OSF/1 2.0 106 uS for 66MHz Snake HP-UX 9.x 126 uS for 25MHz Amiga A2000/030 AmigaOS 2.1 128 uS for 40MHz Viking SunOS 4.1.3 131 uS for 167MHz SPARC Ultra-1 Solaris 2.5 210 uS for 33MHz 486 386BSD 0.1 212 uS for 50MHz RIOS AIX 3.2

Too much different hardware to judged. And it's also too much outdated.
Quote:

It should be easier with so little choice today. Just ARM, RISC-V and x86-64 architectures and a hand full of OSs.

handful = mostly Linux. Unfortunately...

@matthey

Quote:

Games and playing video can be considered soft real time applications as everything should remain synced. The 68k Amiga pioneered real time performance for games and video for low cost personal computer and embedded use.

The Amiga is weak in real-time 3D with physics. Hint: Motorola 68K boat anchor with expensive fast IEEE-754 solutions.


https://learn.microsoft.com/en-us/windows/iot/iot-enterprise/soft-real-time/soft-real-time
Microsoft added soft real-time extensions for Windows 10 IoT Enterprise, version 21H2.

Microsoft has Azure Real-Time OS with hard real-time features. https://en.wikipedia.org/wiki/ThreadX

https://wccftech.com/xbox-one-architecture-explained-runs-windows-8-virtually-indistinguishable/
Xbox One's operating system architecture

Xbox One does indeed run three operating systems but the correct ones are: a full fledged Windows 8, a stripped down Windows 8, and a Host OS (RTOS)

The first tier 'Host OS' and the 'to-the-metal- operating system present in Xbox One dubbed the 'Host OS' is an RTOS (Real Time Operating System) has complete control over the entire Xbox One hardware and resources.


Microsoft has its Windows NT kernel personnel like Dave Culter allocated to the Xbox division.

Xbox division has Microsoft's latest OS development.

For the Amiga context, AROS is a good starting point, and targeting a particular market with $$$$ would be good.

Last edited by Hammer on 26-Nov-2024 at 10:44 PM.
Last edited by Hammer on 26-Nov-2024 at 10:41 PM.
Last edited by Hammer on 26-Nov-2024 at 10:37 PM.
Last edited by Hammer on 26-Nov-2024 at 10:17 PM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@matthey

Quote:

Dense materials provide the best radiation shielding but are heavy. Liquids may be able to provide radiation shielding and cooling in some environments but it may be unnecessary at high earth altitudes and in space where it may be cold enough already.

Conductive and convective cooling are non-staters in a vacuum, radiative cooling is the preferred method.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@matthey

Quote:

matthey wrote: So throw everything in a big fat monolithic kernel and optimize it?

If someone of of would had the task to build a system for an embedded system used on a space probe, he wouldn't care if it's a monolithic kernel or if not.

The real downs of a monolithic kernel comes if you are adding drivers after it was built, but on space probe you will never have the chance to plug in an USB stick when it is on its way.

A monolithic kernel that is reduced to all the drivers it needs, would be better than a micro kernel that is loading it, when new devices are added.

If you are seeing it from a 'real time' perspective.

Don't load things when the system is up and running.

---

I wasn't even allowed to use C++ methods like 'new' in our systems, it has a negative impact on real-time systems. That's why some modern application developers struggle with embedded programming, everything they where tought about dynamic memory management, or about instantiating of objects is wrong.

Last edited by OneTimer1 on 27-Nov-2024 at 04:13 PM.
Last edited by OneTimer1 on 27-Nov-2024 at 04:06 PM.
Last edited by OneTimer1 on 27-Nov-2024 at 04:06 PM.
Last edited by OneTimer1 on 27-Nov-2024 at 09:07 AM.
Last edited by OneTimer1 on 27-Nov-2024 at 09:06 AM.

@OneTimer1
A monolithic kernel can be fine when it is small and there are limited and fixed device drivers. I mentioned the Zephyr OS which switched from a nanokernel/microkernel to a monolithic kernel. Zephyr OS is likely mostly used for small/tiny footprint MCUs/RT hardware. It is the large monolithic kernels for more dynamic systems where monolithic kernels become unwieldy and increase system footprints.

@matthey

I’m glad you found a new shiny pony to ride in your totally irrelevant to anything Amiga RTOS rants. And a better pony it is - unlike old uCLinux, Zephyr _is_ RT, can run with or without the good-for-nothing MMU, and you can download it and run it on hardware you have available right now. Please do test it! Too bad it’s monolithic, but I notice you’ve changed your stance a bit already, whaddayaknow!

Meanwhile, certain industries are happy to see the remaining RT capabilities at last coming to mainline Linux, simplifying the process of maintenance.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla: how much RT is Linux is yet to be seen. And Zephyr as well.

@OneTimer1

Quote:

OneTimer1 wrote: @matthey Quote: matthey wrote: So throw everything in a big fat monolithic kernel and optimize it? If someone of of would had the task to build a system for an embedded system used on a space probe, he wouldn't care if it's a monolithic kernel or if not. The real downs of a monolithic kernel comes if you are adding drivers after it was built, but on space probe you will never have the chance to plug in an USB stick when it is on its way. A monolithic kernel that is reduced to all the drivers it needs, would be better than a micro kernel that is loading it, when new devices are added.

That's not the real advantage of a monolithic kernel.

Especially when talking of microkernels on the same topic, because microkernels have the great virtue of a very reduced core with only essential functions -> everything else is done in user-space and... WHEN IT'S NEEDED.

What's more important, if you load a drive on a microkernel and then it shows some problems, it can be restarted or even reloaded without forcing to restart the whole system.

Just to give a example of their capabilities and net advantages over monolithic kernels.
Quote:

If you are seeing it from a 'real time' perspective. Don't load things when the system is up and running. --- I wasn't even allowed to use C++ methods like 'new' in our systems, it has a negative impact on real-time systems. That's why some modern application developers struggle with embedded programming, everything they where tought about dynamic memory management, or about instantiating of objects is wrong.

No, that's not true.

The real problem here is that C++ noobies don't know how to overload C++'s new and delete operators to finely tune the application's memory allocation/deallocation. So, they use the defaults that can introduce an overhead.

I don't like C++ because it's too big and complicated language to study and mastering it requires time. But at least I can give credit to it because it allows to control and customize every single aspect in the code.

@kolla
The uCLinux mention was because of 68k/ColdFire support and Jeff Dionne who likes the 68k and is the CEO who revived SuperH with the J-Core project. The revival of SuperH was partially based on incorrect code density data from Dr. Vince Weaver which I helped him correct. It should have been the 68k that was revived instead.

The Zephyr OS for small RT systems and Linux with RT additions for larger systems demonstrates poor scaling of Linux like OSs. It is kind of like the poor scaling of ARM architectures where Thumb(-2) is used for small embedded systems and ARM64/AArch64 for larger embedded systems. The 68k AmigaOS scaled lower than Linux and up to the desktop with RT capabilities while the 68k scaled from 32-bit embedded to 32-bit workstation markets, both of which it created, with a single ISA. Linux is maybe better for RT use than the AmigaOS is for desktop use but the AmigaOS has been hidden away and under developed. The 68k could scale from low to high again with a 64-bit mode but it is not developed. Linux and ARM are reinvented over and over again while a whole world of other possibilities will never be invented.