04:10 <josuah> Discussion about how to reduce LiteX maintenance efforts: https://github.com/enjoy-digital/litex/issues/1765

16:50 <_florent_> Hi josuah, thanks for the issue. The catch is mostly that you need to see the pattern a few times before being able to simplify/merge things. Linux/Zephyr project are a bit experimental and features introduced for them have been progressively integrated in LiteX/LiteX-Boards. The current goal for now is to continue this, and make these projects only rely on LiteX/LiteX-Boards only through commands and build exports. The add_xy methods of

16:50 <_florent_> SoC are a first simplification steps and we first need to continue/cleanup this before going changes similar to what you describe in the issue.

16:51 <_florent_> We were discussing a few simplifications with @trabucayre today and will try to allocate some time soon to do them, to allow eventually going further in the abstraction where useful.

19:15 <josuah> _florent_: thank you a lot for this valuable synthesis, this was hard to guess for me by just looking at the commits, and I do see some commits related to reduce boilerplate.

19:17 <josuah> My goal is to understand the path LiteX is taking, not introducing my own :)

19:17 <josuah> > will try to allocate some time soon to do them

19:17 <josuah> I hop this is not related to this message I sent. absolutely nothing encountered in LiteX is blocking for me!

19:24 <_florent_> josuah: The path you are describing in the issue is not that far from what I have in mind, just that I first want to do more some others simplifications before, especially on the integration methods, that could handle more than just the logic integration: Generate the more software constants, also handle filling/handling the arguments for the parser, etc... <- That's what we were discussing for the ethernet core for example with @trabucayre

19:24 <_florent_> today before seeing your message.

19:25 <josuah> this comes timely then!

19:26 <josuah> _florent_: may I get any hint of which kind of cleanup would be coming first?

19:28 <_florent_> For ethernet, each target has a few arguments to configure the ethernet link and all these are duplicated between targets. We could have method in LiteX to fill/handle these arguments and just integrate this in the targets.

19:28 <josuah> this would get me an idea of what to spend efforts on, and pick-up the train rather than starting a new one

19:28 <_florent_> This would be a bit similar to what is done for CPU for example, where each CPU is able to provide arguments.

19:29 <_florent_> Once done for ethernet (that has more arguments), we could extend this to other cores.

19:29 <josuah> thank you! this will be good reference material. I guess all I need to do is spot the API changes, and maintain the boards I can with the new ones

19:29 <josuah> for instance `action="store_true"` -> `action=bool_action default=False` :)

19:32 <_florent_> In addition of the add_method arguments, it would also be good to make sure we can have multiple instance of each core and handle it correctly in the BIOS (make sure it only use the first if only supporting one, or let user specify the one to use).

19:32 <_florent_> ex, related issues: https://github.com/enjoy-digital/litex/pull/1641

19:35 <josuah> thank you, yes indeed

19:35 <josuah> the whole organization of the various repos make a lot of sense from this angle: what is there is evolving, not in a final "this is how you should do it" state

19:36 <josuah> and it takes time to migrate and reshape things

19:36 <josuah> and it does not help to bowling-strike a pull-request that changes everything in the middle of it!

19:37 <josuah> I am going to be involved with Zephyr-on-LiteX-VexRiscv somewhat a lot, and I tried to make it similar to Linux-on-LiteX-VexRiscv as a model

19:37 <josuah> https://github.com/litex-hub/zephyr-on-litex-vexriscv/pull/17

19:38 <josuah> If you had different plan for this (or any other pull request really!) feel free to close it, i.e. referring that something else is planned instead so that 3rd-parties reading the discussion can undrstand

19:39 <josuah> thank you a lot for letting me understand the ongoing evolutions!

19:44 <_florent_> the scope of the project is becoming very large (and open source aspect is in fact a bit different than the design I do with it), so often prefer first doing basic implementations and then improve/re-think after having more feedback or a better idea of how to do it.

19:48 <josuah> this feels like a sound approach to implementing things, with feedback loop involving those who will use it in the end... :)

19:48 <josuah> May I quote some extracts of that discussion and close the issue?