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.
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/e8d079db-8aa0-d630-ab04-7e8f527a02d8%40charlielandau.com.
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.
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.
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAAP%3D3QNVoZQ58OhMEnUFx12pO-ucqzZ%2B-7yXBwVi0EfWjqkC4w%40mail.gmail.com.
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.