[Info-vax] Kernel Transplantation (was: Re: New CEO of VMS Software)
Dan Cross
cross at spitfire.i.gajendra.net
Sat Jan 6 19:52:22 EST 2024
In article <uncl7l$p3mp$5 at dont-email.me>,
Lawrence D'Oliveiro <ldo at nz.invalid> wrote:
>On Sat, 6 Jan 2024 20:31:22 -0000 (UTC), Dan Cross wrote:
>
>> But that's not what he actually said: you omitted the critical word,
>> "kernel", as in _kernel resources_ used by different users.
>
>Since *all* resources are defined (and managed) as such by the kernel, I
>fail to see what the distinction is.
That is evident, but this is not the flex you think that it is.
>cgroups let you manage CPU time usage and CPU affinity (are CPUs a
>"kernel" resource?), memory usage (is that a "kernel" resource?), I/O
>usage (is that a "kernel" resource?), RDMA usage (is that a "kernel"
>resource?), numbers of processes created (is that "kernel" resource?)
>etc etc.
>
>Otherwise, feel free to explain what the distinction is between a "user"
>resource and a "kernel" resource.
Since you asked....
User resources: resources allocated to a user process for the
purpose of executing user code. Examples may include mapped
segments containing executable text, read-only or read/write
data, identifiers handed to userspace to identify resources
held by the kernel on a process's behalf (file and socket
descriptors, for example).
Kernel resources: Those allocated by the kernel for its internal
use. Examples may include page tables describing an address
space, the mapping of user-visible tokens to IO resources (e.g.,
the file array that maps file descriptors to the kernel's
representation of an open file or socket or pipe or whatever),
on Unix-y systems the set of signals pending delivery in the
process, etc. Other examples may include things like a
description of the buses and peripheral devices (e.g., the
complete enumeration of the PCIe topology), buffers associated
with IO devices and the filesystem, a page cache, etc.
Some things blur the line: is the `proc` structure describing a
process a kernel resource, even though it's sole purpose is to
describe a user process? Most kernel people would probably say
yes, particularly as (on Unix-y style systems) the proc
structure allocated to a process will outlive the process itself
(e.g., so that the parent can `wait` on it to collect its exit
status).
These are just a few examples.
>>>Remember that my proposal for adopting the Linux kernel would get rid of
>>>every part of VMS that currently runs at higher than user mode. It's
>>>only their own user-mode code that customers would care about.
>>
>> You think that's easy, but it is clear that you really don't understand
>> the issues involved.
>
>The poster I was replying to already conceded this point.
Yes, everyone has acknowledged that you don't understand the
issues involved.
>> Containers started as a way to run multiple versions of some very large
>> programs with disparate library and other dependencies on a single
>> system, and grew into a mechanism for managing resources generally.
>
>You are thinking of Docker.
No, I am not. I was there when containers were invented, and I
know very much what the original use case was.
>Which is just one kind of "container"
>technology. Remember that "containers" as such do not exist as a built-in
>primitive in the Linux kernel: they are constructed out of a bunch of
>lower-level primitives, including cgroups and the various kinds of
>namespaces. This allows for very different kinds of technologies to be
>built that call themselves "containers". And for them to coexist.
Yawn. Cool story, bro.
>> Every Mac on the planet runs more or less a version of Mach+BSD.
>
>And doesn't exactly do so well.
"For some specific use cases." FTFY.
>Back when Apple sold servers, I remember a
>review of MySQL running on OS X Server versus Linux, on the same hardware.
>
>Linux ran circles around Apple's microkernel-based OS. On the company's
>own hardware.
I remember when Linux acquired TCP/IP support. It was
consistently about 10% slower than BSD at the time. What's your
point? But if we're going to go there....
Why, after all these years, does USB audio on Linux fail so
miserably so often? Why do they still have problems with
suspend and resume on laptops? Why does Linux panic when you
turn on built-in features, like AX.25? Why is it such a pain to
partition disks? Why does the `ss` command still not show
routing tables for lesser-used protocols? Why are the debugging
tools so primitive compared to what Sun was doing 20 years ago
with dtrace? Why don't they have something as robust and
functional as ZFS? Why can't the amazingly resourced Linux
repeat what a group of like 5 engineers at Sun did in 18 months
20 years ago?
You seem to think that Linux is so great, and the irony is that
you're actually _right_. But it's obvious that you don't have
the first clue about _why_ you think that, or what makes Linux
great.
>> The Intel ME embedded in most Intel CPUs runs Minix3.
>
>Bad, bad example.
><https://arstechnica.com/information-technology/2017/05/the-hijacking-
>flaw-that-lurked-in-intel-chips-is-worse-than-anyone-thought/>
Yup. They had a pretty bad flaw. Do you think it hasn't been
fixed? And do you think that's the fault of the kernel that
runs on the ME? That was, after all, in an application program
that ran on that OS: should we start comparing to CVEs in
programs that run under Linux? For that matter, should we start
comparing CVEs between Minix and Linux?
I notice you elided my other examples, as they did not support
your point.
- Dan C.
More information about the Info-vax
mailing list