Best Linux distro for development?

[Charlie Landau]

CapROS has gathered so much dust that I am essentially rebooting the
project from scratch using saved sources. Previously, my CapROS
development took place on Fedora. Ubuntu seems more popular now. Any
thoughts on the best Linux distribution for hosting CapROS development?

[Valerio Bellizzomi]

Ubuntu is the most used/supported platform for development nowadays.

Some projects I care of use and support only Ubuntu, notably AMD Radeon Open Compute (ROCm).

[Matt Rice]

I would probably go with bootstrapping inside a VM with podman, and in
the VM run a minimal distribution perhaps something like alpine or
fedora-minimal image.
Ubuntu may have a minimal image? I don't know.

I think the key benefit of this is that people can run whatever they
like locally, and still have a reasonably sized install that is kept
in sync for everyone.

Another benefit is that aspects of image generation which require root
still work even if running as a user for everything but writing to the
actual physical device.

I.e. no special permissions needed for loopback devices which can be
handy for building e.g. qemu images and such.

I'm definitely willing to put some time/work towards explaining or
helping to implement it.
I have some scripts for projects that use this kind of a setup that
could be modified or explained but they are fairly ad-hoc for their
purpose.

So if you'd like to discuss this specifically in more depth, you know
how to contact me.
I believe at least both Ubuntu and Fedora both have podman.

> --
> You received this message because you are subscribed to the Google Groups "cap-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/a920241b-d1fb-de39-b892-e99fa995852b%40charlielandau.com.

[Valerio Bellizzomi]

You can install Ubuntu Desktop or (better) Ubuntu Live Server in 20 GB and still have plenty of space for other things.

[Valerio Bellizzomi]

I don't know podman, I use QEMU/KVM and Intel Cloud Hypervisor to manage VMs.

On Tuesday, October 12, 2021 at 5:47:12 AM UTC+2 rat...@gmail.com wrote:

[Matt Rice]

The current fedora-minimal is 122 MB, you certainly need to install
compilers and such on top of it.
20 GB might not be much, but it is IMO way beyond the tools needed for
bootstraping

> To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/eb97205b-ad26-44e4-bd40-3c3346fc54bbn%40googlegroups.com.

[Valerio Bellizzomi]

I have managed to install Ubuntu in 10 GB, but I don't understand why you want a VM. Coyotos and CapROS development have been done in the host in the past, not in a VM.

[Matt Rice]

Because back then I wished it was done in a VM, there were quite a few
people who tried to bootstrap on whatever OS they had installed
already rather than the one which was supported,
and there were problems with the tools not tracking the pace of
development/deprecation which the linux distros keep.
By only supporting building on a VM with a specified image, people can
just run what they want locally, and keep their install updated even
when the install needed to build capros might become outdated.
If it was based on a VM back then we'd also still be able to build it.

On Tue, Oct 12, 2021 at 4:30 AM Valerio Bellizzomi
<vbell...@gmail.com> wrote:
>
> I have managed to install Ubuntu in 10 GB, but I don't understand why you want a VM. Coyotos and CapROS development have been done in the host in the past, not in a VM.
>
>

> --
> You received this message because you are subscribed to the Google Groups "cap-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/6d7811f0-759c-42d2-86ab-b760f127f541n%40googlegroups.com.

[Valerio Bellizzomi]

Then you chose in the following list of linux distributions

https://lwn.net/Distributions/#special

I would chose FossaDog

which is the closest to Ubuntu but with a minimal image of 566MB.

[William ML Leslie]

I have built the cross environment using packages for two different
distributions: debian stable, and guix. I currently do all of my work
using the debian versions, because I really bit off more than I could
chew trying to do it with guix from the start. Eventually it would be
nice to have the cross tools integrated into nix or guix, as this
makes it a lot easier to keep everything up to date, and means that
things will continue to build in the future, as all of the
dependencies are properly declared; but it's not as important yet. It
also makes it easy to separate some of base/ out into different
packages, for example, to use the distribution's existing openssl
build infrastructure.

