I shall iterate again, this change makes no change to what the guests
sees if you use the old method sysctl hw.vmm.topology.cores_per_package
or hw.vmm.topology.threads_per_core to set these values, it is
purely a interface enhancement that makes these tuneables easy
to access from userland bhyve(8).
Those sysctls were an undocumented workaround with no error checking.
You are making this a documented part of bhyve,
A guest can not tell the diffence in what way these are set.
If hw.vmm.topology.* needs testing thats not on me, that is
an existing problem, and one that has existed for far too long.
Ah, no, the testing is on you, not the user community.
You can easily download an eval of Windows 10 to try this out with.
You do not (and have never) required ATA support to run Windows on bhyve.
I have made a call for testing, whats your issue?
Are you trying to force me to do that testing?
At a minimum, you are expected to test changes that you expect to commit.
And I consider this change rather trivial and with near 0 risk,
You've never made a commit to bhyve but somehow feel qualified to make
risk assessments.
And why the rush ? I'm yet to understand what the urgency for this
work is ? Who is demanding it ?
The users have been wanting this for well over a year, it was
a frequently requested item when I wrote it. It is long overdue.
Right, so 3 weeks for MFC is perfectly acceptable in that case.
You seem to be raising a bar higher than any other part of
FreeBSD for this rather simple user command enhancement,
can I ask what your objection is?
The fact that you seem to think testing this is someone else's
problem, in a subsystem where rigorous testing is a requirement.
later,
Peter.
_______________________________________________
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
"freebsd-virtualization-unsubscr...@freebsd.org"
