On 18/03/2023 21:37, BALATON Zoltan wrote:
This is untested and probably should be marked RFC as it's mainly to show what I was suggesting as an alternative fix for the decode-unit problem discovered by Mark. This could be taken further to adopt the decode-unit and encode-unit words from openfirmware to reduce clutter in pci.c even more which I may attempt if this direction is accepted. My config words patch will also need to be rebased but let this part settle fitst and I can submit the rest as a follow up or a v2 for this series later.
Regards,
BALATON Zoltan (3): pci: Use forth to add trivial open/close methods pci: Add is-pci-bus word to install some methods from forth pci: Fix calling decode-unit without active-package
drivers/pci.c | 78 +++++--------------------------------------------- drivers/pci.fs | 10 +++++++ 2 files changed, 17 insertions(+), 71 deletions(-)
Thanks for posting an RFC for discussion. There are two separate meanings to the word "simplify" in the context of this patch: the first is being concise, in which Forth can often provide a very compact solution as demonstrated in patch 3. The second is being understandable to developers which improves maintainability in the long run.
I think it's easy to argue that patch 3 meets the first criteria, but as mentioned before I'm not particularly keen on this approach because it starts splitting the core PCI methods out of pci.c and into pci.fs whilst mixing languages and runtime/compile time semantics, and also as per my previous comment you'll end up embedding strings of Forth which is really something to be avoided.
I can see how the first couple of patches can appear opaque, but then it's easy to see that they work in the same way as the existing BIND_NODE_METHODS macro. And from a developer perspective this is something that "just works" in that you use the new macro, and you end up with the phandle as a C function parameter.
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.
ATB,
Mark.