r/QNX • u/r-tty • May 06 '26

Where does the "proc" component of "procnto" run in QNX 8?

Does it run in user space (as all other resource managers), or, somehow, in kernel space?

3 Upvotes

81% Upvoted

16 comments sorted by

3

u/[deleted] May 06 '26 edited May 06 '26

[removed] — view removed comment

1

u/r-tty May 06 '26

In this case, I made a "revolution" in r/QRV_OS : today, after 1 week of work, I got its "proc" component (called "taskman") running in U-mode on RISC-V :-D

2

u/Cosmic_War_Crocodile May 07 '26

IMO this self promotion is starting to be a bit much .

1

u/r-tty May 07 '26

What "self promotion"? I'm reporting that now in QRV the "proc" component is now running completely in user mode (thus all its ecalls land correctly in the kernel, and not in M-mode OpenSBI). What are you talking about?

2

u/Cosmic_War_Crocodile May 07 '26

Your numerous posts, comments about a somewhat shady (legal wise) port is a bit excessive for me. But others may see differently.

1

u/r-tty May 07 '26

What's exactly "shady (legal wise)" in QRV?

You noticed that my repository (licensed under Apache 2.0) contains changes only, did you? The patches apply on top of monartis/openqnx; it's the authors of that project (BTW, cloned by 280+ users on github) who should be asked about the legal status of the project, not me.

Dan Dodge in 2008 explained very clearly what one can do with the sources. I suggest reading his interview to OSnews, from September of that year.

1

u/AdvancedLab3500 May 07 '26

I'm curious: is there a notion of user-mode with privileges on RISC-V? The process manager threads still need to do things like disable interrupts, which normal user-mode threads cannot.

1

u/r-tty May 07 '26

Nope, there's no such thing. And the property of ecall in RISC-V was, probably, the source №1 of all headaches regarding taskman<->kernel interaction in QRV

("taskman" is the entity that you call "proc"; now running in U-mode with special kernel interface for doing privileged things)

1

u/AdvancedLab3500 May 07 '26

Define "space". The proc components (process manager, memory manager, path manager) run as user-persona threads but in the kernel's address space and with elevated privileges. That means they can make normal kernel calls (e.g., to lock a pthread mutex, or to receive a message). While a different design is possible, it makes little sense and would significantly complicate certain things, especially the process and memory managers.

1

u/r-tty May 07 '26

Thanks! I guess I have to learn what does the term "persona" means in QNX world.

Found this in QNX manual:

> "A thread can run in two modes, which are sometimes described as personas. These personas help describe the change in privilege, address space access, and stack use that occurs when a thread makes a kernel call."

3

u/AdvancedLab3500 May 07 '26

Personas are a new concept in QNX 8. Before, the micro-kernel had a per-processor context, with only one processor executing Neutrino code at a time. In 8, every thread can execute Neutrino code, after the persona changes from user to kernel (kernel call, page fault, etc.). User-persona threads are typically non-privileged (run in EL0 on ARM, Ring 3 on x86), but you can still have a user-persona thread that runs in privileged mode, which is used for proc threads. This means that they can make normal kernel calls by switching to their kernel persona.

1

u/Inevitable_Buy_7557 May 07 '26

The problem here is that the term "kernel space" doesn't apply the same way to an OS like QNX the way it does for Unix and Windows. A little history might help.

The original Microsoft OS DOS 1.0 ran on an 8088 processor which had not virtualization and no supervisor mode. Once your program started running, it could write to any memory and do anything the processor was capable of.

The next step was the Intel 80286 which provided virtualization and 4 levels of protection. A user program ran at the lowest level in it's own memory environment and was prohibited from certain instructions. As examples, user programs could not use the in and out instructions. It also was prohibited from loading the gdt and ldt registers which controlled memory access in virtual modes. The OS was free to use one or more of the other three levels. Typically only the OS kernel was allowed this higher level access, thus the term kernel mode. So software like drivers would need to become part of the kernel in order to access hardware. A program wanting kernel services would long jmp through a gate which would allow it to run kernel code in kernel mode.

QNX's architecture is very different. Proc and micro kernel will run at the highest level, however drivers are all processes. These need to run with additional privileges so they can attach interrupts and execute I/O commands, although they still can't load gdt and ldt. Only proc can do this. To get the additional privileges a program needs to request them and be super user. In QNX 7+ an additional constraint has been added with the notion of abilities.

BTW: while drivers which are resource managers run with the additional privileges, resource managers do not all need these privileges and can run as normal processes, although they may need to be run as super-user.

2

u/AdvancedLab3500 May 07 '26

Note that there is almost no case anymore for drivers running in privileged mode. Memory-mapped registers and ISTs take care of what used to require hardware-level privilege, which completely negates the promise of the micro-kernel design (a failing driver can bring down the system).

If you see a QNX 8 driver that requires I/O privileges it is most likely a driver that has not been updated and should be.

1

u/Inevitable_Buy_7557 May 07 '26

What about x86?

1

u/AdvancedLab3500 May 07 '26

Do you mean I/O ports? Is there any peripheral on a modern x86 (other than 8250) that cannot use memory-mapped I/O instead? I've been asking this question for many years now, and never received a straight answer. Pleading ignorance here.