Re: [ckrm-tech] [PATCH 0/5] Allow more than PAGESIZE data read in configfs

[Paul Jackson <pj@sgi.com>]

Chandra wrote:
> As Andrew pointed in one of the email, my patch set reduces the number
> of lines of code in configfs also.

I think Andrew has mentioned this a couple of times ;)

Actually, I've never been particularly happy with the implicit
PAGESIZE limit on these writes.  It's dangerous coding practice to
pass someone a buffer pointer in which they are to write, without
passing a corresponding length.

If it is appropriate for configfs to have some such fixed limit on
file lengths, then that should be a formal part of the API or imposed
in a safer manner than hoping the callback routine doesn't overwrite
a buffer.

Whether or not it should use homebrew code as it does now, or Chandra's
patch to make use of existing infrastructure should be a separate
question.  I think Andrew's observations apply here.

And whether or not we add support for a vector of scalars of the same
type and meaning should be yet another separate question.  No doubt
reasonable minds will differ on this question, though so far that
discussion has been clouded by these other issues.

Greg seems to be suggesting that if we use Chandra's patch, we cannot
impose any length limit, and that this opens the cover to Pandora's
box of all manner of changing and complex output per file.

Well, I could code some pretty ugly output in a single page, if I
set my mind to it.  But it would be rejected, because we've learned
that hurts.

>From that I conclude that it is not the PAGESIZE limit that is saving
us from more unparseable file formats, but the discipline we have
gained from learning the hard way.

Chandra - I haven't looked at seq file lately - could a user of it
such as configfs impose a length limit of its choosing, building on
your patch, without pushing the number of lines of code back above
where it started?

Perhaps, say, we would let the callback routines could push stuff into
a seq file without small limits, but then the configfs code could
truncate that output to a limit of its choosing.  This would impose a
length limit, safely.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/