new ibm-acpi maintainer

new ibm-acpi maintainer

[Borislav Deianov]

Hi Len,

I've handed over ibm-acpi to Henrique de Moraes Holschuh
<hmh@hmh.eng.br>, who will be the new maintainer. Henrique has been
actively improving ibm-acpi and I trust he'll keep it up to date much
better than I have been able to. 

Thanks,
Borislav

Re: new ibm-acpi maintainer

[Henrique de Moraes Holschuh]

On Thu, 02 Nov 2006, Borislav Deianov wrote:
> I've handed over ibm-acpi to Henrique de Moraes Holschuh
> <hmh@hmh.eng.br>, who will be the new maintainer. Henrique has been
> actively improving ibm-acpi and I trust he'll keep it up to date much
> better than I have been able to. 

Thank you very much, Borislav.  It will be a honour to take care of
ibm-acpi, and I hope I will be able to take care of it in a way that would
make you (and myself) proud.

Len, as the ACPI subsystem maintainer, is there any specific way you'd like
me to handle ibm-acpi?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: new ibm-acpi maintainer

[Len Brown]

On Friday 03 November 2006 11:19, Henrique de Moraes Holschuh wrote:
> On Thu, 02 Nov 2006, Borislav Deianov wrote:
> > I've handed over ibm-acpi to Henrique de Moraes Holschuh

Thanks Boris, I know that a lot of thinkpad users are happier because of your efforts.

> Len, as the ACPI subsystem maintainer, is there any specific way you'd like
> me to handle ibm-acpi?

Yes, we should sync up on both the logistics and the strategy here.

Logistics are pretty much covered by Documentation/SubmittingPatches
Send to me, cc linux-acpi@vger.kernel.org
Subject: ACPI: ibm_acpi: fix foo for model bar

Put some thought into the Subject and check-in comments --
they are the "permanent record" and people do read them.

Also, it is ideal if we can maintain the invariant that the source is Lindent clean.
(right now ibm_acpi.c is very close to clean.  I often Lindent after patches,
 but not always -- simpler if you do it before sending to me)

The strategy for platform specific drivers that use ACPI is:
1. make the machines as useful as possible
2. be supportable by distributors w/o any special user-land effort

Linux does an okay job on #1, but not such a good job on #2 -- yet.

For #2 we are generally trying to make features available to the user
(think HAL, or X) with generic interfaces.  ie. if the word "acpi"
appears in the path, we are probably not generic enough for general use.

This is why I generally do not permit any new files under /proc/acpi,
and why we are trying over time to delete them all and use generic sysfs
places instead.

  eg. you've seen the recent changes to put brightness under sysfs
  in the backlight section, and the recent discussion about a generic
  battery interface, and the recent dock driver and bay driver.
  As these generic interfaces come on-line, we need to delete
  the old ones from these platforms drivers w/o screwing up users.
  This means announcing feature removal and documenting
  it in Documentation/feature-removal.txt and adding #ifdefs
  for the legacy stuff, then finally removing it.
 
 On a minor, but related note,  at some point, ibm_acpi.c should be moved
 outside of /drivers/acpi, probably to drivers/misc where other
 platform specific drivers are starting to congregate.
  This is because it is an OEM specific driver using un-documented
   OEM features that happen to depend on ACPI, but it is not implementing
   the ACPI spec itself, and is thus not part of ACPI.  Can still call it
  ibm_acpi.c, and I'll still be happy to handle patches to it,
  but the line between the implementation of the ACPI spec and the
  platform specific drivers that use ACPI has to be more clear.

thanks,
-Len

Re: new ibm-acpi maintainer

[Henrique de Moraes Holschuh]

On Mon, 06 Nov 2006, Len Brown wrote:
> Also, it is ideal if we can maintain the invariant that the source is Lindent clean.
> (right now ibm_acpi.c is very close to clean.  I often Lindent after patches,
>  but not always -- simpler if you do it before sending to me)

Lindent doesn't do that well with some of the stuff in the patches, but I
will keep everything as Lindent-clean as possible, yes.  I will also see if
I can reformat it to be Lindent-friendly on the areas where Lindent doesn't
do the right thing.

> This is why I generally do not permit any new files under /proc/acpi,
> and why we are trying over time to delete them all and use generic sysfs
> places instead.

ibm-acpi needs a serious revamp on the stuff it *already* exports to
/proc/acpi, so that people will stop blindly echoing stuff directly to EC
space through /proc/acpi/ibm/ecdump.

But as soon as it becomes practical to do so (i.e. as soon as I can find a
sane way to place ibm-acpi in the device model -- currently this means I am
waiting the ACPI patches to go in), I intend to fully move to sysfs, and
freeze (and schedule for removal) the procfs interface.

>   eg. you've seen the recent changes to put brightness under sysfs
>   in the backlight section, and the recent discussion about a generic
>   battery interface, and the recent dock driver and bay driver.

Yes, I have paid quite close attention to them all.

>   This means announcing feature removal and documenting
>   it in Documentation/feature-removal.txt and adding #ifdefs
>   for the legacy stuff, then finally removing it.

Indeed.  For ibm-acpi, I will go with the shortest deprecation periods you
allow me to when the time to do it comes.  Some userland is doing
unforgivable sins to parse the ibm-acpi procfs output, and I want to see all
that bogosity *gone*.

>  On a minor, but related note,  at some point, ibm_acpi.c should be moved
>  outside of /drivers/acpi, probably to drivers/misc where other
>  platform specific drivers are starting to congregate.

Sure.  Whenever you feel like it is the right time to do it, we shall do it.

>    the ACPI spec itself, and is thus not part of ACPI.  Can still call it
>   ibm_acpi.c, and I'll still be happy to handle patches to it,
>   but the line between the implementation of the ACPI spec and the
>   platform specific drivers that use ACPI has to be more clear.

It is a done deal, then.  Just tell me when you want it moved.

A first lot of patches for ibm-acpi will follow soon.  I can also provide
them through git if you'd prefer that.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh