From: Len Brown <len.brown@intel.com>
To: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Borislav Deianov <borislav@users.sourceforge.net>,
Linux ACPI <linux-acpi@vger.kernel.org>,
Arno Willig <akw@thinkwiki.org>
Subject: Re: new ibm-acpi maintainer
Date: Mon, 6 Nov 2006 13:18:22 -0500 [thread overview]
Message-ID: <200611061318.23326.len.brown@intel.com> (raw)
In-Reply-To: <20061103161933.GD4257@khazad-dum.debian.net>
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
next prev parent reply other threads:[~2006-11-06 18:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-02 22:04 new ibm-acpi maintainer Borislav Deianov
2006-11-03 16:19 ` Henrique de Moraes Holschuh
2006-11-06 18:18 ` Len Brown [this message]
2006-11-21 16:26 ` Henrique de Moraes Holschuh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200611061318.23326.len.brown@intel.com \
--to=len.brown@intel.com \
--cc=akw@thinkwiki.org \
--cc=borislav@users.sourceforge.net \
--cc=hmh@hmh.eng.br \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.