Re: [PATCH vfs 2/2] {block|char}_dev: remove inode->i_devices

[Tejun Heo]

On Thu, Nov 20, 2014 at 04:14:29PM +0200, Boaz Harrosh wrote:
> On 11/20/2014 03:11 PM, Tejun Heo wrote:
> > Hello, Boaz.
> > 
> <>
> > W/ preloading, one way to do it is,
> > 
> > 	if (preload())
> > 		handle -ENOMEM;
> > 	lock;
> > 	error = insert();
> > 	if (error)
> > 		handle error which can't be -ENOMEM;
> > 	unlock;
> > 	preload_end();
> > 
> 
> I like this one, cause of the place I come from. Where
> in a cluster you want the local fails as early as possible
> before you start to commit remotely, and need to undo on
> errors.
> 
> And I can see the real flow of things
> 
> > Another way is
> > 
> > 	preload();	// can't fail
> > 	lock;
> > 	error = insert();
> > 	if (error)
> > 		handle error;'
> > 	unlock;
> > 	preload_end();
> > 
> > Both ways have pros and cons.  The latter seems to lead to simpler
> > code in general.  Not always, but the overall.
> > 
> 
> I still like the over all simplicity of the above pattern to
> this behind the seen complexity hidden away under the carpet.

Maybe the right thing to do is allowing both.  It really depends on
the use cases.  For a lot of cases, the error handling and unrolling
are necessary anyway so the deferred preload failure doesn't add any
complexity but there are cases where the insertion can be guaranteed
to succeed.  The only change necessary is making preload return
-ENOMEM which can be ignored by the caller anyway.  The caller can
either ignore and handle the deferred failure later or handle it and
know that later insertion won't fail with -ENOMEM.

Anyways, let's see how minimal linked list implementation works out.

Thanks.

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