Re: Linux-2.6.13-rc6: aic7xxx testers please..

From: Theodore Ts'o (tytso_at_mit.edu)
Date: 08/08/05

  • Next message: linux-os (*** Johnson): "Re: I can not build a new kernel image with a assembly module"
    Date:	Mon, 8 Aug 2005 10:17:48 -0400
    To: Dumitru Ciobarcianu <Dumitru.Ciobarcianu@iNES.RO>
    
    

    On Mon, Aug 08, 2005 at 12:14:43AM +0300, Dumitru Ciobarcianu wrote:
    > ??n data de Du, 07-08-2005 la 11:47 -0700, Linus Torvalds a scris:
    > > Luming Yu:
    > > [ACPI] revert Embedded Controller to polling-mode by default (ala 2.6.12)
    > > [ACPI] CONFIG_ACPI_HOTKEY is now "n" by default
    >
    > IMHO you really need then to make acpi_specific_hotkey the default or at
    > least mention it in the release notes or you'll have tons of people
    > screaming that the specific module does not work anymore.
    > I found out about it after my toshiba_acpi module stopped working and I
    > noticed a small change in the development acpi tree documentation
    > mentioning acpi_specific_hotkey ...

    What was the reasoning behind this UI design decision anyway? If you
    don't enable the generic hotkey code, it seems _stupid_ to require a
    magic boot-time config option in order to enable the specific hotkey
    code. Yes, at the very least we should do is mention this
    brain-damaged UI in the release notes, since otherwise users will get
    the warning, recompile without the generic hotkey support, and then be
    confused when the IBM driver still complains that it can't start
    because we're using generic hotkey support --- which is not enabled!

    The developer/user will at this point either (a) start diving into the
    kernel sources and marvelling at the user-hostile UI design decisions
    involved, or (b) start screaming and pounding their head against a
    brick wall.

    At least in the case of the IBM driver, it provides _far_ more
    functionality than the generic hotkey option (ultrabay control,
    docking control, bluetooth enable/disable, fan control, etc.) so if it
    is compiled it, it should by default take precedence over the hotkey
    code. I'm not convinced there should be any need for a mysterious
    command-line option at all, but if it is present, it should only
    provide an override in case both the generic and the hotkey-specific
    drivers are compiled in. If they are modules, the first module to
    load should take precedence, and if they are both compiled in, the
    laptop-specific should take precendence unless there is a boot-time
    option to the contrary.

    Len, am I missing something, or will you accept a patch.... ?

                                                    - Ted
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: linux-os (*** Johnson): "Re: I can not build a new kernel image with a assembly module"