Groups | Search | Server Info | Login | Register

Groups > comp.lang.misc > #11224

Re: [OT] NetBSD vs. Linux(-based systems)

Show all headers | View raw

In article <KKx97WvtTkldzxgb@violet.siamics.net>,
Ivan Shmakov  <ivan@siamics.netREMOVE.invalid> wrote:
>>>>>> On 2025-08-30, Lawrence D'Oliveiro wrote:

FYI, you are arguing with a known troll.  It is unlikely to turn
into a productive exercise, so caveat emptor.

> [snip]
> > I mean that Xen runs an actual Linux kernel in the hypervisor,
> > and supports regular Linux distros as guests -- they don't need to
> > be modified to specially support Xen, or any other hypervisor.
>
>	It's been well over a decade since I've last used Xen, so I'm
>	going more by http://en.wikipedia.org/wiki/Xen than experience.
>
>	But just to be sure, I've checked the sources [1], and while
>	I do see portions of Linux code reused here and there - such as,
>	say, [2] below - I'd hesitate to call Xen at large "Linux-based."
>	If anything, there's way more of Linux in the GNU Mach microkernel
>	(consider the linux/src/drivers subtree in [3], for instance)
>	than in the Xen hypervisor.  (And I don't recall GNU Mach being
>	called "Linux-based.")
>
>	To note is that there seem to be no mention in CHANGELOG.md of
>	anything suggesting that Xen uses Linux as its upstream project.

This is basically correct.  Xen falls into the broad category
known as "Type-1" hypervisors: meaning that Xen controls runs
directly on the bare metal outside of the context of an existing
OS (versus, say, KVM, Bhyve, etc).  It is true that Xen was
centered on Linux initially, and pulled in a lot of the code; I
think it's fair to say that early versions largely started with
(and in many ways were based on) the Linux kernel, but it has
clearly gone its own way.

In the Type-1 model, you still need some software component that
lets you do stuff like configure virtual machines, provide
device models to guests, and so on.  It's common to provide a
specially blessed VM instance (Dom0 in Xen; a "root VM" in
Hyper-V) to do this.

> 2>  * common/notifier.c
> 2>  *
> 2>  * Routines to manage notifier chains for passing status changes to any
> 2>  * interested routines.
> 2>  *
> 2>  * Original code from Linux kernel 2.6.27 (Alan Cox [...])
>
>[1] http://downloads.xenproject.org/release/xen/4.20.1/xen-4.20.1.tar.gz
>[2] xen-4.20.1/xen/common/notifier.c
>[3] git://git.sv.gnu.org/hurd/gnumach.git rev. 8d456cd9e417 from 2025-09-03
>
> > It's Linux above, and Linux below -- Linux at every layer.
>
>	Sure, if you want to run it that way.  You can also run Xen
>	with NetBSD at every layer, or, apparently, OpenSolaris.
>
>	A GNU/Linux distribution AFAICR needs to provide Xen-capable
>	kernel for it to be usable as dom0 - as well as Xen user-mode
>	tools.  Niche / lightweight distributions might omit such support.
>	(There're a few build-time options related to Xen in Linux.)
>
>	Also, Xen supports both hardware-assisted virtualization /and/
>	paravirtualization.  On x86-32, the former is not available, so
>	the Linux build /must/ support paravirtualization in order to be
>	usable with Xen, dom0 or domU.
>
>	When hardware-assisted virtualization /is/ available, the things
>	certainly get easier: pretty much anything that can run under,
>	say, Qemu, can be run under Xen HVM.  The performance may suffer,
>	though, should your domU system happen to lack virtio drivers and
>	should thus need to resort to using emulated peripherals instead.

Yes.  With Xen, you've got the Xen VMM running on the bare metal
and then any OS capable of supporting Xen's Dom0 requirements
running as Dom0, and essentially any OS running as a DomU guest.

So to summarize, you've got a hypervisor that descended from an
old version of Linux, but was heavily modified, running a gaggle
of other systems, none of which necessarily needs to be Linux.

> >> NetBSD supports running as both Xen domU (unprivileged) /and/
> >> dom0 (privileged.)
>
> > Linux doesn't count these as separate platforms.  They're just
> > considered a standard part of regular platform support.
>
>	Which means one needs to be careful when comparing architecture
>	support between different kernels.

I gathered your point was that neither Dom0 nor DomU _had_ to be
Linux, and that's true.  Note that the troll likes to subtlely
change the point that he's arguing.

> >> My point was that GNU/Linux distributions typically support less
>
> > But that's an issue with the various distributions, not with the
> > Linux kernel itself.
>
>	True.  That, however, doesn't mean you can use Linux /by itself/
>	outside of a distribution.  (Unless, of course, you're looking
>	for a kernel for a new distribution, but I doubt that undermines
>	my point.)  So architecture support /you/ will have /will/ be
>	limited by the distribution you choose, regardless of what Linux
>	itself might offer.
>
> > In the BSD world, there is no separate of "kernel" from "distribution".
> > That makes things less flexible than the Linux world.
>
>	That's debatable.  Debian for a while had a kFreeBSD port (with
>	a variant of the FreeBSD kernel separate from FreeBSD proper), and
>	from what I recall, it was discontinued due to lack of volunteers,
>	not lack of flexibility.
>
> > For example, while base Debian itself may support something under a
> > dozen architectures, there are offshoots of Debian that cover others.
>
>	How is this observation helpful?
>
>	Suppose someone asks, "what OS would you recommend for running
>	on loongarch?" and the best answer we here on Usenet can give
>	is along the lines of "NetBSD won't work, but there're dozens
>	of Debian offshoots around - be sure to check them all, as one
>	might happen to support it."  Really?
>
>	If you know of Debian offshoots that support architectures
>	that Debian itself doesn't, could you please list them here?
>	Or, if there's already a list somewhere, share a pointer.
>
> >> The way I see it, it's the /kernel/ that it takes the most effort
> >> to port to a new platform - as it's where the support for peripherals
> >> lives, including platform-specific ones.
>
> > Given that the Linux kernel supports more of these different
> > platforms than any BSD can manage, I think you're just reinforcing
> > my point.
>
>	Certainly - if your point is that way more effort went into
>	Linux over the past two to three decades than in any of BSDs.
>	(And perhaps into /all/ of free BSDs combined, I'd guess.)
>
> >> But I still think that if you're interested in understanding how
> >> your OS works - at the source code level - you'd be better with
> >> NetBSD than with a Linux-based OS.
>
> > Linux separates the kernel from the userland.  That makes things
> > simpler than running everything together, as the BSDs do.
>
>	I fail to see why developing the kernel and an OS based on it
>	as subprojects to one "umbrella" project would in any way hinder
>	code readability.
>
>	Just in case it somehow matters, there're separate tarballs under
>	rsync://rsync.netbsd.org/NetBSD/NetBSD-10.1/source/sets/ for the
>	kernel (syssrc.tgz) and userland (src, gnusrc, sharesrc, xsrc.)
>
>	That said, I've last tinkered with Linux around the days of
>	2.0.36 (IIRC), and I don't recall reading any Linux sources
>	newer than version 4.  If you have experience patching newer
>	Linux kernels, and in particular if you find the code easy to
>	follow, - please share your observations.

He doesn't.

	- Dan C.

Back to comp.lang.misc | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Algol 68 / Genie - opinions on local procedures? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-18 04:52 +0200
  Re: Algol 68 / Genie - opinions on local procedures? Andy Walker <anw@cuboid.co.uk> - 2025-08-18 16:54 +0100
    Re: Algol 68 / Genie - opinions on local procedures? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-18 18:30 +0200
      Re: Algol 68 / Genie - opinions on local procedures? Andy Walker <anw@cuboid.co.uk> - 2025-08-19 00:45 +0100
        Re: Algol 68 / Genie - opinions on local procedures? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-19 02:44 +0200
          Re: Algol 68 / Genie - opinions on local procedures? Andy Walker <anw@cuboid.co.uk> - 2025-08-20 00:47 +0100
            Re: Algol 68 / Genie - opinions on local procedures? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-20 00:43 +0000
              Re: Algol 68 / Genie - opinions on local procedures? Andy Walker <anw@cuboid.co.uk> - 2025-08-20 23:58 +0100
                Re: Algol 68 / Genie - opinions on local procedures? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-21 02:59 +0000
                Re: Algol 68 / Genie - opinions on local procedures? Andy Walker <anw@cuboid.co.uk> - 2025-08-23 00:42 +0100
                Re: Algol 68 / Genie - opinions on local procedures? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-23 02:29 +0200
                Re: Algol 68 / Genie - opinions on local procedures? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-23 02:36 +0000
                Economizing resource requirements (was Re: Algol 68 / Genie - opinions on local procedures?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-21 21:02 +0200
                Re: Algol 68 / Genie - opinions on local procedures? antispam@fricas.org (Waldek Hebisch) - 2025-10-04 01:11 +0000
                Re: Algol 68 / Genie - opinions on local procedures? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-04 03:37 +0000
                Re: Algol 68 / Genie - opinions on local procedures? Andy Walker <anw@cuboid.co.uk> - 2025-10-07 22:03 +0100
                Re: Algol 68 / Genie - opinions on local procedures? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-07 22:04 +0000
                Various digressions (was Re: Algol 68 / Genie - opinions on local procedures?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-08 01:27 +0200
                Re: Algol 68 / Genie - opinions on local procedures? Andy Walker <anw@cuboid.co.uk> - 2025-10-10 01:11 +0100
                Re: Algol 68 / Genie - opinions on local procedures? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-10 01:39 +0000
                Re: Algol 68 / Genie - opinions on local procedures? Andy Walker <anw@cuboid.co.uk> - 2025-10-11 12:47 +0100
                Re: Algol 68 / Genie - opinions on local procedures? antispam@fricas.org (Waldek Hebisch) - 2025-10-08 17:04 +0000
          simplicity / complexity Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-08-26 18:42 +0000
            Re: simplicity / complexity Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-27 00:28 +0000
              Re: simplicity / complexity Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-08-30 19:10 +0000
                Re: simplicity / complexity Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-30 22:43 +0000
                [OT] NetBSD vs. Linux(-based systems) Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-09-04 18:50 +0000
                Re: [OT] NetBSD vs. Linux(-based systems) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-05 00:03 +0000
                Re: [OT] NetBSD vs. Linux(-based systems) Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-09-07 15:55 +0000
                Re: [OT] NetBSD vs. Linux(-based systems) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-07 21:17 +0000
                Re: [OT] NetBSD vs. Linux(-based systems) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-09-05 12:02 +0000
                Re: [OT] NetBSD vs. Linux(-based systems) Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-09-07 16:30 +0000
            Re: simplicity / complexity Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-27 07:53 +0200
              Re: simplicity / complexity Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-08-30 19:39 +0000
                Re: simplicity / complexity Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-30 22:45 +0000
                Re: simplicity / complexity Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-08-31 13:35 +0000
                Re: simplicity / complexity Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-31 22:40 +0000
                [OT] free software Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-09-04 18:25 +0000
                Re: simplicity / complexity antispam@fricas.org (Waldek Hebisch) - 2025-10-08 14:03 +0000
                Re: simplicity / complexity Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-08 16:21 +0200
                Re: simplicity / complexity John Ames <commodorejohn@gmail.com> - 2025-10-08 08:08 -0700
                Re: simplicity / complexity Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-08 21:18 +0000
                Re: simplicity / complexity John Ames <commodorejohn@gmail.com> - 2025-10-08 14:31 -0700
                Re: simplicity / complexity Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-09 00:09 +0000
                Re: simplicity / complexity John Ames <commodorejohn@gmail.com> - 2025-10-09 08:44 -0700
                Re: simplicity / complexity Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-09 21:52 +0000
                Re: simplicity / complexity John Ames <commodorejohn@gmail.com> - 2025-10-09 15:21 -0700
                Re: simplicity / complexity antispam@fricas.org (Waldek Hebisch) - 2025-10-09 00:34 +0000
                Re: simplicity / complexity Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-09 03:48 +0200
                Re: simplicity / complexity ram@zedat.fu-berlin.de (Stefan Ram) - 2025-10-08 14:53 +0000
                Re: simplicity / complexity ram@zedat.fu-berlin.de (Stefan Ram) - 2025-10-08 15:24 +0000
                Re: simplicity / complexity antispam@fricas.org (Waldek Hebisch) - 2025-10-09 01:39 +0000
                Re: simplicity / complexity Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-09 04:00 +0200
                Re: simplicity / complexity antispam@fricas.org (Waldek Hebisch) - 2025-10-09 14:19 +0000
                Re: simplicity / complexity ram@zedat.fu-berlin.de (Stefan Ram) - 2025-10-09 14:48 +0000
                Re: simplicity / complexity Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-10 12:36 +0200
                Re: simplicity / complexity Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-10 12:09 +0200
                Re: simplicity / complexity Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-31 08:32 +0200
                Re: simplicity / complexity Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-31 08:34 +0200

csiph-web