Re: [PATCH 1/4] stringbuf: A string buffer implementation

[Matthew Wilcox <matthew@wil.cx>]

On Sat, Oct 27, 2007 at 07:34:47PM +0300, Pekka Enberg wrote:
> On 10/27/07, Rusty Russell <rusty@rustcorp.com.au> wrote:
> > On Saturday 27 October 2007 21:47:09 Pekka Enberg wrote:
> > > Why don't we just return -ENOMEM here just like all other APIs in the
> > > kernel?
> > I think Willy did it because this is for printk.  It makes more sense than
> > everyone opencoding an -ENOMEM handler, which will have to be replaced by
> > some mildly amusing string like "I want to printk but I have no memory!".
> > Next think you know 70% of the kernel will be bad limericks as everyone tries
> > to one-up each other.
> 
> My point was, of course, that the caller gets to decide what to do on
> OOM. For the most part, you probably want to ignore it but for things
> like pseudo filesystems where you generate a human-readable string,
> returning -ENOMEM from read(2) is preferable.

That was why I had an sb_error() as part of the API so a caller who
cared could check, and a caller who didn't care would never know --
they'd just print the out-of-memory string and continue happily.

It's not hard to add an sb_error to Rusty's rewrite.  It looks something
like:

static inline int sb_error(struct stringbuf *sb)
{
	if (sb == sb_enomem_string)
		return -ENOMEM;
	return 0;
}

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."