dtc: Return code of fdt_get_path()
David Gibson
dwg at au1.ibm.com
Wed Aug 13 09:15:07 EST 2008
On Tue, Aug 12, 2008 at 10:57:17AM -0500, Jon Loeliger wrote:
> On Thu, 2008-08-07 at 16:08 +1000, David Gibson wrote:
>
> > Ugh, yes, confirmed that it is buggy. Not sure of the best way to fix
> > this, I can see three ways to go here.
> >
> > 1. Minimally fix the error code bug, make sure NOSPACE is
> > returned when the buffer is too small, length of path otherwise,
> > update documentation to match.
> > 2. Make the code match the documentation: return 0 on success,
> > NOSPACE if the buffer is too small.
> > 3. Update both code and documentation to match the semantics I
> > think I must have intended at some point: always return the path
> > length, even if it exceeds the buffer length; caller is responsible
> > for checking if the path in the buffer is truncated.
> >
> > (3) has the possibly useful property that you can use the call with a
> > small buffer and if it fails the caller now knows how big a buffer it
> > must allocate. With (1) and (2) the caller's only way to deal with
> > NOSPACE is to keep allocating bigger buffers until the call succeeds.
> > However it makes it more complex for the caller to check the return
> > value - not just that it's non-negative put also that it's less than
> > the buffer size. Plus its arguably stylistically inconsistent with
> > the read-write functions which return NOSPACE when the buffer is
> > exceeded with no indication of how much space is needed.
> >
> > Any views, Jon?
>
> Just rolling back into town and catching up some....
>
> Has this issue been resolved yet?
No there's been no motion since this mail, as far as I know. I was
waiting for your response, and otherwise occupied kernel bug hunting
anyway.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
More information about the devicetree-discuss
mailing list