From: Kristen Accardi <kristen.c.accardi@intel.com>
To: Patrick Mochel <mochel@linux.intel.com>
Cc: Prarit Bhargava <prarit@sgi.com>, Andrew Morton <akpm@osdl.org>,
len.brown@intel.com, greg@kroah.com, linux-acpi@vger.kernel.org,
pcihpd-discuss@lists.sourceforge.net,
linux-kernel@vger.kernel.org, arjan@linux.intel.com,
muneda.takahiro@jp.fujitsu.com, pavel@ucw.cz, temnota@kmv.ru
Subject: Re: [patch 1/3] acpi: dock driver
Date: Wed, 19 Apr 2006 11:28:42 -0700 [thread overview]
Message-ID: <1145471322.21185.55.camel@whizzy> (raw)
In-Reply-To: <20060419172816.GA14304@linux.intel.com>
On Wed, 2006-04-19 at 10:28 -0700, Patrick Mochel wrote:
> On Wed, Apr 19, 2006 at 10:08:57AM -0700, Kristen Accardi wrote:
> > On Tue, 2006-04-18 at 15:54 -0700, Patrick Mochel wrote:
>
> > > > +acpi_status
> > > > +register_hotplug_dock_device(acpi_handle handle, acpi_notify_handler handler,
> > > > + void *context)
> > >
> > > If this is called from outside drivers/acpi/, you should return an int with a
> > > real errno value. The AE_* values shouldn't be used outside of the ACPI CA.
> > >
> >
> > Really? We use these all over the place in drivers/pci/hotplug. In
> > fact, you kinda have to use them if you are calling certain acpi
> > symbols, since they return these types.
> >
> > For example, here are some functions will return acpi_status that we use
> > in hotplug land.
> >
> > pci_osc_control_set()
> > acpi_run_oshp()
> > acpi_walk_namespace requires its use.
>
> Well, it's one thing to use a function that returns a non-standard error-value,
> but it's another to add more functions that do. :-)
>
> > I felt that by returning acpi_status I was being consistent with how
> > other acpi calls acted. Is this another example of the iceberg that Len
> > was talking about in a previous email?? (ugh.)
>
> I believe so.
>
> We have a standard, well-defined error namespace that lives in include/*/errno.h.
> ACPI defines its own error namespace because it must be portable, and even though
> most OSes will define the standard errno values, some do not, so it cannot
> assume that it will be there. I'm not sure why the choice was to redefine similar
> error values instead of reusing the errno values, but that's moot at this point..
>
> The only place where the ACPI error values need to be used is in the ACPI CA. The
> functions exposed to the OS from the CA will return AE_* because the same source
> runs everywhere. However, Linux-specific code doesn't need to do that. It is free
> to use Linux-specific error reporting (except in the OSL layer that the CA uses,
> because it is expecting well-defined return values, as specified in the CA
> Programmers Reference).
>
> My standpoint is that Linux-specific code should not be using any ACPI CAisms at
> all because since the code is Linux-specific, it doesn't need to be portable in
> the same manner that the CA is. This is true for all of drivers/acpi/*.c, with the
> exception of drivers/acpi/osl.c, but even some of that source can be cleaned up
> to be more Linux-friendly.
>
> Further rationale is that there is no way to enforce the CAisms in Linux-specific
> code. You will frequently find mixed return values. Sometimes a function is
> declared as
>
> acpi_status acpi_foo()
>
> and return -1 and 0. Or vice versa.
>
> The ACPI drivers were initially written in the same style that the CA was written,
> which makes it confusing when you look at them. But, they don't need to be that
> way. They can look like real Linux drivers and become a lot more palatable.
>
> Eventually, all of the CAisms should be pushed down to the thin layer that sits
> above the interpreter. All exported functions should return ints, and those that
> deal directly with the CA interface should simply translate the AE_* error
> values into an errno return.
>
> Thanks,
>
>
> Pat
Well, I will certainly change the dock code, but pulling this stuff out
of the hotplug drivers will take longer since it would require changing
the offending acpi interfaces.
next prev parent reply other threads:[~2006-04-19 18:19 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20060412221027.472109000@intel.com>
2006-04-12 22:18 ` [patch 1/3] acpi: dock driver Kristen Accardi
2006-04-12 22:35 ` [patch 1/3] acpi: dock driver (refreshed) Kristen Accardi
2006-04-13 5:27 ` [patch 1/3] acpi: dock driver Andrew Morton
2006-04-14 22:02 ` Kristen Accardi
2006-04-14 22:49 ` Kristen Accardi
2006-04-15 14:29 ` Prarit Bhargava
2006-04-18 18:03 ` Kristen Accardi
2006-04-18 22:54 ` Patrick Mochel
2006-04-19 17:08 ` Kristen Accardi
2006-04-19 17:28 ` Patrick Mochel
2006-04-19 18:28 ` Kristen Accardi [this message]
2006-04-19 18:20 ` Patrick Mochel
2006-04-28 23:51 ` [patch 1/3] acpi: dock driver v3 Kristen Accardi
2006-05-11 18:45 ` [patch 1/3] acpi: dock driver v4 Kristen Accardi
2006-06-01 23:05 ` [patch 1/3] acpi: dock driver v6 Kristen Accardi
2006-06-01 23:20 ` Andrew Morton
2006-06-02 0:53 ` Kristen Accardi
2006-04-16 13:28 ` [patch 1/3] acpi: dock driver Prarit Bhargava
2006-04-12 22:18 ` [patch 2/3] acpiphp: use new " Kristen Accardi
2006-04-12 23:16 ` Christian Trefzer
2006-04-28 23:55 ` [patch 2/3] acpiphp: use new dock driver v2 Kristen Accardi
2006-04-12 22:18 ` [patch 3/3] acpiphp: prevent duplicate slot numbers when no _SUN Kristen Accardi
2006-04-13 12:36 ` MUNEDA Takahiro
2006-04-14 21:39 ` Kristen Accardi
2006-04-14 22:42 [patch 1/3] acpi: dock driver Brown, Len
2006-04-14 23:11 ` Kristen Accardi
-- strict thread matches above, loose matches on Subject: below --
2006-04-14 23:17 Brown, Len
2006-04-19 17:14 Moore, Robert
2006-04-19 17:36 ` Patrick Mochel
2006-04-19 17:51 Moore, Robert
2006-04-19 18:06 ` Patrick Mochel
2006-04-19 19:17 Moore, Robert
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=1145471322.21185.55.camel@whizzy \
--to=kristen.c.accardi@intel.com \
--cc=akpm@osdl.org \
--cc=arjan@linux.intel.com \
--cc=greg@kroah.com \
--cc=len.brown@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@linux.intel.com \
--cc=muneda.takahiro@jp.fujitsu.com \
--cc=pavel@ucw.cz \
--cc=pcihpd-discuss@lists.sourceforge.net \
--cc=prarit@sgi.com \
--cc=temnota@kmv.ru \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox