On Thu, 20 Apr 2023, Mark Cave-Ayland wrote:
On 01/04/2023 12:36, BALATON Zoltan wrote:
On Fri, 24 Mar 2023, Segher Boessenkool wrote:
On Fri, Mar 24, 2023 at 12:20:01AM +0100, BALATON Zoltan wrote:
If there were already a significant amount of Forth code in the PCI bindings then a Forth solution such as yours would be a better approach, however for now my preference would be to use the approach from my original series since the glue code provides a much more intuitive solution given that the PCI bindings are written in C.
I disagree but since nobody else here seems to have an opinion or care about OpenBIOS in the end you do what you want. Forth and C are mixed in OpenBIOS also in pci.c already so using that to make pci.c less cluttered and easier to read by adding some very simple forth that's also easily understandable would make this easier to maintain but if this did not convince you I can't do much else.
I care. I find doing as much as possible in C incredibly clumsy, just like you it seems -- you are not alone :-)
But, I don't maintain this code. Whoever does the work gets to make the decisions. I just throw nuts from the peanut gallery sometimes.
I would do some work but apparently I'm not allowed to... Another point is that Mark's proposed changes are something he would never merge if I submitted it so he should be equally critical with his own work and make a cleaner change.
This is just getting ridiculous now.
What I proposed as an alternative does the same simpler and we have at least 1 and a half votes for it against the 1 vote for Mark's series but if it's still not good enough then do it in C but in a cleaner way, without patching the Forth-C bridge which should also be possible. But I really don't see what would be the advantage of keeping these methods in C which just makes pci.c more cluttered and harder to read and maintain.
I've already explained in my previous response why the approach you are proposing is not simpler or cleaner. Certainly for historical reasons OpenBIOS has a large C component, however if you are interested in spending time converting drivers from C to Forth then feel free to post a proposal to the list.
Why should I waste my time if the response will just be that you don't like it and will ignore it? That's why I've asked in advance if you would accept such change and only did minimal version first before spending any more time with it, as I'd only do that if the time will not be wasted. Otherwise I have better things to do in that time so I'll just refrain from contributing to OpenBIOS at all instead. But that leaves noone else besides you to do the things needed to:
- allow running FCode ROMs which is needed to pass through GPUs to MacOS - Fix the mac99 emulation so it works with more guests - Fix the G5 mac99 emulation so it can boot anything else than Linux
My patches aimed to solve the above step by step but you don't even let me do a small step without either doing it all at once or following your ideas only.
I still think it is a problem that the way you're holding hostage OpenBIOS development and Mac emulation in QEMU prevents any progress with these because you don't have time to work on it but also don't let others to work on it. This isn't wnat a maintainer should do but you don't seem to understand that and when I try to explain it to you you take it personal and get offended. This probably scares away potential contributors and I remember at least one case where somebody tried to submit a change to QEMU mos6522 model to fix an issue but you did the same to him that you usually do with my chnages (so I know it's not personal) and that change was not accepteed after ending up arguing about it at the end and the problem may still not be fixed. I don't know the reasons why you're doing this. I guess sometimes maybe you have local changes you don't want to rebase or have different ideas on how a problem should be solved or you don't trust anybody's judgement but yours but as a maintainer you should impartially consider if a proposed change is making progress and does not break or make existing code worse and not force your ideas on everybody. Also demanding extensive clean ups to be done by a contributor just to accept a small change that you regularly do (and tha above request is going that direction again) is unreasonable and jusd holds back any progress. This thread is now a good summary of all of this again.
I agree this is getting ridiculous so I just stop trying to work with you until you change your ways or this is resolved somehow. If you can't help the project to progress, you could consider stepping down as a maintainer. You could and should stay and provide your expertise for review and testing but you should not be the person who alone decides what change can be accepted. So I think if there was somebody more impartial and less strict as a maintainer and your patches were judged under the same terms as any other contributor that would help the project in general.
You don't have to reply, I don't think there's any point to discuss this further. I've tried to explain this several times and if you still don't think I have a point then there isn't much to add to that. I'd like to say again that I have nothing against you personally and sorry again if I've offended you in the past. My intention is not to fight or offend you, just to explain the above which might be difficult when I'm trying to make some progress and constantly getting thrown back by this even in areas unrelated to OpenBIOS or mac99 like the vt82c686 changes the last time. This makes it more difficult to work on these than it should be and have fun with it.
In case you decide to change your mind or somebody else can step in as a maintainer to more sensibly manage this project, my ideas for improvements that I'd consider to elaborate on would be:
- Finish this pci method simplification by moving some more methods to Forth
- Implement missing register access words to get FCode ROMs working
- Get rid of fw_cfg and hard coded machine parameters and pass an FDT from QEMU instead as done my spapr and SLOF or pegasos2 and VOF; I've already ported SLOF's FDT parser to OpenBIOS but because it's impossible to convince you I did not finish this. This would simplify arch/ppc/qemu a lot by removing hard coded device trees and lift the need to change OpenBIOS together with QEMU as then device tree changes could be made in QEMU alone. For example fixing G5 mac99 can be possible without any change in OpenBIOS and thus lessen maintenance need for OpenBIOS. (Related to this is passing VGA driver through ROM to lessen dependency on fw_cfg as a first step and move towards real FCode ROM as it works on real hardware so instead of hacks do what real hardware does. But that's another change that met resistence from you.)
I could try to explain the ideas in more detail but if your first reaction is just that you don't think this can be a good solution then even spending time with detailing the ideas is wasted time so I'll just stop now.
Regards, BALATON Zoltan