David Young dyo...@pobox.com wrote:
There are kcpuset_attached and kcpuset_running, which are MI. All ports
ought to switch to them replacing MD cpu_attached/cpu_running. They can
be wrapped into a routine, but globals seem harmless in this case too.
It seems that if they are not
On Feb 3, 2013, at 3:33 PM, Mindaugas Rasiukevicius wrote:
Any reason why do you need bitfield based iteration, as opposed to list
or array based?
Be nice to have a MI method instead a hodgepodge of MD methods.
The CPU_FOREACH method is ugly.
On Sun, Feb 03, 2013 at 04:22:37PM -0800, Matt Thomas wrote:
On Feb 3, 2013, at 3:33 PM, Mindaugas Rasiukevicius wrote:
Any reason why do you need bitfield based iteration, as opposed to list
or array based?
Be nice to have a MI method instead a hodgepodge of MD methods.
The
On Sun, Feb 03, 2013 at 11:33:10PM +, Mindaugas Rasiukevicius wrote:
David Young dyo...@pobox.com wrote:
There are kcpuset_attached and kcpuset_running, which are MI. All ports
ought to switch to them replacing MD cpu_attached/cpu_running. They can
be wrapped into a routine, but
On Fri, Feb 01, 2013 at 06:25:24PM -0600, David Young wrote:
There was no use case, when I added it. Can you describe your use case?
Usually we iterate all CPUs with CPU_INFO_FOREACH() anyway (which should
also be replaced with a MI interface, but that requires non-trivial
invasion into
David Young dyo...@pobox.com wrote:
I was using kcpuset(9) a little bit today and I was surprised that
there was not a routine or a variable representing all of the attached
CPUs. I see that there is such a MI variable declared in sys/cpu.h,
kcpuset_attached. Should it be part of the API?
