On Mon, Sep 15, 2008 at 06:07:45PM -0400, John Baldwin wrote: > On Monday 15 September 2008 04:13:10 pm Marcel Moolenaar wrote: > > > > On Sep 15, 2008, at 12:22 PM, John Baldwin wrote: > > > > > On Monday 15 September 2008 12:55:33 pm Marcel Moolenaar wrote: > > >> > > >> On Sep 15, 2008, at 9:47 AM, Andriy Gapon wrote: > > >> > > >>> on 15/09/2008 19:41 Marcel Moolenaar said the following: > > >>>> So, if you compile acpi(4) as a module, you must compile all > > >>>> it's depending drivers as modules as well. Or you compile acpi > > >>>> into the kernel... > > >>> > > >>> I understand the logic, but OTOH uart can work without acpi too, so > > >>> it's not a strict dependency. > > >> > > >> Well, yes. That's what's causing your "problem". You compile a > > >> kernel without acpi but with uart. As such, uart will be built > > >> without acpi support. uart does indeed work without acpi. > > >> > > >> The problem is that people then load the acpi module at runtime > > >> and expect uart to work with acpi. That's not going to fly. If > > >> one builds uart as a module, all possible support is included > > >> and it works as expected. > > >> > > >>> Also, this (acpi dependency) doesn't seem to be documented. > > >> > > >> It's standard behaviour. > > > > > > The problem is that right now we ship with acpi.ko as a module by > > > default and > > > have the loader auto-load acpi.ko IFF the machine supports ACPI. > > > > Well, don't do that then. Just have the device probe check if acpi is > > supported and attach if yes. > > It does that, the loader stuff is from someone trying to be fancy and save the > memory of not having acpi.ko around if the system doesn't support it. This > may in fact be dubious. :) While acpi.ko is a beast (about .5MB) we're really only talking about savings in the case when people are using GENERIC so it seems highly dubious. -- Brooks
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:35 UTC