But right now, I don't think it matters too much. You could declare
how to set up the build environment on your distribution of choice and
get back to the fun part.

--
William Leslie

Q: What is your boss's password?
A: "Authentication", clearly

Notice:
Likely much of this email is, by the nature of copyright, covered
under copyright law. You absolutely MAY reproduce any part of it in
accordance with the copyright law of the nation you are reading this
in. Any attempt to DENY YOU THOSE RIGHTS would be illegal without
prior contractual agreement.

[William ML Leslie]

On Tue, 12 Oct 2021 at 14:47, Matt Rice <rat...@gmail.com> wrote:
>
> Another benefit is that aspects of image generation which require root
> still work even if running as a user for everything but writing to the
> actual physical device.
>
> I.e. no special permissions needed for loopback devices which can be
> handy for building e.g. qemu images and such.
>

+1. I haven't added anything for this to the Coyotos build, but I did
a review of other operating systems to figure out what they did here,
and it is almost universally "use PAM or sudo to get root" or "build
the image from within a VM", neither of which are very nice
conceptually, but it's important that you have something to do this.
I quite enjoy watching how quickly Andreas Kling's SerenityOS builds
an image and runs using this technique.

Anttii Kanttee (of rumpkernel fame) has a package called fsutils which
can operate on file systems embedded in disk images; I didn't see an
easy way to install and configure grub using it, but I have it noted
down as an avenue to explore.

So far, I've been testing by passing qemu the -kernel parameter and
the output of coymerge.

[Matt Rice]

On Tue, Oct 12, 2021 at 5:42 AM William ML Leslie
<william.l...@gmail.com> wrote:
>
> On Tue, 12 Oct 2021 at 14:47, Matt Rice <rat...@gmail.com> wrote:
> >
> > Another benefit is that aspects of image generation which require root
> > still work even if running as a user for everything but writing to the
> > actual physical device.
> >
> > I.e. no special permissions needed for loopback devices which can be
> > handy for building e.g. qemu images and such.
> >
>
> +1. I haven't added anything for this to the Coyotos build, but I did
> a review of other operating systems to figure out what they did here,
> and it is almost universally "use PAM or sudo to get root" or "build
> the image from within a VM", neither of which are very nice
> conceptually, but it's important that you have something to do this.
> I quite enjoy watching how quickly Andreas Kling's SerenityOS builds
> an image and runs using this technique.
>
> Anttii Kanttee (of rumpkernel fame) has a package called fsutils which
> can operate on file systems embedded in disk images; I didn't see an
> easy way to install and configure grub using it, but I have it noted
> down as an avenue to explore.
>
> So far, I've been testing by passing qemu the -kernel parameter and
> the output of coymerge.
>

I think I also might be missing some context here:
As soon as you start running on a device like raspberry Pi, with its
firmware, and the firmware requirements
you're going to need to build dos partitions and the like to put the
firmware in where the Pi expects it and that sort of stuff
(details fuzzy though). IIRC capros didn't have this requirement, but
wasn't ported to devices which behaved as such

[Valerio Bellizzomi]

Alternatively I would consider developing an ad-hoc operating system for development using https://t2sde.org/ which seems better inline with CapROS development purpose.

[William ML Leslie]

On Tue, 12 Oct 2021 at 21:30, Valerio Bellizzomi <vbell...@gmail.com> wrote:
>
> Alternatively I would consider developing an ad-hoc operating system for development using https://t2sde.org/ which seems better inline with CapROS development purpose.
>

Good one, SEL.

T2SDE is highly flexible, and not only does Rene port it to a lot of
architectures (many of which he has actual hardware for), but he has
spoken of his intentions to write his own microkernel OS.

[Valerio Bellizzomi]

