Yes, this is smarter.

Approved.

For this change you will want to tag it with:

Reviewed by: fernape
Approved by: fernape (ports)
Approved by: mhorne (mentor)

From where are you getting your line-wrap rules? style.mdoc(5) is silent on this, but the existing tendency is to wrap single sentences at 80 characters (the source code limit declared by style(9)), and of course follow the one-line-per-sentence rule (although some man pages break lines semantically).

We can quickly enter bikeshed territory debating something like this, but I must ask, is this workflow real or imagined?

Approved.

In D48508#1106915, @ziaee wrote:

That's so exciting! Unfortunately, I have already failed at the very first step, I didn't fix the approved trailed in the commit log.

In D48488#1106326, @imp wrote:

This has been unused since

commit f7b776917236d24a4ac7aaa19b3595abdd8411f9
Author: Doug Rabson <dfr@FreeBSD.org>
Date:   Sat Apr 8 14:17:18 2000 +0000

    * Factor out the object system from new-bus so that it can be used by
      non-device code.
    * Re-implement the method dispatch to improve efficiency. The new system
      takes about 40ns for a method dispatch on a 300Mhz PII which is only
      10ns slower than a direct function call on the same hardware.

    This changes the new-bus ABI slightly so make sure you re-compile any
    driver modules which you use.

I don't think we're being too hasty removing it. It used to be used a pointer to the compiled ops (method) table.

Merge the status and enable-method checks into a helper function.

Approved.

Approved.

LGTM, but for any content changes (not formatting only), you need to bump .Dd.

This is the general rule/convention for utility option lists? If so that is the point most worth noting in the commit message.

Approved.

Approved.

Approved.

The title and description don't match the code change!

This is not a full review, just a couple of quick notes.

Add missing whitespace.

Add "enable-methods" property to the check. According to my reading of the
spec, and our code, this should satisfy all cases.

Use ofw_bus_status_okay().

Remove warning message.

In D48122#1097216, @imp wrote:

Do we need to update arch(7)?

Thanks. I am swamped with reviews right now, but I will try to say something on the other open ones before the end of the year.

Approved. Sorry, one final note is that if Sergio doesn't speak on this change, it is just:

Approved by: mhorne (mentor)

Thanks much. I will pull this change today.

In D48058#1096833, @markj wrote:

In D48058#1096826, @mhorne wrote:

I have no objection to the current revision, although we can say a few things about how the code may look/change in the future.

Obviously, the feature-to-ISA-string code will continue to expand/balloon, as we will want to advertise the availability of the many unprivileged ISA extensions to the guest as well.

The problem is that we have no mechanism for reporting extension presence from the kernel to userspace, therefore you are using vm_cap_type here. I am working on something "official" for this, most likely it will be a sysarch exporting a bitmap, with bit definitions compatible to what can be found in Linux. Therefore one call can obtain the full set of supported extensions (sanitized), and we will be able to use this in bhyve to construct the ISA string for the guest.

So I don't think we will need to rely on vm_cap_type in the long run. We also don't need to be precious about the ABI, given the experimental state of RISC-V vmm and hypervisor hardware, and since I intend for this extension reporting stuff to be resolved before the release of 15.0. So this VM_CAP_SSTC can easily be removed later.

I'll just comment that we will probably still want some kind of indirection through vmm to fetch the set of supported extensions, as vmm might want to "mask" some extensions, e.g., because they require some specific support in the hypervisor.

I have no objection to the current revision, although we can say a few things about how the code may look/change in the future.

In D48086#1096806, @concussious.bugzilla_runbox.com wrote:

Thank you. How does it work since this is not doc? Since you have a src bit and have approved it, do I commit this? Also, in general, if you have approved it, do I still wait for Sergio? If not, do I put him as implicit or do I omit from the commit message?