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

[Kristen Accardi <kristen.c.accardi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>]

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.

Kristen



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click