Yes! from the T2SDE site: Currently the Linux kernel is usually used, but we also consider to port T2 to support compiling home-brew open source package add-ons on macOS, other BSDs, classic Unix systems (Irix, ...) or support bootstrapping alternative micro kernel systems (like a L4 variant or Fuchsia). Similarly building Haiku, Android, Minix, Hurd, Open (or Pure) Darwin, Haiku and OpenBSD.

[Charlie Landau]

On 10/11/21 9:36 PM, Matt Rice wrote:
> If it was based on a VM back then we'd also still be able to build it.

I still have the Fedora version 13 I used a decade ago, and it does not
work, because Source Forge does not accept the weak encryption that it
uses. This system is on hardware, but presumably would have the same
outcome on a VM.

I see your point about the value of a VM, but I don't want to be in the
business of developing a development system for developing CapROS. I
don't need it because I don't use this Linux system for anything else.
IIUC, anyone who does need it can create a development system in a VM to
serve their needs, and is free to share their work.

[Valerio Bellizzomi]

I will put some effort in developing that development system, I only need to know the full CapROS development tool-chain.

[Matt Rice]

Understandable, Kind of why I like the fedora-minimal based VM because
the base system is maintained elsewhere,
and it maintains a familiarity with a system you could just install
and run directly...

Anyhow I'm excited capros has resumed development whatever you do end
up going with, and look forward to
getting some of my old branches into some reasonable shape in the future.

[Jonathan S. Shapiro]

On Sun, Oct 17, 2021 at 6:25 PM Charlie Landau <cha...@charlielandau.com> wrote:

On 10/11/21 9:36 PM, Matt Rice wrote:
I see your point about the value of a VM, but I don't want to be in the
business of developing a development system for developing CapROS. I
don't need it because I don't use this Linux system for anything else. 

Actually, you might find it helpful. One of the big uses of the VM for us was debugging. In most of the VMs there is an option somewhere that lets you connect GDB to it and do kernel debugging. 

I mostly stopped doing that when our attention switched to Coldfire for Coyotos, because I had pretty good in circuit debuggers for this boards. But for x86 it was a big help. 

JonathAn

[Charlie Landau]

I believe Matt was talking about a VM for the development Linux system. It appears you are advocating a VM for the CapROS system. The latter does sound very useful.

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAAP%3D3QNcQfi9ivXFg7nMv5inqsZY1-K6c5r2QGQt%2B8nyVEwmVQ%40mail.gmail.com.

[Jonathan S. Shapiro]

Yes. Personally, I think doing the target mods for current version of GCC/LD is probably easier than maintaining a separate VM for build. Would also let windows victims… err, umm, users… do development under Ubuntu on WSL2.  Which, incidentally, might be a reason to choose Ubuntu.

The in-circuit emulator approach for Coldfire and ARM is hard to beat, and networked ICE decides aren’t expensive these days. For x86, I no longer remember clearly, but I think we mostly used qemu. Thankfully, we didn’t actually need a kernel mode debugger on x86 much, partly because we had already done so on Coldfire. 

Jonathan

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/e8d079db-8aa0-d630-ab04-7e8f527a02d8%40charlielandau.com.

[William ML Leslie]

On Fri, 22 Oct 2021 at 17:06, Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

Yes. Personally, I think doing the target mods for current version of GCC/LD is probably easier than maintaining a separate VM for build. Would also let windows victims… err, umm, users… do development under Ubuntu on WSL2.  Which, incidentally, might be a reason to choose Ubuntu.

The in-circuit emulator approach for Coldfire and ARM is hard to beat, and networked ICE decides aren’t expensive these days. For x86, I no longer remember clearly, but I think we mostly used qemu. Thankfully, we didn’t actually need a kernel mode debugger on x86 much, partly because we had already done so on Coldfire. 

FWIW I have really appreciated the support for kernel debugging in QEMU you added to the Coyotos build.  I recently had a nightmare bug where I ended up filling up the transmap.  I don't know how I'd have figured that out otherwise.

OTOH, the worst thing about QEMU is needing to support things I'll never need real hardware for.  I'd love to ignore VBE and VESA and just implement accelerated graphics, to ignore upnp PCI configuration and just implement MCFG, and to rely on the fact that ACPI works sensibly, but QEMU implements a rather old system.

