lkml.org 
[lkml]   [2013]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2 01/03] clocksource: Add Kconfig entries for CMT, MTU2, TMU and STI
    On 11/12/2013 09:47 PM, John Stultz wrote:

    [ ... ]

    >> I think all your goals make sense, and I would like to reach the same
    >> place from a usability point of view. I would however like to allow
    >> existing power users to select whatever they want enabled on their
    >> platform. Ideally I also would like to share Kconfig bits between
    >> multiple architectures where appropriate, but it's just a few lines of
    >> code so I don't care that much.
    >
    > And as long as the options for the power-users actually make sense,
    > that all sounds fine. But I want to make sure we aren't needlessly
    > causing pain to folks building kernels all to save a few lines of
    > Kconfig logic.
    >
    > And again, this is just my pet peeve, I'm not the directory
    > submaintainer any more, so Daniel and Thomas are the ones to convince.
    > :)

    So to summarize:

    1. We want to prevent to manually select the drivers, this is painful to
    have the right config. We assume the SoC config will choose the right
    driver config option.

    2. We want to disable some drivers because they could conflict. Or for
    kernel builders, it is easier to hack around the options.

    3. We want to select a driver as a module because the timer could reside
    on a PCI board.

    4. Code size could be an issue if everything is selected.

    IMO, John's approach makes totally sense.

    I am not worried about the code size because one day or another we will
    have to fix up the code size increasing with the single zImage for ARM,
    and we will probably end up to unload dynamically unneeded drivers from
    the memory after booting (I don't how. Perhaps by some magic with the
    init sections).

    Disabling some drivers, or in other words, give more customization
    options to the kernel builders, makes also sense.

    It isn't possible to select the driver as we do right now but let them
    optional from the Kconfig ? What if we invert the logic in the Kconfig,
    make each driver depends on a arch_option defaulting to 'yes', so it can
    be manually unselected (similar to drivers/cpuidle/Kconfig.arm).

    In any case, consolidating SH and ARM Kconfig is ok but with a change
    which is consistent with the current Kconfig, that is following the
    policy of the Kconfig (on top of the current one or on top of a new one).

    -- Daniel




    --
    <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

    Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
    <http://twitter.com/#!/linaroorg> Twitter |
    <http://www.linaro.org/linaro-blog/> Blog

    --
    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/

    \
     
     \ /
      Last update: 2013-11-13 23:01    [W:4.934 / U:0.092 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site