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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
