Add a config file to bhyve

[allanjude]

Summary

This is an expansion of D2448, but I didn't want to hijack that review

This uses a more detailed config file that exposes more of the options.
This code is not complete yet (bhyveload has not been converted)

A bug fix is pending in upstream libucl to deal with implicit/explicit arrays, that is breaking the ability to have more than 1 disk {}, device {} or network {} block

In the example config, you'll notice that the device stanza is an array, this will be changed to being 2 separate device {} stanzas once the libucl bug fix is imported.

Ideally, Most of the config options will be moved to a default.conf that will be loaded 'under' the user defined config file, using libucl's include mechanism, once it supports lower relative priorities.

[allanjude]

usr.sbin/bhyve/config.c

364

this is for debugging, and wasn't meant to be included

[araujo]

Sorry but where is my copyright at bhyveload.c?
Why not improve the original patch and have discussion there. You just hijacked the patch if you didn't notice.

Not nice do that!!! So, keep the original submission, even if you want change and add your ideas you can use the original review for that.

Bad way to do things in an open source project!

[araujo]

More one point here:
"""A bug fix is pending in upstream libucl to deal with implicit/explicit arrays, that is breaking the ability to have more than 1 disk {}, device {} or network {} block"""

At the patch D2448 we can have multiples disk and network devices.

This is my final point here.

[araujo]

bhyveload.c cannot have your copyright, even myself with the first patch didn't claim any copyright there, and you just copied the code that I made, and add really few lines, to don't say 0.

usage(void)
{

fprintf(stderr,
    "usage: %s [-c <console-device>] [-d <disk-path>] [-e <name=value>]\n"
    "       %*s [-f <config-file> [-h <host-path>] [-m mem-size]\n"
    "       %*s <vmname>\n",
    progname,
    (int)strlen(progname), (int)strlen(progname), "");
exit(1);

}

Sorry, but copyright is when you design and create something, if every small change that we do in the source code give us the rights to claim copyright the source files will be full of it.

Very bad Allan.

[araujo]

to prove that you only copyied the code that I made on bhyveload.c:

if (config.isofile)
                                    error = disk_open(config.isofile);

Shameless. First time that I saw this kind of things on FreeBSD, and I hope will be the last time.

[allanjude]

In D2505#46088, @araujo wrote:

to prove that you only copyied the code that I made on bhyveload.c:

if (config.isofile)
                                    error = disk_open(config.isofile);

Shameless. First time that I saw this kind of things on FreeBSD, and I hope will be the last time.

Sorry, as I mentioned in the submission, I had not got around to converting bhyveload yet. I did not remove your copyright, you never added one.
This patch is based on yours, a checkout of yours, then I spent the entire day working on it.

The reason I did not submit this to your review is that that would require 'commandeering' your review, and I thought that would be rude. I am happy to continue this on your review if that is what you would prefer.

[araujo]

In D2505#46111, @allanjude wrote:

In D2505#46088, @araujo wrote:

to prove that you only copyied the code that I made on bhyveload.c:

if (config.isofile)
                                    error = disk_open(config.isofile);

Shameless. First time that I saw this kind of things on FreeBSD, and I hope will be the last time.

Sorry, as I mentioned in the submission, I had not got around to converting bhyveload yet. I did not remove your copyright, you never added one.

Yes, I didn't add copyright, because copyright should be add when you design our create something, not only when change feel lines.

This patch is based on yours, a checkout of yours, then I spent the entire day working on it.

The reason I did not submit this to your review is that that would require 'commandeering' your review, and I thought that would be rude. I am happy to continue this on your review if that is what you would prefer.

Yes, would be the right thing to do, send your patch to my email, and I update the review that I created, but first I would like to wait the reply of Peter and Neel, as I exchange some emails with them and I'm waiting for their reply.

Hijack is not the way. To revert all this mess: Reopen the first review, close this review D2505, send your patch to me, I will check with Neel and Peter what they have in mind and then keep working on it.

Again, it sounds a closed group, and open source doesn't work in this way.

Best,

[allanjude]

In D2505#46081, @araujo wrote:

More one point here:
"""A bug fix is pending in upstream libucl to deal with implicit/explicit arrays, that is breaking the ability to have more than 1 disk {}, device {} or network {} block"""

At the patch D2448 we can have multiples disk and network devices.

This is my final point here.

The bug in libucl stops you from having multiple elements with the same name. It is supposed to work, and it is a bug that has been fixed upstream (although recently regressed). The fix will get pulled in shortly. In the mean time, the repeated segments much be in an explicit array in the config file.

[araujo]

I'm gonna accept this revision just to after it, close it.

This revision just hijack the patch send at first place at D2448, so the discussion must be there.
If you want update the patch there you are very welcome to do so.

I'm still waiting Peter and Neel, as I have exchanged some emails with them, and they have their own proposal for the configuration file.

All the best.

[araujo]

So, I'm closing this revision in favor of D2448, this revision just hijack the patch and make changes.

Allan, please, use that revision and feel free to send me your changes. I will update without any problem.

Best.