* [9fans] Nix to test Nix (or others)
@ 2025-01-21 8:42 tlaronde
2025-01-21 17:31 ` Ron Minnich
0 siblings, 1 reply; 2+ messages in thread
From: tlaronde @ 2025-01-21 8:42 UTC (permalink / raw)
To: 9fans
I'd like to know if I'm totally lost about this idea:
With at least 2 cores, start with a TC on only one core
(if there is one primus inter pares [PiP] because of hard wires ports,
this one).
This is used for code development.
It seems to me that traditional OSes take as undifferentiated as
"root", two different "users": hardware user and soft user. Very roughly
speaking, for me, a "soft" user deals with binds, a "hard" user deals
with mounts.
But as there can be several distinct "soft" users, there can be
several distinct "hard" users: cores.
When a device, for example, is MMIO mapped, the PiP core
(that owns the most important: memory and memory mapping) could
"delegate" a device to another core---a KC.
When doing kernel development (on the PiP TC), one could test the new
kernel, specially when trying a kernel driver, by running the tested
code on another KC. If things go wrong, shut the KC.
It has always frustrated me to have to rely on emulation (that
doesn't, in fact, allow to really test things, because of emulation)
or to use a VM (that offers not the hardware but a virtual hardware
depending on the host) and to have the obligation to cross fingers
when one has to update specially a remote machine that have no
clone (with the exact same hardware) locally on which to thoroughly
test things before.
Isn't Nix a step offering the possibility to almost direct access
(with the lightest layer of interference due to MMIO) and partitioning
on hardware, that is another solution to the problem kernel panics
of monolithic kernels?
The only not testable part is the memory. But there are simulators
(for example the Donald E. Knuth's MMIXware).
Am I totally on the wrong track?
--
Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
http://www.kergis.com/
http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T448db0ae05409971-Md57e694f0e299263ac05d71b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [9fans] Nix to test Nix (or others)
2025-01-21 8:42 [9fans] Nix to test Nix (or others) tlaronde
@ 2025-01-21 17:31 ` Ron Minnich
0 siblings, 0 replies; 2+ messages in thread
From: Ron Minnich @ 2025-01-21 17:31 UTC (permalink / raw)
To: 9fans
you're asking for logical partitioning, as done on IBM power for
example, so you can run two kernels on one machine at the same time.
On Intel it's not easy. We tried it for several years at one of my jobs.
A friend from Google reminded me of my summary of the experience.
“For all the years I have left on this earth, I don’t ever want to
work on this problem again”
- Ron (rminnich@) 2020-06-16
So, your idea is cool, but ... I think I won't go there :-)
On Tue, Jan 21, 2025 at 5:28 AM <tlaronde@kergis.com> wrote:
>
> I'd like to know if I'm totally lost about this idea:
>
> With at least 2 cores, start with a TC on only one core
> (if there is one primus inter pares [PiP] because of hard wires ports,
> this one).
>
> This is used for code development.
>
> It seems to me that traditional OSes take as undifferentiated as
> "root", two different "users": hardware user and soft user. Very roughly
> speaking, for me, a "soft" user deals with binds, a "hard" user deals
> with mounts.
>
> But as there can be several distinct "soft" users, there can be
> several distinct "hard" users: cores.
>
> When a device, for example, is MMIO mapped, the PiP core
> (that owns the most important: memory and memory mapping) could
> "delegate" a device to another core---a KC.
>
> When doing kernel development (on the PiP TC), one could test the new
> kernel, specially when trying a kernel driver, by running the tested
> code on another KC. If things go wrong, shut the KC.
>
> It has always frustrated me to have to rely on emulation (that
> doesn't, in fact, allow to really test things, because of emulation)
> or to use a VM (that offers not the hardware but a virtual hardware
> depending on the host) and to have the obligation to cross fingers
> when one has to update specially a remote machine that have no
> clone (with the exact same hardware) locally on which to thoroughly
> test things before.
>
> Isn't Nix a step offering the possibility to almost direct access
> (with the lightest layer of interference due to MMIO) and partitioning
> on hardware, that is another solution to the problem kernel panics
> of monolithic kernels?
>
> The only not testable part is the memory. But there are simulators
> (for example the Donald E. Knuth's MMIXware).
>
> Am I totally on the wrong track?
> --
> Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
> http://www.kergis.com/
> http://kertex.kergis.com/
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T448db0ae05409971-M8e2df0ae92865d19ee6bc18b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2025-01-21 17:43 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-01-21 8:42 [9fans] Nix to test Nix (or others) tlaronde
2025-01-21 17:31 ` Ron Minnich
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).