Re: [PATCH] fix sys cpumap for > 352 NR_CPUS

[Rusty Russell]

On Fri, 2004-06-04 at 02:51, Greg KH wrote:
> Just be aware of the size and code your show() function to be defensive
> and not overrun that size.

This is where we have a philosophical difference.  As I understand it,
the rule is, "don't put big things in attributes".  If we want to change
that rule, we need to do more work, like pass the length to the show
function, and handle -ENOMEM by reallocating and looping.

But I think the /rule/ is a good one: if you need to handle something
arbitrarily large, DON'T USE THIS INTERFACE, because there is no way to
do that correctly.  This allows us to handle 99.9% of cases as a
one-liner, which I think has great merit.

I think we should guarantee any kernel primitive fits into the space:
this means it should comfortably fit printing a cpumask_t.  I would
argue for a #error inside the cpumask or sysfs code which ensures we can
fit two cpumasks (~7000 CPUs on page-size 4096), so we explode early if
this ever becomes a problem, and a runtime sanity check inside the sysfs
code to BUG on overrun.

If the average code is worrying about the exact size of the sysfs
buffer, I think they're on the wrong path.  If they are checking it at
runtime, they've got a bug.

I hope this clarifies my thinking, and I can understand that people
would disagree with my premise: that's OK.

Cheers,
Rusty.
-- 
Anyone who quotes me in their signature is an idiot -- Rusty Russell

-
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/