RE: [PATCH 2/6] ACPICA: Rename some function and variable names

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I'm not talking about a single patch, but the entire process that has been cumbersome.


-----Original Message-----
From: Rafael J. Wysocki [mailto:rjw@xxxxxxx] 
Sent: Thursday, December 09, 2010 2:51 PM
To: Moore, Robert
Cc: Lin, Ming M; Len Brown; linux-acpi@xxxxxxxxxxxxxxx
Subject: Re: [PATCH 2/6] ACPICA: Rename some function and variable names

On Thursday, December 09, 2010, Moore, Robert wrote:
> For the next time we attempt to make such a large ACPICA change, we need to put a methodology in place to simplify things. It has been very difficult for us to take Linux patches, backport and integrate into ACPICA, make additional changes, then forward port the final ACPICA changes to Linux, and then shoehorn the code into the original Linux patches.
> 
> Difficult as in several times the work.
> 
> Ming has worked very hard to forward-port the ACPICA code and then shoehorn the changes into the original Linux patches.
> 
> But we can't do it this way again. 
> 
> We are open to suggestions on a better way to do this, perhaps Len can help.

Well, I'm talking about a simple thing like splitting a patch into two pieces.
That's not going to take a lot of time IMO and the benefit is that more people
may actually understand what's being done.

Moreover, if anyone hits a problem related to one of your patches, it's vital
to be able to figure out which change caused it to happen.

Thanks,
Rafael


> -----Original Message-----
> From: Rafael J. Wysocki [mailto:rjw@xxxxxxx] 
> Sent: Thursday, December 09, 2010 2:00 PM
> To: Lin, Ming M
> Cc: Len Brown; Moore, Robert; linux-acpi@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH 2/6] ACPICA: Rename some function and variable names
> 
> On Monday, December 06, 2010, Lin Ming wrote:
> > Some function and variable names are renamed to be consistent with
> > ACPICA code base.
> > 
> > acpi_raw_enable_gpe -> acpi_ev_add_gpe_reference
> > acpi_raw_disable_gpe -> acpi_ev_remove_gpe_reference
> > acpi_gpe_can_wake -> acpi_setup_gpe_for_wake
> > acpi_gpe_wakeup -> acpi_set_gpe_wake_mask
> > acpi_update_gpes -> acpi_update_all_gpes
> > acpi_all_gpes_initialized -> acpi_gbl_all_gpes_initialized
> > acpi_handler_info -> acpi_gpe_handler_info
> > ...
> > 
> > Signed-off-by: Lin Ming <ming.m.lin@xxxxxxxxx>
> 
> Well, tha changes related to acpi_ev_gpe_dispatch() do not really match the
> changelog.  I'd prefer them to go into a separate patch with the right
> description.
> 
> ...  
> >  u32
> > -acpi_ev_gpe_dispatch(struct acpi_gpe_event_info *gpe_event_info,
> > +acpi_ev_gpe_dispatch(struct acpi_namespace_node *gpe_device,
> > +		     struct acpi_gpe_event_info *gpe_event_info,
> >  		     u32 gpe_number);
> >  
> ...
> >  					int_status |=
> > -					    acpi_ev_gpe_dispatch(&gpe_block->
> > +					    acpi_ev_gpe_dispatch(gpe_block->
> > +								 node,
> > +								 &gpe_block->
> >  						event_info[((acpi_size) i * ACPI_GPE_REGISTER_WIDTH) + j], j + gpe_register_info->base_gpe_number);
> >  				}
> >  			}
> ...
> > @@ -589,7 +597,9 @@ acpi_ev_gpe_dispatch(struct acpi_gpe_event_info *gpe_event_info, u32 gpe_number)
> >  		 * Ignore return status for now.
> >  		 * TBD: leave GPE disabled on error?
> >  		 */
> > -		(void)gpe_event_info->dispatch.handler->address(gpe_event_info->
> > +		(void)gpe_event_info->dispatch.handler->address(gpe_device,
> > +								gpe_number,
> > +								gpe_event_info->
> >  								dispatch.
> >  								handler->
> >  								context);
> ...
> 
> Thanks,
> Rafael
> 

ÿô.nlj·Ÿ®‰­†+%ŠË±é¥Šwÿº{.nlj·¥Š{±ý¶›¡Ü}©ž²ÆzÚj:+v‰¨þø®w¥þŠàÞ¨è&¢)ß«a¶Úÿûz¹ÞúŽŠÝjÿŠwèf



[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux