[Ocfs2-tools-devel] [PATCH 4/6] O2info: Add running codes for '--fs-features'.

[Joel Becker]

On Mon, Apr 26, 2010 at 10:38:51AM +0800, tristan wrote:
> I loved your new solutions;), how about we incorporate solution #2 and #3?
> 
> We do it mostly like solution #3, but also returning successful
> FILLED count by make info.info_count as 'in/out'.

	I don't like it, because we are basically returning error codes
in two places.  That's not nice ;-)

> 1. rc == 0, info_count == full_count: all requests get successfully
> handled, no need to check FL_ERROR.
> 
> 2. rc == 0, info_count < full_count: means some unknown request
> didn't get filled, no need to check FL_ERROR.
> 
> 3. rc != 0: real error in kernel happens, if all FL_ERROR were ok in
> each request, we're sure the error happened in ioctl() before or
> after real request filling, otherwise, the error should be in the
> operation of each request handling.

	Think about coding this up.  Just like my pseudocode for
solution #2, it's ugly for every caller to do.  Each operation in o2info
will have a bunch of ugly boilerplate.

> with above scheme, I've had another concern:
> 
> Should we immediately return the ioctl(2) when hitting error in #N
> request(N< inf_count), or we continuously to handle the rest
> requests by just simply set the FL_ERROR of #N request?

	If you have scheme #3, you continue until the end of the request
list.  It's like async I/O.  The error belongs to the request, not the
ioctl(2) call.

Joel

-- 

You can use a screwdriver to screw in screws or to clean your ears,
however, the latter needs real skill, determination and a lack of fear
of injuring yourself.  It is much the same with JavaScript.
	- Chris Heilmann

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127