Delete content instead of removing the whole directory

In D54757#1251289, @jrtc27 wrote:

In D54757#1251288, @aokblast wrote:

In D54757#1251272, @jrtc27 wrote:

I don’t understand, other than it sounding like bear is broken

Sorry, the commit message is not clear. I try to explain with more detail. Please tell me if you need anymore information.

When

pwd == $OBJTOP

, and after

run rm -rf "$OBJTOP"

getcwd(3) will return with error since the directory is deleted.

Under this condition:

When shell is executing:

mkdir -p "$OBJTOP"

bear intercepts the libc exec(3) function call and call getcwd in here. As a result, it causes an error.

So... bear makes assumptions that are false and breaks perfectly fine build system code

In D54757#1251272, @jrtc27 wrote:

I don’t understand, other than it sounding like bear is broken

In D54551#1248714, @markj wrote:

Looks ok, but I'd use int in the function signature.

Minor fixes

Remove License message

Move commit back

Move commit back

Seperate differential

Minor fixes

Use x86_msr_op

Simplify dump_sysctl_cb
Add helper functions for single cpu

Thanks! Thought I sucessfully booted up on a AMD64 machine, this patch touches the basic logic of smp so I will think twice before landing it.

In D54466#1244696, @ziaee wrote:

Thanks aokblast!

This belongs in DESCRIPTION section.
The mdoc(7) manual specifies what goes in SYNOPSIS.

Also, each new sentence starts on a new line.

Minor fixes

Trust sc->req in set_epp and add () in KASSERT

Use hwpstate_amd instead of hwpstate
Not short-circuiting for cpu

In D54173#1238612, @unitrunker_unitrunker.net wrote:

Now I have a dilemma.

I can add exclusivity inside libusb20.c or push down one more layer and add this to the backend in libusb20_ugen20.c. To do this in the backend, device_open_t gets a third parameter for the flag. It's a six-for-one, half-dozen-for-the-other kind of decision.

The scope for this change is exclusivity. No plans to touch existing enumeration behavior.

I'll have to create a separate review. Everything will link back to the same bug.

Minor fixes

Haven't test it. But I have a comment. It would be great if we can solve multiple device issue like this.

Thanks for the comments! Hope it looks better now.

1. Fix indentation
2. Remove hwpstate_cppc_settings structure
3. Update sc->req in all cpu cores
4. Fix sc->req style nits
5. Consistent CAPS and REQUESTS macro

In D49587#1235795, @olce wrote:

In D49587#1235740, @aokblast wrote:

@olce I think exposing the epp setting interface only in only cpu0 makes sence and therefore I make some changes.

Mmm... It's not that providing it only on CPU 0 does not make sense, but actually having a different knob for each CPU can be useful (admittedly in corner cases), and would be consistent with hwpstate_intel. But that's of course not a blocker, this can be added back later on.

Going to review the new version.

@markj Please also help me review it when you have time, thanks! Also, I remember that you have told me that it is better to send ipi instead of binding the CPU, but I forget the url of your sample code. Could you please provide it in here?

If Mark gives no answer in a few days, I'll suggest something.

Minor fixes

@olce I think exposing the epp setting interface only in only cpu0 makes sence and therefore I make some changes. @markj Please also help me review it when you have time, thanks! Also, I remember that you have told me that it is better to send ipi instead of binding the CPU, but I forget the url of your sample code. Could you please provide it in here?

Expose the epp interface in only cpu 0 and modify all cpu value.

Make sense to me.

In D52166#1232521, @bz wrote:

It's gotten silent here. May I ask what the plan is? Is there a chance to get this work into 16?

LGTM.

In D52815#1206854, @imp wrote:

I suspect this is fine. ISA is all the on boatd IO that's ioport mapped that's not part of pci. It most likely is lpc based and the ACPI enumeration of that jardware should hang off this bus, not the acpi bus for the software model. But practically, this is easier and there's not enough difference to mater.

@jhb do you think that it is fine? Since you know much about pcie, and isa is the predecessor of pci(e).

I think nobody cares about isa bus stuff.
Also, no modern hardware attaches to isa bridge actually.
But it is really annoying for me to see "none" in pciconf -lv.