In D12419#391688, @kalle.carlbark_freebsd_kcbark.net wrote:

Hi @araujo, are there plans to move forward with this now that https://reviews.freebsd.org/rS340373 (libcasper: introduce cap_fileargs service) was commited?

Committed at: r340707

In D17874#386140, @alexandru.elisei_gmail.com wrote:

The only test I did for the patch was to compile the source code. When the patch code is stabilized I will try to do a proper test by running a virtual machine with bhyve.

In D2838#385109, @emaste wrote:

still pursuing this change?

Also there are lots of style(9) issues!
@alexandru.elisei_gmail.com could you please first address @rgrimes comment and then we can do the review including the style(9) issues that need to be fixed too?

After reflect a little bit more about what @rgrimes mentioned, how about we do something like this?

In D17848#381508, @rgrimes wrote:

This is good, but it is not clear on *who* can approve as bhyve, in the past that was Peter, is it now jhb & tychon, or anyone who just happens to join the bhyve group, which is not controller.

Sounds reasonable!

ping!

ping!

Committed already: https://svnweb.freebsd.org/changeset/base/340046

LGTM!

Close in favor of: https://reviews.freebsd.org/D17795

Ops, abandoned the wrong review... Sorry!

Address the memset according with the suggestion made by @jhb.

Close in favor of: https://reviews.freebsd.org/D17795

Tag release to 2.0.

In D17759#379608, @jhb wrote:

I agree with @brooks that the current patch is a no-op as it is just re-computing 'strnlen' and then discarding the result.

That said, if you rewrote it to use memset of the static size first the compiler will probably inline the memset with SSE/AVX instructions and be faster than the current code. Something like:

size_t len;

len = strnlen(src, dst_size);
memset(dst, pad, dst_size);
memcpy(dst, src, len);

I would also probably make 'dst_size' a size_t. However, it would also be fine to just drop the current patch as the existing code works.

In D17759#379605, @brooks wrote:

What ever overflow I thought I saw doesn't appear to exist when I read the code now. len is always <= dst_size so the memset is safe.

I don't know what the loop is attempting to do, but all it does is compute i = MIN(strlen(src)+1, dst_size) and then i isn't used.

The only real issue I can see with this code is that pad should probably be an int like c is in memset and that's mostly theoretical.

Hi @imp is there anything pending to commit this patch?

Hi @allanjude is there anything pending to move this patch forward?

Hi @yuripv , is there anything pending for this patch to be committed?

In D2838#378519, @rgrimes wrote:

Proposal: Rename the current bhyvectl code to bhyvedbg, and create a new bhyvectl that has --create, --destory and --list. This could also be the tool to do the bhyvectl --addcpu, --addmemory, --adddisk, etc, etc. This is just a random braincell firing of an idea, anyone and everyone can ignore as they see fit.

In D2838#378512, @rgrimes wrote:

I shall re assert my earlier concern that we want to keep bhyvectl purely as a debugging tool, and not start to clutter it with stuff that is not part of that. Yes, there is the use of --destroy by others, but that is and should be the exception rather than the norm.

s/company/keypads/g

In D2448#378445, @0mp wrote:

Just to be sure: the usage function mentions that the configuration file is in the UCL format but it is not mentioned anywhere in the manual page.

Am I missing something or the format of the configuration file is not yet documented?

Just a hands up, this patch needs the following patches:

Any news about this patch? I need it to be able to finish this review: https://reviews.freebsd.org/D12419

I have spoke with @allanjude about it, we at bhyve group are discussing this topic again and we will become with a new format for the configuration file.
So, I'm commandeer this revision again!

LGTM! I have spoke with Ryan to get a better scenario about this issue and here there is a reference for that: https://redmine.ixsystems.com/issues/25092

Lgtm!

Lgtm

Lgtm!

I have tested it with FreeBSD HEAD as a guest running for couple days.

In D12419#349103, @kalle.carlbark_freebsd_kcbark.net wrote:

Any update on this? I've tried this diff on a recent current but it seems like it doesn't work anymore?

For the bhyveload side, I'm ok with the changes.

In D16945#361590, @kevans wrote:

In D16945#361587, @araujo wrote:

A fast look over bhyveload it looks ok. I suppose you have done tests with these changes on bhyveload.

Indeed- I tested all of the cases listed: legacy setup where it's forthloader with old version string, lua+forth guest with each of the userboots in place as /boot/userboot.so, tolerance for a requested interpreter not existing on the host, and explicitly requesting a loader with -l.

A fast look over bhyveload it looks ok. I suppose you have done tests with these changes on bhyveload.

Personally I'm not a vmrun.sh user, but I have no objection related with this change and I don't see anything harmful.

Some minor style(9), but overall very good. Thank you!