Teach ofw_bus_parse_xref_list_alloc to be able to return the length of the parsed list

[Sgalabov_gmail.com]

Summary

Teach ofw_bus_parse_xref_list_alloc to be able to return the length of the parsed list

Currently, there is no easy way to know in advance how many entries a list parsed by ofw_bus_parse_xref_list_alloc() in sys/dev/ofw/ofw_bus_subr.c has.

The attached patch allows us to pass an idx of -1 to ofw_bus_parse_xref_list_alloc(), in which case it would either return an error (negative) or the number of entries in the parsed list (non-negative).

This would be useful if we don't know in advance how many entries such a list has, but we need to get them (and store them) all - we can call ofw_bus_parse_xref_list_alloc with idx = -1, see how many entries to allocate memory for, and then loop through the entries to get each one of them.

[adrian]

adding some reviwers who have their hands deeper in the ofw code.

[andrew]

Can you provide more context? It's not obvious what code you're changing.

[andrew]

There are examples of the commands to run to generate the context on the wiki https://wiki.freebsd.org/CodeReview#Create_a_Revision_via_Web_Interface

[Sgalabov_gmail.com]

Updated diff with more context provided.

[Sgalabov_gmail.com]

Please disregard the above patches for now. I'll update and submit a new diff.
The major flaw in the above diffs is that they wrongly assume that the standard error values are negative, which they're not.

[Sgalabov_gmail.com]

Updated diff added. Now we use the ncells parameter to return the number of elements in case idx == -1 is passed as a parameter. This allows us to continue to interpret the return value as simply 0 == success and anything else is a failure, while also being the least intrusive (IMHO) option to allow us to be able to get the length of the list.

[Sgalabov_gmail.com]

Would it be possible for someone to look at this change so we can decide if it's ok to go with it or just forget about it?

[adrian]

Ideally the API would be changed to return an array that the routine allocates, and the caller can free. But I'm okay with committing this for now until the API gets churned.

Actually, hm, how about we do something a little stranger - let's do this:

• create a new function, that returns how many entries are there
• take the function you've created (with idx == -1) and rename it to something internal
• make the public ofw_bus_parse_xref_list_alloc() call the private version with idx as positive (and asserts on idx < 0); and will return ENOENT as appropriate
• .. and the new function returns how many entries there are.

How's that sound?

[Sgalabov_gmail.com]

Thanks Adrian, I'll do what you suggest and will submit a new diff.

[Sgalabov_gmail.com]

Diff updated per Adrian's latest suggestion.

[Sgalabov_gmail.com]

Sorry, I attached the wrong patch... Now with the right one.

[adrian]

yup, looks good to me!