Discussion: New package for flags parsing.

[ChriMarMe]

I suggest Kong as a new commandline parser.

It will bring sophisticated commandline parsing and gives more future prove capabilities when extending gokvm.

[bobuhiro11]

Thanks for the suggestion. But as a project policy I would like to develop only with the standard library. I believe that is sufficient in many cases, but are there cases where that is not possible?

[ChriMarMe]

I can certainly think about extending gokvm to a more complex VMM with load/store/start/stop/resume functionality. Decoupling the execution of the binary and running a VM which needs to be controlled via command execution. (see #150#issuecomment-1685713411)

Have a look at the Draft PR #152

On a more general note: What do you think about working out a project plan for desired functionalities and capabilities?

[bobuhiro11]

I understand the intent to support operations like load/store/start/resume in addition to the existing VM booting. Interesting 👍 I also understand the need for subcommand. Well, my suggestion is simply to prioritize the standard library. For example, I think we can achieve subcommands by doing the following:

https://gobyexample.com/command-line-subcommands

On a more general note: What do you think about working out a project plan for desired functionalities and capabilities?

I would like to implement only essential aspects of virtualization in gokvm. For example, support for new boot protocols and load/store/start/resume functionality would be appropriate for gokvm. On the other hand, I don't want to include things that should be done by higher level services or orchestrators (OpenStack, Libvirt, etc.) such as listing or scheduling of multiple VMs.

[ChriMarMe]

After playing around with FlagSets to implement sub-commands I don't see a nice way of using FalgSets without mimicing functionality of kong in most ways. The result is sub-commands with headaches and a lot of infra to implement just to support basic functionality without the benefits of kong. I dont see the point in implementing a new cmdline parser for the sake of doing it, when my priorities are in extending VM capabilities. FlagSets require me to handle too much stuff already solved in a better way by libs like kong.

Sorry to say: but in regards of commandline parsing I disagree with the desire to only use std libs. I dont want to invent the wheel again if we have a properly working one already.

[bobuhiro11]

Yes, I know that kong and a few others are really great cmdline parsers. And I also know that you want to spend your time on more essential work (e.g. PVH Boot), not cmdline parser. Sorry to put you through my selfishness. So, as a suggestion, how about using kong to implement subcommand for the time being, and then I will try the standard library?

Sorry to say: but in regards of commandline parsing I disagree with the desire to only use std libs. I dont want to invent the wheel again if we have a properly working one already.

I am focusing on using only the standard library since this project itself is a redevelopment of the wheel.

[ChriMarMe]

No need for excuses! I understand the desire to use std lib to keep robustness high.

This project may be a reinvention of the wheel but the only one which can be integrated into u-root and execute a VM from firmware :) So for me gokvm is not just pure interest.

[bobuhiro11]

Oh, so there are actually beneficial use cases. Thanks for letting me know. I'm glad to hear it!

By the way, I agree with the introduction of subcommands by kong so far, so I guess the only thing left is implementation. This Issue is closed.