[Venkatesh Srinivas]

On Fri, Oct 22, 2021 at 12:40 AM William ML Leslie <william.l...@gmail.com> wrote:

On Fri, 22 Oct 2021 at 17:06, Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

Yes. Personally, I think doing the target mods for current version of GCC/LD is probably easier than maintaining a separate VM for build. Would also let windows victims… err, umm, users… do development under Ubuntu on WSL2.  Which, incidentally, might be a reason to choose Ubuntu.

The in-circuit emulator approach for Coldfire and ARM is hard to beat, and networked ICE decides aren’t expensive these days. For x86, I no longer remember clearly, but I think we mostly used qemu. Thankfully, we didn’t actually need a kernel mode debugger on x86 much, partly because we had already done so on Coldfire. 

FWIW I have really appreciated the support for kernel debugging in QEMU you added to the Coyotos build.  I recently had a nightmare bug where I ended up filling up the transmap.  I don't know how I'd have figured that out otherwise.

OTOH, the worst thing about QEMU is needing to support things I'll never need real hardware for.  I'd love to ignore VBE and VESA and just implement accelerated graphics, to ignore upnp PCI configuration and just implement MCFG, and to rely on the fact that ACPI works sensibly, but QEMU implements a rather old system.

qemu can emulate a newer chipset/system (q35) than its original i440; this includes MCFG support and even a non-PASID virtual IOMMU.

hth,

-- vs;

[Jonathan S. Shapiro]

Uh… hold up. It should not be *possible* to fill up the transmap. Life of transmap entries is one system call. Total number of transiently mapped pages in worst case syd all should not and must not exceed transmap capacity.

Jonathan

On Fri, Oct 22, 2021 at 12:40 AM William ML Leslie <william.l...@gmail.com> wrote:

--

You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAHgd1hHoL4q-fPk2Sg3x5pAa_Dd94Dw7vt8MGMRjM%3DhpdAbB3A%40mail.gmail.com.

[Valerio Bellizzomi]

I have never used stackoverflow before, but I find it has some questions resolved:

https://stackoverflow.com/questions/11408041/how-to-debug-the-linux-kernel-with-gdb-and-qemu

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAAP%3D3QNVoZQ58OhMEnUFx12pO-ucqzZ%2B-7yXBwVi0EfWjqkC4w%40mail.gmail.com.

[William ML Leslie]

Thank you, I've just started Coyotos on q35 and will be able to make progress on carving up the PCI space into delegatable chunks!  Still no luck with KVM, but at least virtio GPU works.

--

[William ML Leslie]

On Sat, 23 Oct 2021 at 13:26, Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

Uh… hold up. It should not be *possible* to fill up the transmap. Life of transmap entries is one system call. Total number of transiently mapped pages in worst case syd all should not and must not exceed transmap capacity.

Good, I assumed that was supposed to be the case, but nothing was explicitly clearing them.

I found a bunch of places that don't remove entries from the transmap when done with them; preparing cappages in the receive phase and preparing cappages during module load.  Rather than track down and fix all of these, I just made sure the transmap was flushed on sched_abandon_transaction(), and figured I'd ask you about it later.

I just noticed this commit introduces a call to a function I haven't committed and should remove (relevant to the current discussion about enabling CI builds in gitlab), but see kern_Sched here:

https://gitlab.com/william-ml-leslie/coyotos/-/commit/45cd190bbc9113610c6c3dfa3174dbf345d5eccd

I should define these zeros in a header as the size of the transmap can vary by architecture, but this just got me to a point where I could make progress on something more fun.

what I was doing - indexing GPTs and fabricating unallocated physical address space, mostly:

https://gitlab.com/william-ml-leslie/coyotos/-/commit/33c759044885526e22941b79b621c332ab71de3e#31b4944fc75a67eaebac654a6f4203bf9d128986_0_93