Hi Simon,
On Montag, 24. Jänner 2022 18:57:47 CET Simon Glass wrote:
> Hi Luca,
>
> On Sat, 22 Jan 2022 at 03:59, Luca Weiss <luca@xxxxxxxxx> wrote:
> > Add a new Python method wrapping fdt_get_path() from the C API.
> >
> > Also add a test for the new method.
> >
> > Signed-off-by: Luca Weiss <luca@xxxxxxxxx>
> > ---
> > Changes in v2:
> > - dynamically increase size of string buffer until it fits.
> >
> > The values are chosen relatively arbitrary, and terminates at lengths
> > over than 4096 as I don't expect paths to be longer and there should
> > be an exit condition to not eat up RAM in case of some bug.
> >
> > pylibfdt/libfdt.i | 27 +++++++++++++++++++++++++++
> > tests/pylibfdt_tests.py | 7 +++++++
> > 2 files changed, 34 insertions(+)
> >
> > diff --git a/pylibfdt/libfdt.i b/pylibfdt/libfdt.i
> > index ac70762..d103bb6 100644
> > --- a/pylibfdt/libfdt.i
> > +++ b/pylibfdt/libfdt.i
> >
> > @@ -443,6 +443,28 @@ class FdtRo(object):
> > """
> > return fdt_get_alias(self._fdt, name)
> >
> > + def get_path(self, nodeoffset):
> > + """Get the full path of a node
> > +
> > + Args:
> > + nodeoffset: Node offset to check
> > +
> > + Returns:
> > + Full path to the node
> > +
> > + Raises:
> > + FdtException if the path is longer than 'size' or other error
> > occurs + """
> > + size = 64
> > + while size < 4096:
> > + ret, path = fdt_get_path(self._fdt, nodeoffset, size)
> > + if ret == -NOSPACE:
> > + size += 64
> > + continue
> > + check_err(ret)
> > + return path
> > + raise ValueError('Node path is unexpectedly long')
>
> Do you think it would hurt to go with 4096 immediately? Python is not
> the most efficient language so it should not matter. You can also copy
> it to another object of the correct size, perhaps, to avoid memory
> wastage.
The returned string won't be of $size but of the actual string size, swig doc
mentions of the buffer size being used to dynamically allocate memory on heap
but the result will be returned as string.
Probably it's not a problem to start with a bigger size, but maybe 4096 is a
bit overkill for a normal use case? Paths (at least in Linux dts files) are
normally relatively short so 512 or 1024 feels better for this.
Which values do you think are appropriate here? I made this loop because of
David's reply to v1:
https://www.spinics.net/lists/devicetree-compiler/msg03857.html
> Also can you please explain how swig works here? I'm a bit lost as to
> the magic for calling fdt_get_path().
It's quite well described in the doc (ctrl-f for "cstring_output_maxsize")
http://www.swig.org/Doc4.0/SWIGDocumentation.html
I don't think I've worked with swig before so I found this on stackoverflow or
somewhere, but this function definitely seems to be made for this use case.
As far as I understand it, it just allocates a buffer of x bytes, does the C
call with the temporary buffer and then converts the result into a proper
Python object and discards the buffer.
Regards
Luca
