Hrm, not sure how to interpret that test failure- I actually can't even getmage -v test to run locally.

Any pointers@icexin ?

It seems that a driver is initialized twice, causing the io address to be remapped. This may be the reason. I'm not too sure. You can debug in this direction.

Nice one, thanks!

Ah, yeah- I see now. Because the repo containseggos.go, which already contains all the init stuff, when we then build the test unikernel we end up initialising stuff twice- once ineggos.go, and once inzz_load_eggos.go.

I need to think about this more. I could removeeggos.go and useegg generate to createzz_load_eggos.go instead- this keeps backwards compatibility, but might be ugly.

Thanks@jspc, I will find time to review the code

Cheers@icexin - no rush, enjoy your weekend!

Hi,@jspc:

This PR addresses the ability to manually configure driver modules. The solution is to generate a go file to decide which modules to load and in what order. Here are some of my thoughts on this PR:

1. Users may need a deep understanding of eggos to decide which modules to keep and which modules to delete. For example, thepci module needs be initialized before thee1000 module. Of course eggos is in the early stages and it's fine to do so.
2. The default template code is a string in the go file, which is slightly less maintainable.

In the long run, a module manager may be needed to provide module initialization, dependency management and configuration management. But it is out of scope of this PR.

Any thought？

BTW,mage qemu will fail becauseapp/kmain is still referencing_ "github.com/icexin/eggos". I think if the initialization code is managed byegg generate, theeggos.go file in the root directory may not need to keep.

As there are still some design considerations (e.g.#99 (comment)), I'd prefer to keep discussing various options before merging this PR (or a new PR with an alternative approach).

We can consider what potential solutions there may be for using/initializing only parts of eggos, and try to evaluate pros/cons for those different approaches. Perhaps for this discussion, it's better to open an issue where we can keep such discussions concentrated.

For instance, it may be possible to envision usingeggos as a library which is imported by the user's unikernel. Such an approach may either use default configurations (e.g. byimport _ "github.com/icexin/eggos"), or configure different aspects, such as what drivers to use.

The two original methods of using eggos in a unikernel work exactly the same as before. Everything is completely 100% backwars compatible.

1. Loadingimport _ "github.com/icexin/eggos" still works the same as before; that module has the same code as before, it's just the filename that changes
2. Runningegg {build|pack|etc} does the same thing- if the generated file does not exist thenegg will template it and build it using the currentoverlay.json method.

The major change this PR introduces is to make that generated file contain variousdriver.Init() calls directly, rather than importing eggos.

The reason it does this is to allow things like loglevels to be set as early as possible without having to hack around the module loader.

If the additionalegg generate command is confusing matters, by making it seem like the workflow must contain that step, then we can change the documentation.

Being able to adjust what boots (I, for instance, don't need to configure mice and keyboard support, and I'm building for a machine with more than 8 cores) was useful for me, and will unstick us later when we have more driver support, but if it's premature then that's cool too.

@icexin - good point re: the templated string. I pretty much followed what was there before. I started writing a tool to generate that file based on inputs, but before I knew it I was nearly writingmake menuconfig and so I went back to a string.