[lkml]   [2003]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [ACPI] [PATCH] 1/3 ACPI resource handling
Good grief.  If people would actually read and think about the
change instead of having a knee-jerk reaction to seeing
"#define", they would see that inline functions will not work
in this particular application. The macros were used to
factor code that was identical except that it operated on
different structure types. Inline functions obviously require
explicit argument declarations, while macros don't, so macros
are the only choice for this type of factoring.

In any case, this horse has been long dead. I've posted versions of
acpi_resource_to_address64() both with and without the macros, and
haven't heard any substantial objections, so I'm assuming the ACPI
folks will either ignore them or pick the one they like best and
we can move on.


On Monday 24 February 2003 3:48 pm, Moore, Robert wrote:
> Yes, as long as the code is used more than once (which it appears to be),
> then of course it should be procedurized.
> Bob
> -----Original Message-----
> From: Pavel Machek []
> Sent: Sunday, February 23, 2003 2:55 PM
> To: Moore, Robert
> Cc: 'Bjorn Helgaas'; Grover, Andrew; Walz, Michael;;
> Subject: Re: [ACPI] [PATCH] 1/3 ACPI resource handling
> Hi!
> > 1) This seems like a good idea to simplify the parsing of the resource
> lists
> >
> > 2) I'm not convinced that this buys a whole lot -- it just hides the code
> > behind a macro (something that's not generally liked in the Linux world.)
> > Would this procedure be called from more than one place?
> Well, reducing code duplication *is* liked in Linux world. Use inline
> function instead of macro if possible, through.
> Pavel

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:33    [W:0.030 / U:1.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site