Re: [PATCH] cpumask 5/10 rewrite cpumask.h - single bitmap based implementation

[Mikael Pettersson]

William Lee Irwin III writes:
 > William Lee Irwin III writes:
 > >> If the marshalling code presents different formats to userspace
 > >> depending on BITS_PER_LONG then it's buggy.
 > 
 > On Fri, Jun 04, 2004 at 11:46:49AM +0200, Mikael Pettersson wrote:
 > > No. Read what I wrote: binary compatibility was the very problem I
 > > set out to solve, not cause.
 > > For a given cpumask_t value, user-space sees the same binary
 > > representation irregardless of how you combine 32 or 64-bit
 > > user-spaces with 32 or 64-bit kernels.
 > > This has all been worked out on x86 and amd64, and the conversion
 > > is endian-neutral so e.g. ppc32 on ppc64 should work.
 > 
 > cpumask_scnprintf() is correct to all appearances... testcase please.

How large buf does it need? I don't see any spec for that in 2.6.6.

Second, let's just say that while some kernel people think that
converting stuff to ASCII is "neat", I'm not one of them. It's
just a waste of time and space, for both kernel and user-space.
I'd rather do a for-each-CPU loop which strictly keeps to cpumask_t
operations than take a detour via ASCII.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/