Moody, first of all, I apologize. To be clear, I would not wamt to claim anyone else's work as mine, especially not right in front of them. Quite the opposite; I credit others on a regular basis. All I'm trying here is to help bring things further. I do recall that you had mentioned a patch for something on IRC, but I had forgotten about it and not taken a closer look, focusing on the fiddling we did that evening; sorry if it was exactly this for r2. I have no logs, otherwise I'd check. The changes I made were my own, in the context of yesterday's exchange with pancake, https://mastodon.social/@CyReVolt/114625651395826989 - being trivial enough that you probably did very much the same, though I am not sure whether what I did there was correct or complete. I just took a kernel that Shawn had built and it seemed to work fine. If I had had your changes, I would not have done this. And I wouldn't have spent a whole week creating another tool, which is obviously 100x the effort. I didn't even know what ELF really looks like until now. While it's not ideal either, it makes it possible to see the symbols in gdb now, at least. I started with x86 because I had a kernel from Ron in both a.out and ELF that I took as a fixture, and just added 64-bit RISC-V ELF support today, which should get some cleanups because it got pretty ugly.
Regarding LinuxBoot, stories like yours on the Talos system are what I see as input for improvement. Yes, I agree, the current state is not great, and a lot of work is necessary to make it smooth. And I am well aware how complex today's SoCs are, having worked with so many of them now. I do not expect the effort to port any system to them to be easy, just doable. I also agree that "do this" is a horrible sentiment vs "how do I" / "here is what I did". That is not what I meant to say here. I hope that the tools I'm creating show that my intention is to do work myself. And to be fair, I think any software that comes with source code invites to be understood, unless the authors intend to make it obscure, that is. On Thu, Jun 5, 2025 at 6:02 PM Jacob Moody <[email protected]> wrote: > Responses in-line. > > On 6/5/25 07:42, Daniel Maslowski via 9fans wrote: > > > > Operating systems have made their journeys as well. Be it macOS, Windows > or Ubuntu as they are today having iterated over many concepts in terms of > widgets and interaction design, and BeOS famously having experimented a lot > in the realm of multimedia. The respin Haiku is close to a stable version > 1.0. Let me cite from haiku-os.org <http://haiku-os.org>: > > "Haiku is an open-source operating system that specifically targets > personal computing. Inspired by the BeOS, Haiku is fast, simple to use, > easy to learn and yet very powerful." > > > > And here goes the idea of "simplicity": It isn't simple nor easy to > *develop* those things, but the primitives are simple. On the other hand, > it is the developers' burden to deliver simplicity to the end user. Let's > keep that in mind: Missing out on a decent user experience creates tons of > complexity on the side of the user. Like, say, having tons of abbreviations > and little use of colors and such in 2025, in which we have 8k screens, > terabytes of storage, gigabytes of RAM, touch input, and tons > > of gadgets in everyone's hands - that can change. > > I personally like that while Plan 9 presents a very cohesive environment, > it never really papers over technical issues. Plan 9 often chooses simpler > implementations and exposing the reality to the user instead of attempting > to > hide the real world complexities of the problem. > > Plan 9 is a system that invites you to understand your computer. > In doing so, a lot of code can be straight forward. > Plan 9 is "simple" in the sense that most implementations are simple. > > If people want a hand-holding user experience I suggest sticking to a mac. > > > > > Part2: Where do I want to go with Plan 9? > > > > The question now is what I am doing here. It's simple (pun intended). > > I read that Plan 9 ought to be simple, and I want to see that work out. > So I look at it from a bunch of angles and see that it is quite different > from my expectation of simplicity. Though there is potential to get > somewhere. I think that would fit the spirit of the Bell Labs folks who > started it all. > > > > A lightweight system that can run on those many gadgets we now have? > Awesome, let's do that! I see a ton of potential in being able to, say, > drawterm / cpu into the tablet I hung up in my kitchen. The stock Android > is long defunct. Or the wristband I am wearing. Tiny SBCs that I can plug > into my laptop via USB. The small https://racklet.io/ <https://racklet.io/> > cluster that I am helping to build. Whatever wicked still may come! > > 9front is less of a "let's do X or Y" and a "this bothers me so I'll put > in the work". > If people want change they send the patches. I dislike this "this work > should be done" > talk instead of a "How do I start doing this work? Here I have a sketch of > this idea but > I'm having issues". > > The biggest issue with supporting whatever tablet or whatever you have > hanging in your > kitchen is the lack of documentation and the crazy interfaces that are > required to make > it work sensibly. Nice to have? Sure why not. Easy to do? Likely no. > > > > > So I have been working on hardware platform initialization firmware, > this project called oreboot (yes, without C), and boot loaders, that is, > LinuxBoot, and next, I want to bring up Plan 9. I mainly work on RISC-V > based platforms, now also a bit of Arm, and little x86. > > > > With the experience in doing this, I paired up with Shawn to hack on > Moody's WIP port of 9front for RISC-V in QEMU. And I checked with Ron and > Ori if we can LinuxBoot into Plan 9 / 9front on x86 (might work again with > Ron's fix; I gotta retry!). > > What do you mean get "LinuxBoot into plan 9 / 9front", > if you mean getting a linux kernel in as a bootloader that won't happen. > > If you mean to add support for booting 9front kernel using linuxboot, > our amd64 kernel already supports multiboot. > > I did this dance of getting a 9front kernel booting with kexec (ala > linuxboot), > for the power64 talos and the interface sucked. I'd rather not propagate > this to other > systems. If I recall correctly I had to make up some bullshit addresses in > the ELF > header because the linux kernel had a validity check for a value it never > used. > LinuxBoot is designed to do just that, boot linux. > > > > > Over the last few days, I created a tool to convert Plan 9 a.out files > to ELF (amd64 so far, RISC-V WIP), and I added Plan 9 a.out support for > RISC-V to radare2. Those tools should help with the endeavor. > > Converting Plan 9 a.outs to ELFs is going to be bound with issues if > you're doing > it after the fact. Plan 9 code is not position independent and we do not > provide > the structure required for relocation. > > Now for the real reason I sent this email, you didn't add RISC-V plan 9 > a.out support to radare2. > You took someone else's patch that I had generously shared with you while > you were poking at the RISC-V kernel > and upstreamed it behind our backs claiming it as your own. > > Your PR(https://github.com/radareorg/radare2/pull/24261) mentions nowhere > that this was someone else's code. > > To be entirely honest I find this behavior shocking and troubling, and now > I feel responsible for being the > one to send it over to you. I'm sorry but I will not be interested in > continuing to share the ongoing work > of the RISC-V port if this is the respect we have for each others work. > ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tf84d656c78bbda91-M0c3549ec212c2c8b45755874 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
