Messages in this thread | | | Date | Fri, 26 Apr 2019 15:38:30 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: [PATCH v17 1/3] proc: add /proc/<pid>/arch_status |
| |
On Fri, 26 Apr 2019, Enrico Weigelt, metux IT consult wrote: > On 25.04.19 12:50, Thomas Gleixner wrote: > > On Thu, 25 Apr 2019, Enrico Weigelt, metux IT consult wrote: > > > >> On 25.04.19 12:42, Li, Aubrey wrote: > >>> > >>> Yep, I'll make it disabled by default and not switchable and let arch select it. > >>> > >> > >> That's not quite what I've suggested. Instead: > >> > >> #1: make the switch depend on the arch's that support it > > > > No. That's what select is for. > > Just for clarification: I've proposed the depend, because not only some > archs will support it - and avoid masses of #ifdef's in the code. > Therefore, it can only be enabled, when the archi supports it.
What has the way how you enable support to do with masses of #ifdefs? Absolutely nothing.
> But if you insist in not having it configurable, letting the arch just > select this feature, your approach makes sense.
Even if you make it configurable, then having:
depends on ARCH1 ... ARCHN
is just wrong. That's what dependency config symbols are for which can be selected by the arch.
> >> #2: still leave it selectable to the user, so somebody who doesn't need > >> it, can just disable it. > > > > Well, the number of knobs is exploding over time and the number of people > > actually tweaking them is close to 0. So no, we don't want to have the > > extra tunable for everything and the world. > > The great configurability often is one of the major arguments for using > Linux in the first place. > > Would you propose killing all the CONFIG_EMBEDDED/CONFIG_EXPERT > related knobs ?
No, but adding knobs for every tiny piece of code does not make the whole thing any better in terms of usability and maintainability.
Thanks,
tglx
| |