kworkflow integration

[superm1]

Hi!

Thanks for sharing this collection of scripts and extensions. I have been playing with them and really like what I've seen so far. One thing I wanted to ask about though; are you aware of the kworkflow project? In some ways it overlaps with some of your build scripts, and in other ways it is complimentary.

I was wondering if there is any opportunity for synergy at least for build system and deployment.

[FlorentRevest]

Hi!

Hi!

Thanks for sharing this collection of scripts and extensions. I have been playing with them and really like what I've seen so far.

Glad you like it!

One thing I wanted to ask about though; are you aware of the kworkflow project? In some ways it overlaps with some of your build scripts, and in other ways it is complimentary.

I wasn't aware of that project, thanks for sharing. :)

I was wondering if there is any opportunity for synergy at least for build system and deployment.

I suppose there could be some benefits, especially for people doing embedded development as I see kw helps with deploying the kernel to a RPi target for example.

I haven't really looked much into it but it looks like a lot of the value they offer in a terminal (like wrappers for get_maintainers, checkpatch, send-email, mailing list exploration etc...) is something this setup offers in a UI. I suppose that's a matter of preferences. For the rest (build/VM) I like that the current tasks.sh is fairly transparent and easy to modify locally, but maybe I say that because I wrote it and am familiar with it :) I haven't actually looked at kw'd codebase and don't know if it makes things easier.

If anyone ever wants to look into what it would look like to modify this setup to use kw, I'm interested to have a look at the resulting setup but I don't think I'll actively look into switching to kw myself for now.

Have a good day!

[matttbe]

Hi!

Similarly, there is the virtme-ng project :)

Personally, I'm using a docker image gathering some dependences, and including some scripts that can build a kernel and run various MPTCP tests. When a contributor wanted to use VSCode, I provided some files, like a local-*.sh file to override the behaviour of local.sh, and some extra settings.

We could have something similar for virtme-ng, and kw as Florent suggested. Or something directly included in local.sh, and just having to set one option to use one "tool" or another.

[superm1]

Yeah you're right some of the stuff in kw is a terminal equivalent of what UI extensions do here.

The biggest perk to me is kw bd. This will build the kernel and then deploy it using kw on another SUT. There are more args that could be used for picking a host etc. I personally am using it to send kernels to a variety of hosts. It then handles the differences of different bootloaders tools and distros etc.

I notice that building with kw vs the keyboard combination in vscode requires a full build in vscode and then a full build in kw.

I guess what would make sense to me is have the build script call out to kw if present, but I suspect it's not that simple because of needing to generate compile commands for clangd.

[superm1]

Cc @rodrigosiqueira