[ACPI] Re: [PATCH 1/2] make acpi_path_name() global

[Rolf E. B. <ei...@sf...>]

> On Thu, 2005-12-15 at 21:27 -0800, Randy.Dunlap wrote:
>> On Thu, 15 Dec 2005 23:56:47 -0500 Brown, Len wrote:
>
> <snip>
>> > an example of this is acpi_get_name(), which as declared
>> > isn't supposed to be available outside the core.
>> > All the uses of it to print ACPI namespace tokens in /proc
>> > are totally bogus and should be deleted.  The other use
>> > of it is to print out debug strings -- stuff the OS
>> > doesn't really need to "know" and maybe something the
>> > core should do for it.  That leaves the hotplug use,
>> > which I don't understand.  What does SATA need
>> > with the actual path names?
>>
>> SATA uses the name string for (a) debugging, as you have
>> mentioned, and (b) for comparing complete device strings
>> to match/find a SATA _ADR under a device (in a device's
>> scope).  I can do without (a) as well as the rest of the
>> kernel can, of course.  I don't know how to find and match
>> SATA devices (part b) without it, so this is an opportunity
>> for you to educate me.  :)
>>
>>
> We use this in pciehp and shpchp as well for the same reason.  One thing
> I don't love about these patches is the need now to worry about freeing
> memory after you make these calls.  To me that seems like asking for
> memory leaks in error paths at some point down the road when someone
> less careful than Randy adds some code in.  If there were some way to
> return a pointer to a static string, I'd prefer that solution, but I
> can't figure out from looking at the acpi code if that is possible.  If
> there's some better way to perform this compare, I'd like to hear it
> too.

Don't do the allocation in the function but pass a buffer and it's length
to it. The caller can do dynamic allocation if needed or use a buffer on
stack if not. This also makes error handling easier as ENOMEM can't happen
in acpi_path_name() anymore.

Eike