Re: kcpuset(9) interface

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

hi,

> yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi) wrote:
>> > Here is a reworked dynamic CPU set implementation for kernel (shared
>> > cpuset.c in src/common will be moved to libc) - a kcpuset(9) interface:
>> > 
>> > http://www.netbsd.org/~rmind/kcpuset_ng.diff
>> > 
>> > It supports early use while the system is cold through a fix up
>> > mechanism, see kcpuset_sysinit().  That would enable us to use kcpuset
>> > (9) in MD code, such as pmap(9).  The intention of interface is to:  1)
>> > replace hard-coded parts (e.g. limited to uint32_t or MAXCPUS constant)
>> > with a more dynamic mechanism  2) replace and unify duplicated CPU
>> > bitset code (e.g. in MIPS, PowerPC, sparc64, which have own copies).
>> 
>> thanks for working on this.
>> and sorry for commenting only on a minor point.
> 
> Your comments are always welcome. :)
> 
>> why did you change kcpuset_t to a pointer from a structure?
>> i always feel awkward to compare an opaque type with NULL.
> 
> The reason is that kcpuset_t now points directly to the bit field rather
> than opaque struct kcpuset_impl.  Do you prefer wrapping, e.g. like this:
> 
> struct kcpuset { uint32_t bitfield[0]; };
> 
> Except this is not C99..

is it necessary to expose the fact that it's an array to the API users?
if it isn't, a dummy structure tag should just work.

btw, on second thought, i think it might be worth to allow kcpuset_t be
just a scalar type and avoid dynamic allocations for ports which can't
have large MAXCPUS.  in that case, we should somehow abstract NULL
comparisons.

YAMAMOTO Takashi

> 
> -- 
> Mindaugas