[Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Sergey Senozhatsky]

Hello,

am I the only one who struggle with the Kconfig sometimes? can there
be a way to make it more general/simpler, in some parts at least? e.g.
the hardening effort? (just an example. *ABSOLUTELY NOT* blaming Kess
or anyone else who is involved, that's not the point, they are doing
great job, no doubt. it's just the most recent thing I saw was
CONFIG_SLAB_MERGE_DEFAULT). do people who really want to harden their
kernels go all-in anyway (enable all of the options at once)? if so,
can there be a single Kconfig option then? just curious.

	-ss

Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Linus Torvalds]

On Tue, Jun 27, 2017 at 6:58 AM, Sergey Senozhatsky
<sergey.senozhatsky.work@gmail.com> wrote:
>
> am I the only one who struggle with the Kconfig sometimes?

I hate our Kconfig. It's my least favorite part of the kernel. It asks
questions about insane things that nobody can know the answer to.

Taking a distro default config and doing"make localmodconfig" is what
I end up doing on new machines, and it has all kinds of suckage too.

I don't have a solution to it. But I think part of the solution would
be for us to have various "sane minimal requirement" Kconfig
fragments, and trhe ability to feed them incrementally, so that people
can build up a sane Kconfig from "I want this".

For example, instead of answering a million odd questions about
specific features that the base distro expects to always be there
(say, just the networking firewall rules and stuff like that), have
some "minimal required features to boot Fedora 25 or SuSE 12 sp2".

And then a "I use Intel KVM, so I need those minimal features, but I
do *not* want paravirtualization or any other virtualization
services".

We could *maybe* make it part of some "make simpleconfig" that just
basically uses "select" a lot with s special architecture-specific
Kconfig file, and try to help people with a few bigger questions.

Not the thousands of detailed questions. Just do the big strokes, and
enable teh *normal* still. The "defconfig" approach doesn't work (and
hasn't for a long time except for cases where you have very specific
configurations), but just having the abilitty to enable a *sane* basic
config for modern machines would be fine.

Would you have to tweak it later when you have odd hardware or speific
issues? Yes. But there shouldn't be a single question about USB - just
enable basic support, and then add support for HID and USB storage
that pretty much everybody will need. Things like that, to get a
workign but basic config going.

And yes, the security questions are all insane. Nobody knows what the
answers are, since some of it is distro-specific, and others are just
"do you want to test hardening". And because people don't even know
which is which, they often end up enabling features that they
shouldn't, just because they are unsure.

The default distro config still enables PCCARD support, even if you
don't have a laptop at all (or if your laptop is not from the middle
ages any more). Big things like that make a big difference in what
questions you are then asked about random devices.

ISDN? ATM? They're dead. Some sane simple config shouldn't ask about
them any more. The "ten thousand questions" could probably be narrowed
down to maybe a few tens, with some tweaking for special devices
people have lying around.

And note that none of this is about technoliogy, and SAT solvers and
resolving the KConfig depdendencies that some techie people love
talking about. It's all about "what if we just had some kconfig
fragments to enable some commonly used stuff" (where "commonly used"
is obviously architecture dependent, but also target-dependent - a
"simpleconfig" for a PC workstation kind of config is very different
from a "simpleconfig" for a server or some ARM embedded thing).

                  Linus

Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Luis R. Rodriguez]

On Tue, Jun 27, 2017 at 10:18:04AM -0700, Linus Torvalds wrote:
> And then a "I use Intel KVM, so I need those minimal features, but I
> do *not* want paravirtualization or any other virtualization
> services".

Such things exist now:

make kvmconfig
make xenconfig

> We could *maybe* make it part of some "make simpleconfig" that just
> basically uses "select" a lot with s special architecture-specific
> Kconfig file, and try to help people with a few bigger questions.

So you mean a menu of the defconfigs ?

> Not the thousands of detailed questions. Just do the big strokes, and
> enable teh *normal* still. The "defconfig" approach doesn't work (and
> hasn't for a long time except for cases where you have very specific
> configurations), but just having the abilitty to enable a *sane* basic
> config for modern machines would be fine.
> 
> Would you have to tweak it later when you have odd hardware or speific
> issues? Yes. But there shouldn't be a single question about USB - just
> enable basic support, and then add support for HID and USB storage
> that pretty much everybody will need. Things like that, to get a
> workign but basic config going.
> 
> And yes, the security questions are all insane. Nobody knows what the
> answers are, since some of it is distro-specific, and others are just
> "do you want to test hardening". And because people don't even know
> which is which, they often end up enabling features that they
> shouldn't, just because they are unsure.

Sensible defaults per subsystem would help.

> And note that none of this is about technoliogy, and SAT solvers and
> resolving the KConfig depdendencies that some techie people love
> talking about.

If you have a set of requirements but need to fold in a large lump of
other desirables then surely a SAT solver can help.

> It's all about "what if we just had some kconfig
> fragments to enable some commonly used stuff" (where "commonly used"
> is obviously architecture dependent, but also target-dependent - a
> "simpleconfig" for a PC workstation kind of config is very different
> from a "simpleconfig" for a server or some ARM embedded thing).

Actually ideally something like udevadm dumping respective kconfig symbols
should give you what kconfig a system needs at a specific boot time. Solving
this was part of Cristina Moraru's  2016 GSoC effort which tried to streamline
scripts/kconfig/streamline_config.pl (make localmodconfig). That effort ended
up producing simple patches to associate modules with respective kconfig
symbols, to enable udevadm to dump the info later.

Cristoph didn't like the reverse engineering approach this seemed to take
though so proposed an alternative which could even fold Makefiles into Kconfig
[2]. I however found issues with built-in with this model [3], other than this
it seemed fair and reasonable provided we actually worked on it.

At Linux Plumbers Sante Fe we had a small kernel session about Kconfig
semantics to talk more about this. Some loose ideas and notes from that
sessions:

  * Arnd noted a kconfig "Suggests" tag seems appropriate, he seems to have
    volunteered to work on it :)

  * David Howells noted he'd prefer to have a cache of enabled features.
    He also volunteered this ;)

  * We all seem to have decided having *both* depends and select is dumb.
    So we decided we could remove select but fix tools first to give you
    what you need:

    - make selectconfig
    - make dependsconfig

[0] https://kernelsense.wordpress.com/2016/08/23/gsoc-2016-summary/
[1] https://lkml.kernel.org/r/1471462023-119645-1-git-send-email-cristina.moraru09@gmail.com
[2] https://marc.info/?l=linux-backports&m=147211126311774&w=2
[3] https://marc.info/?l=linux-kernel&m=147215738525058&w=2

  Luis

Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Linus Torvalds]

On Tue, Jun 27, 2017 at 11:44 AM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
>
> Such things exist now:
>
> make kvmconfig
> make xenconfig

Not really. Not for normal users. Those are literally only for the
special cases that are *not* normal.

> So you mean a menu of the defconfigs ?

No. The defconfigs are useless. They are fundamentally broken, excatly
because there is never one config that can work.

They do need to be of the "kvmconfig" type, but for sane subconfirurations.

So I'd look for something like

    make modernpcconfig # enable minimal modern PC workstation stuff
    make f25config  # enable minimal stuff required for F25
    make amdconfig # enable the core modern AMD stuff

or something like that.

But it's not going to happen, because everybody thinks *their* code is
so supremely important, so the "minimal config" is literally a doomed
concept ;(

> Sensible defaults per subsystem would help.

No. We've tried. The only sensible default (and that I try to enforce)
is "new featrures default to 'n'"

Why? Exactly because of that "everybody thinks *their* code is
important". Developers always think "I have to enable my code". It
doesn't matter how stupid or esoteric their code is, the developer by
definition thinks their own code is supremely important, and
particularly all the new cool features.

So subsystem defaults are always completely broken, unless I come
along and swear at people who think their new cool feature is
important.

Which I do regularly. And I'm sure I miss things, because I just don't see them.

> If you have a set of requirements but need to fold in a large lump of
> other desirables then surely a SAT solver can help.

No. The SAT solver will only hurt, because it will bring in all those
irrelevant people who are interested in SAT solving, not in making
things easy for users.

It should be perfectly sufficient to just have a series of 'select
XYZ' statements, and yes, update them manually, but since the point is
to go for minimal, automation by definition just breaks it. It will
just make people select big things and leave it at that.

> Actually ideally something like udevadm dumping respective kconfig symbols
> should give you what kconfig a system needs at a specific boot time.

So we already have localmodconfig that uses other things to figure out
what is needed, but no, it's not good enough.

Partly it's not good enough because realistically there are base
configs that you want enabled whether they are used or not. For
example, enabling USB without enabling USB_STORAGE is kind of crazy in
this day and age. But USB storage is not required for booting in most
circumstances, it's just reuired for occasional day-to-day things.

Also, one problem really is that distro configurations by definition
will be pretty damn large. If you want that config, then use the
distro config. But if you want anything else, then udevadm isn't going
to help you at all, because it's not going to show you any of the
stuff that just worked because it was built in and never neeed any
action at all.


>   * Arnd noted a kconfig "Suggests" tag seems appropriate, he seems to have
>     volunteered to work on it :)

Yeah, that's not goping to work either, simply because what is
suggested in one context makes no sense at all in another.

Are you doing a PC workstation kind of thing like many developers are?
Very different from qwhen you're doing an embedded thing or a server
or whatever.

>   * David Howells noted he'd prefer to have a cache of enabled features.
>     He also volunteered this ;)

I do that. There's a reason "make defconfig" reads your
/etc/kernel-config. It's just that it's machine-specific.

And it's there exactly so that you can make your machine-specific
config *once*, and then it's there, and it never affects anybody else
(unless you share your /etc directory, but that's crazy).

But even with that, I find our config stuff annoying. Upgrading
hardware or distros is always just painful, because it means
re-generating a new machine-specific configuration (either because the
hardware changed, or because the distro baseline requirements
changed).

                    Linus

Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Kees Cook]

On Tue, Jun 27, 2017 at 12:27 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> No. The defconfigs are useless. They are fundamentally broken, excatly
> because there is never one config that can work.
>
> They do need to be of the "kvmconfig" type, but for sane subconfirurations.
>
> So I'd look for something like
>
>     make modernpcconfig # enable minimal modern PC workstation stuff
>     make f25config  # enable minimal stuff required for F25
>     make amdconfig # enable the core modern AMD stuff
>
> or something like that.
>
> But it's not going to happen, because everybody thinks *their* code is
> so supremely important, so the "minimal config" is literally a doomed
> concept ;(

I'd be curious to see someone try this anyway, just to see how it
turns out. It's been suggested to me before for hardening features,
(e.g. "make hardenedconfig") and I think it would turn out better than
trying to encode it directly in Kconfig itself. Each kernel release
can have its "make *config" targets updated as the individual CONFIGs
change... though I suspect it might bitrot... But it would be nice to
add "make paranoidconfig" to the above set of make *config runs.

I know I won't have time to do this in the near future, though, so the
best I've done is spew paranoid default suggestions into the KSPP wiki
instead[1]. My plan for spending time on Kconfig currently is to try
to get the compiler feature detection[2] working sanely.

-Kees

[1] http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings
[2] http://www.spinics.net/lists/linux-kbuild/msg15070.html

-- 
Kees Cook
Pixel Security

Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Olof Johansson]

On Tue, Jun 27, 2017 at 12:27 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Tue, Jun 27, 2017 at 11:44 AM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
>>
>> Such things exist now:
>>
>> make kvmconfig
>> make xenconfig
>
> Not really. Not for normal users. Those are literally only for the
> special cases that are *not* normal.
>
>> So you mean a menu of the defconfigs ?
>
> No. The defconfigs are useless. They are fundamentally broken, excatly
> because there is never one config that can work.
>
> They do need to be of the "kvmconfig" type, but for sane subconfirurations.
>
> So I'd look for something like
>
>     make modernpcconfig # enable minimal modern PC workstation stuff
>     make f25config  # enable minimal stuff required for F25
>     make amdconfig # enable the core modern AMD stuff
>
> or something like that.

It sounds to me like you want to turn it from option/driver selection
to feature selection, where features could be stuff like:
 * Basic config for modern PC
  - Intel-based
  - AMD-based
 * DBasic configs for distros
  - F25
  - Debian Jessie
  - ...
 * Virtualization
  - Platform support
    + Intel (default platform support && basic-config-for-intel)
    + AMD
  - Paravirt support
    + Drivers for paravirt platform [...]


Is that a correct interpretation of what you have in mind?


So, a meta config layer if seen in the context of our current config system.

If we were to do this incrementally with current Kconfig on the
backend, I think most of the above could be done as one config action,
that in turn would select a set of kconfig snippets on the backend,
concatenate them all and give you the config to build with.



-Olof

Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Linus Torvalds]

On Tue, Jun 27, 2017 at 2:16 PM, Olof Johansson <olof@lixom.net> wrote:
>
> It sounds to me like you want to turn it from option/driver selection
> to feature selection, where features could be stuff like:
>
> So, a meta config layer if seen in the context of our current config system.

Yes.

Most people are really bad at knowing details, but they may well know
some big-picture stuff. They can certainly answer questions like "do
you have a laptop", and "does it have a PCMCIA card slot".

They might even be able to answer some HW specifics ("Is it 64-bit?"
"Is the CPU an Intel/AMD or ARM chip?").

But answering questions like "do you have broadcom wireless" is
already much much harder, particularly if it's one very particular
broadcom chipset, that isn't even sold as broadcom, because HP or Dell
or Lenovo whatever laptop you have doesn't even really sell it as
such.

So asking a normal user about details like that is already fraught
with error, and that *should* be a really trivial question from a
technical angle. Some other questions are *much* harder.  When you get
into some of the esoteric interfaces like "do you need CGROUPS
support", any normal person has no friggin clue about the details of
their particular user land installation.

> If we were to do this incrementally with current Kconfig on the
> backend, I think most of the above could be done as one config action,
> that in turn would select a set of kconfig snippets on the backend,
> concatenate them all and give you the config to build with.

I agree that our current Kconfig backend might be able to do it. At
the same time, I'm not sure it necessarily the right model.

For example, I think we migth want to use scripts that are *not* about
current Kconfig stuff, but instead are tailored towards particular
special cases.

For example, how about a script that takes a list of PCI devices, and
figures out the modules for that, and generates a list of Kconfig
symbols you want?

It's kind of what "make localmodconfig" does, not not really. It's
more targeted to a particular subsystem, and it's *not* necessarily
something that Kconfig itself would do. It's a helper script, and then
you could do

    make localpciconfig

to enable those PCI options that are local to that device (or run the
script with the list from somebody else)

Same for various hotplug devices (including, but not limited, to USB)
- but maybe it could generate a list of USB devices by looking at your
system logs, and seeing what you used in the last month?

Ok, that's a very specific example, and I'm not saying either of those
are really great ideas and should be implemented, but more throwing it
out as the kind of things we *could* do to make it easier for people
to build their own kernels.

I think there are a lot of people that are afraid of testing a new
kernel purely because of the high KConfig pain threshold.

It's hopefully not because the build is all that complex - christ, I
have been building my own version of Qt the last couple of weeks for
reasons you do *not* want to know, and compared to that a kernel build
is a breeze and completes almost immediately, and has almost no build
dependencies, but also should have no pain in installing because we
allow multiple kernels at the same time _and_ they should all work
because of the "no user space regressions" rule.

That is, they should all work as long as you get that incredibly
complicated configuration phase right ;)

So I'd love to have this made easier.

I'm just not necessarily very optimistic, since kernel config has
never EVER been easy/

Well, I guess it was easy back in 1991, when you just didn't have any
options. You got what you got, and if you didn't have the right
hardware, it didn't work, but at least you didn't need to configure
the kernel much.

                        Linus

Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Serge E. Hallyn]

Quoting Linus Torvalds (torvalds@linux-foundation.org):
> For example, how about a script that takes a list of PCI devices, and

Or uses lspci and lsusb output?

> figures out the modules for that, and generates a list of Kconfig
> symbols you want?

Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Luis R. Rodriguez]

On Tue, Jun 27, 2017 at 4:10 PM, Serge E. Hallyn <serge@hallyn.com> wrote:
> Quoting Linus Torvalds (torvalds@linux-foundation.org):
>> For example, how about a script that takes a list of PCI devices, and
>
> Or uses lspci and lsusb output?

Cristina looked at evaluating precisely *this* first as part of her
GSoC project, details on her post I linked.

Each subsystem can use different buses, so each bus might have a
different way to map to a driver. Then the driver can also change
names over kernels.

The *easier* thing to do for now was to just map a loaded module to a
kconfig symbol, and she proposed fairly simple patches to do this.
That'd allow one-to-one mapping of module from udevadm output to a
kconfig symbol. It'd try to de-hackify streamline_config.pl.

Sure built-in is still a problem, but the current logic in
streamline_config.pl to keep that enabled seems sensible.

Part of another problem is the symbol renames that happen over
kernels, but if a map existed for this, then that should enable a
forward conversion. The GSoC effort was actually partly with a focus
on backporting, so this map would ultimately be important.

 Luis

Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Linus Torvalds]

On Tue, Jun 27, 2017 at 5:09 PM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
>
> The *easier* thing to do for now was to just map a loaded module to a
> kconfig symbol, and she proposed fairly simple patches to do this.

Well, localmodconfig does that today already.

And as mentioned, this is *not* even primarily about devices.

Devices are actually the easy case. Not only are they generally fairly
easy to enumerate (ie lsusb etc), they are things that people are at
least more or less aware of.

The config options that don't enable drivers, but enable particular
behavior - *those* are actually the nastiest ones.

And you don't see those in module names (well, you obviously sometimes
do, since the module might be what implements the behavior, but quite
often it's a built-in or just a setting for a module)

                 Linus

Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Luis R. Rodriguez]

On Tue, Jun 27, 2017 at 5:14 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> The config options that don't enable drivers, but enable particular
> behavior - *those* are actually the nastiest ones.

Ah yes... addressing this with the meta thingy would certainly be
nice. It can help close one of the big gaps and flaws of
localmodconfig.

  Luis

Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Stephen Hemminger]

On Tue, 27 Jun 2017 17:26:03 -0700
"Luis R. Rodriguez" <mcgrof@kernel.org> wrote:

> On Tue, Jun 27, 2017 at 5:14 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > The config options that don't enable drivers, but enable particular
> > behavior - *those* are actually the nastiest ones.  
> 
> Ah yes... addressing this with the meta thingy would certainly be
> nice. It can help close one of the big gaps and flaws of
> localmodconfig.
> 

I also run into issues with things like USB sticks with FAT filesystem.
If no stick has been plugged in the module isn't loaded, and therefore the module
doesn't get included. This is a general problem with hot pluggable hardware.

Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Matthew Wilcox]

[-- Attachment #1: Type: text/plain, Size: 358 bytes --]

Networking options are a similar pain. When we were doing prebuilt kernels
for the parisc port, the most frequent request was to enable random network
things.

On 27 Jun 2017 20:14, "Linus Torvalds" <torvalds@linux-foundation.org>
wrote:

The config options that don't enable drivers, but enable particular
behavior - *those* are actually the nastiest ones.

[-- Attachment #2: Type: text/html, Size: 770 bytes --]

Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Geert Uytterhoeven]

On Wed, Jun 28, 2017 at 2:14 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Tue, Jun 27, 2017 at 5:09 PM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
>> The *easier* thing to do for now was to just map a loaded module to a
>> kconfig symbol, and she proposed fairly simple patches to do this.
>
> Well, localmodconfig does that today already.
>
> And as mentioned, this is *not* even primarily about devices.
>
> Devices are actually the easy case. Not only are they generally fairly
> easy to enumerate (ie lsusb etc), they are things that people are at
> least more or less aware of.

Devices are indeed the easy part.  And on systems using DT, it's fairly easy
to find out which drivers you need to enable.
However, many drivers cannot be enabled without enabling a subsystem and
a few subsystem-specific options first.  Finding out which is already much
harder. E.g. the media subsystem has many of these.

> The config options that don't enable drivers, but enable particular
> behavior - *those* are actually the nastiest ones.
>
> And you don't see those in module names (well, you obviously sometimes
> do, since the module might be what implements the behavior, but quite
> often it's a built-in or just a setting for a module)

Module names assume you already have a running system to get a list of modules.
I don't want to go into systemd bashing (you can probably find other examples),
but when a Debian upgrade pulled in systemd, I had a hard time finding out
which Kconfig options I had to enable to make the system boot again.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Mauro Carvalho Chehab]

Em Wed, 28 Jun 2017 19:56:01 +0200
Geert Uytterhoeven <geert@linux-m68k.org> escreveu:

> On Wed, Jun 28, 2017 at 2:14 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > On Tue, Jun 27, 2017 at 5:09 PM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:  
> >> The *easier* thing to do for now was to just map a loaded module to a
> >> kconfig symbol, and she proposed fairly simple patches to do this.  
> >
> > Well, localmodconfig does that today already.
> >
> > And as mentioned, this is *not* even primarily about devices.
> >
> > Devices are actually the easy case. Not only are they generally fairly
> > easy to enumerate (ie lsusb etc), they are things that people are at
> > least more or less aware of.  

That depends. When the devices don't have I2C buses, this is usually
trivial. However, when then have it, it not uncommon that the same
USB/PCI ID to be shipped with different I2C chips for the same function.

That is the case of media drivers: the support for, let's say, a TV
device usually requires 3 or 4 different drivers, one bridge driver
and multiple I2C drivers.

To make things worse, the same brand name and PCI/USB ID is sometimes
shipped with different TV decoders if they're manufactured for Europe,
US, Asia or South America market. There are even some cases where
the same USB ID (with different BCD revision) use completely different
bridge drivers.

> 
> Devices are indeed the easy part.  And on systems using DT, it's fairly easy
> to find out which drivers you need to enable.
> However, many drivers cannot be enabled without enabling a subsystem and
> a few subsystem-specific options first.  Finding out which is already much
> harder. E.g. the media subsystem has many of these.

The media subsystem is harder for DT-based drivers, because it has no
way to know what I2C devices some bridge driver would use. Basically,
any bridge driver could, in thesis, use any available camera sensor.

For PC (e. g. non-platform devices), what's equivalent to DT is hardcoded
at the bridge driver: it has to explicitly bind each I2C device used
on it.

As such driver dependency is known by the Kernel module, we do lots of
efforts to make easier for users to select what they want, trying to
avoid technical questins. That actually required us a lot of magic at 
Kconfig dialect, because select is not recursive. So, we had to do
some sort of "reverse polish notation" type of thing, where possible, in
order to convert select into depends on. Ugly, and harder to maintain,
but it works on several cases.

In the past, the Kconfig questions there were if the user wanted V4L,
V4L2  and/or DVB API, and then a series of other technical questions. 
Now, it starts by asking if the user wants to enable a functionality
visible to him (camera/video, analog TV, digital TV, radio, etc),
with is something that the user likely knows how to answer. With that,
it allows to select adapter per their bus (USB, PCI).

There are still a bunch of more technical questions, though, that we
could possible avoid if were there some Kconfig option that would
tell that the user wants a "simplified" version as he would be compiling
the kernel for a PC or a Laptop.

Yet, the user has to know if his "Win TV" board uses bt8xx, cx88,
cx231xx, em28xx... chipset. 

That's not an easy question for the user. We have a wiki to help,
and we document the PCI/USB IDs for several commonly used drivers.

Once the driver is selected, by default, Kconfig enables the option
"Autoselect ancillary drivers", with basically means that, if the user
selects, for example, the em28xx driver, all possible combinations
of tuners and other I2C devices that all em28xx boards supports
will be selected.

Not optimal, but that warrants that, if the user has an em28xx
driver, it will work out of the box, no matter what variant he
has, preventing us to ask what tuner, analog TV demod, digital TV
demod, camera sensor... such hardware has.

An improvement would be to let the user tell what boards he has
(either via PCI/USB ID running some ancillary script or by presenting 
him a menu of all supported hardware per brand name.

We would likely need a list of all supported boards by their 
brand names (we have that already hardcoded at drivers - either as
string names or as comments), and likely a SAT solver, in order 
to allow selecting the needed drivers for such board.

-

Anyway, if you think selecting media drivers for DT-based drivers is
hard, perhaps you could take a look at the current approach and see
how to extend it to the DT case.

I guess we would need some sort of script that would inspect all
DT files and convert their dependencies into something that we could
import to Kconfig in a way that, for example, one selects OMAP3 driver,
it would, by default, select all sensors that this driver uses, 
according with the existing DT files.

> 
> > The config options that don't enable drivers, but enable particular
> > behavior - *those* are actually the nastiest ones.
> >
> > And you don't see those in module names (well, you obviously sometimes
> > do, since the module might be what implements the behavior, but quite
> > often it's a built-in or just a setting for a module)  
> 
> Module names assume you already have a running system to get a list of modules.
> I don't want to go into systemd bashing (you can probably find other examples),
> but when a Debian upgrade pulled in systemd, I had a hard time finding out
> which Kconfig options I had to enable to make the system boot again.
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss



Thanks,
Mauro

Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Linus Torvalds]

On Tue, Jun 27, 2017 at 4:10 PM, Serge E. Hallyn <serge@hallyn.com> wrote:
> Quoting Linus Torvalds (torvalds@linux-foundation.org):
>> For example, how about a script that takes a list of PCI devices, and
>
> Or uses lspci and lsusb output?

Well, you'd probably want to do "cross configurations" in many
situations, but yes, have the script fall back to just doing the local
thing.

That said, I really think that for hotpluggable things (ie usb, but
also obviously hotpluggable PCIe through
USB-C/TB3/whateveritscalledtoday), you should strive to not just look
at "right now" but also history. That's where a log of historical udev
events or whatever could be very useful.

            Linus

Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Mauro Carvalho Chehab]

Em Tue, 27 Jun 2017 14:36:44 -0700
Linus Torvalds <torvalds@linux-foundation.org> escreveu:

> On Tue, Jun 27, 2017 at 2:16 PM, Olof Johansson <olof@lixom.net> wrote:
> >
> > It sounds to me like you want to turn it from option/driver selection
> > to feature selection, where features could be stuff like:
> >
> > So, a meta config layer if seen in the context of our current config system.  
> 
> Yes.
> 
> Most people are really bad at knowing details, but they may well know
> some big-picture stuff. They can certainly answer questions like "do
> you have a laptop", and "does it have a PCMCIA card slot".
> 
> They might even be able to answer some HW specifics ("Is it 64-bit?"
> "Is the CPU an Intel/AMD or ARM chip?").

Perhaps we could add some "hint" questions at the very beginning of Kconfig
that would give some hints about the kind of usage the user expects.

E. g. asking if the Kernel is for the local machine. If so, it could look at
the cpu model at /proc/cpuinfo and take a set of defaults for that
specific model.

It could also have menu selections that would allow to select the type
of usage (customer PC, laptop, server, custom hardware, ...) and the
distro, in order to load some specific set of defaults for ARCH and
core-dependent features, and allow taking some "hints" at driver's level.

With those hints subsystem Kconfigs could use such information to take
automatic decisions about what should be enabled by default, and even
hide technical questions.

That's easier said than done, as implementing the hints logic can be
painful.

If we take such way, one open question is wow to tell Kconfig to read
/proc/cpuinfo or to run lspci/lsusb. Perhaps the simplest way would be
to add some dialect at Kconfig that would make it run a script if 
a Kconfig symbol has its value changed, and restart Kconfig after
the end of the script. This way, such script could internally modify
.config, in order to tweak the defaults.

Thanks,
Mauro

Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Dan Carpenter]

On Tue, Jun 27, 2017 at 08:44:48PM +0200, Luis R. Rodriguez wrote:
>   * We all seem to have decided having *both* depends and select is dumb.
>     So we decided we could remove select but fix tools first to give you
>     what you need:

They're totally different and both make sense.  You can select a library
but you can select an ARM.  Select is for hiding infratructure that
users don't care about and depend is for hiding features that users
can't have.

regards,
dan carpetner

Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Steven Rostedt]

On Tue, 27 Jun 2017 10:18:04 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> We could *maybe* make it part of some "make simpleconfig" that just
> basically uses "select" a lot with s special architecture-specific
> Kconfig file, and try to help people with a few bigger questions.

Actually, I think something can be done quite easily today without much
modifications.

What about a: make profileconfig

And add at the top of make menuconfig menu: Profiles

Which the "make profileconfig" will only look at that.

The Porfile section will only contain profiles. Which would be human
readable options (what the hell is "Big Bang thermal governor" anyway?).

That is:

 Profiles:

    Virtualization:

           KVM <menu>
              Intel
              AMD
              Both

           Paravirt


    Networking:

           Firewall
           [...]

    Power Management:

           [...]

    File systems:

          Ext

          [...]


Etc, etc

None of these options should become a CONFIG_*. That is, no code in the
kernel should have CONFIG_VIRTUALIZATION, as these profiles wont create
a CONFIG_ define. But instead, each of these will select all the
necessary options to support what it wants.

I will say, it may enable more than you ask for. But at least I believe
something like this would be a start. Then you only need to select a
few options and it will enable everything you need to have it work.

The profiles should only be what a normal person would ask for in a
kernel. Yes, I want USB storage, Yes I want PCI support, Yes I want a
firewall. No I don't want SElinux (sorry). No I don't want encrypted
filesystems (ok this is for a test box, I don't care about security or
privacy).

etc etc 

-- Steve

Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Darren Hart]

On Tue, Jun 27, 2017 at 10:18:04AM -0700, Linus Torvalds wrote:
> On Tue, Jun 27, 2017 at 6:58 AM, Sergey Senozhatsky
> <sergey.senozhatsky.work@gmail.com> wrote:
> >
> > am I the only one who struggle with the Kconfig sometimes?
> 
> I hate our Kconfig. It's my least favorite part of the kernel. It asks
> questions about insane things that nobody can know the answer to.
> 
> Taking a distro default config and doing"make localmodconfig" is what
> I end up doing on new machines, and it has all kinds of suckage too.
> 
> I don't have a solution to it. But I think part of the solution would
> be for us to have various "sane minimal requirement" Kconfig
> fragments, and trhe ability to feed them incrementally, so that people
> can build up a sane Kconfig from "I want this".

This was, in part, the intent behind the configuration fragments and the
merge_config.sh script. I use this with the x86 platform drivers:

$ make defconfig pdx86.config

But I have to generate, also scripted, the pdx86.config by scraping the
Kconfig file. The kvm_guest.config. There are other things I would like
to see subconfigs for, like "efi.config" - but I wasn't sure what the
current view on such things were. I'm glad to know I'm not along in my
frustration with the overly granular nature of Kconfig.

The problem with this model of course is keeping the config fragments
current with Kconfig changes. The mergeconfig script does call out
problems with specified config options. We can address this with
a configcheck target or similar which would audit the config fragments
to ensure they are kept in sync with the Kconfig files.

...

> 
> And note that none of this is about technoliogy, and SAT solvers and
> resolving the KConfig depdendencies that some techie people love
> talking about. It's all about "what if we just had some kconfig
> fragments to enable some commonly used stuff" (where "commonly used"
> is obviously architecture dependent, but also target-dependent - a
> "simpleconfig" for a PC workstation kind of config is very different
> from a "simpleconfig" for a server or some ARM embedded thing).
> 

It sounds like the existing config fragment mechanism is sufficient for
what you describe and what we need to do is create these fragments.

One thing that would be nice is if we could have fragment nesting so you
could create your "simpleconfig" which in turn includes a few of the
more specific config fragments.

-- 
Darren Hart
VMware Open Source Technology Center

Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Darren Hart]

On Fri, Jun 30, 2017 at 10:52:01AM -0700, Darren Hart wrote:
> On Tue, Jun 27, 2017 at 10:18:04AM -0700, Linus Torvalds wrote:
> > On Tue, Jun 27, 2017 at 6:58 AM, Sergey Senozhatsky
> > <sergey.senozhatsky.work@gmail.com> wrote:
> > >
> > > am I the only one who struggle with the Kconfig sometimes?
> > 
> > I hate our Kconfig. It's my least favorite part of the kernel. It asks
> > questions about insane things that nobody can know the answer to.
> > 
> > Taking a distro default config and doing"make localmodconfig" is what
> > I end up doing on new machines, and it has all kinds of suckage too.
> > 
> > I don't have a solution to it. But I think part of the solution would
> > be for us to have various "sane minimal requirement" Kconfig
> > fragments, and trhe ability to feed them incrementally, so that people
> > can build up a sane Kconfig from "I want this".
> 
> This was, in part, the intent behind the configuration fragments and the
> merge_config.sh script. I use this with the x86 platform drivers:
> 
> $ make defconfig pdx86.config
> 
> But I have to generate, also scripted, the pdx86.config by scraping the
> Kconfig file. The kvm_guest.config. There are other things I would like
> to see subconfigs for, like "efi.config" - but I wasn't sure what the
> current view on such things were. I'm glad to know I'm not along in my
> frustration with the overly granular nature of Kconfig.
> 
> The problem with this model of course is keeping the config fragments
> current with Kconfig changes. The mergeconfig script does call out
> problems with specified config options. We can address this with
> a configcheck target or similar which would audit the config fragments
> to ensure they are kept in sync with the Kconfig files.
> 
> ...
> 
> > 
> > And note that none of this is about technoliogy, and SAT solvers and
> > resolving the KConfig depdendencies that some techie people love
> > talking about. It's all about "what if we just had some kconfig
> > fragments to enable some commonly used stuff" (where "commonly used"
> > is obviously architecture dependent, but also target-dependent - a
> > "simpleconfig" for a PC workstation kind of config is very different
> > from a "simpleconfig" for a server or some ARM embedded thing).
> > 
> 
> It sounds like the existing config fragment mechanism is sufficient for
> what you describe and what we need to do is create these fragments.
> 
> One thing that would be nice is if we could have fragment nesting so you
> could create your "simpleconfig" which in turn includes a few of the
> more specific config fragments.

We could also have a simple config view for the make *config UIs which
would enumerate all the config fragments, perhaps with some meta data so
they are self descriptive, and then it runs upon save:

$ make minconfig foo.config bar.config kvm.config efi.config dell.config

-- 
Darren Hart
VMware Open Source Technology Center

Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Hannes Reinecke]

On 06/30/2017 07:52 PM, Darren Hart wrote:
> On Tue, Jun 27, 2017 at 10:18:04AM -0700, Linus Torvalds wrote:
>> On Tue, Jun 27, 2017 at 6:58 AM, Sergey Senozhatsky
>> <sergey.senozhatsky.work@gmail.com> wrote:
>>>
>>> am I the only one who struggle with the Kconfig sometimes?
>>
>> I hate our Kconfig. It's my least favorite part of the kernel. It asks
>> questions about insane things that nobody can know the answer to.
>>
>> Taking a distro default config and doing"make localmodconfig" is what
>> I end up doing on new machines, and it has all kinds of suckage too.
>>
>> I don't have a solution to it. But I think part of the solution would
>> be for us to have various "sane minimal requirement" Kconfig
>> fragments, and trhe ability to feed them incrementally, so that people
>> can build up a sane Kconfig from "I want this".
> 
> This was, in part, the intent behind the configuration fragments and the
> merge_config.sh script. I use this with the x86 platform drivers:
> 
> $ make defconfig pdx86.config
> 
> But I have to generate, also scripted, the pdx86.config by scraping the
> Kconfig file. The kvm_guest.config. There are other things I would like
> to see subconfigs for, like "efi.config" - but I wasn't sure what the
> current view on such things were. I'm glad to know I'm not along in my
> frustration with the overly granular nature of Kconfig.
> 
> The problem with this model of course is keeping the config fragments
> current with Kconfig changes. The mergeconfig script does call out
> problems with specified config options. We can address this with
> a configcheck target or similar which would audit the config fragments
> to ensure they are kept in sync with the Kconfig files.
> 
> ...
> 
>>
>> And note that none of this is about technoliogy, and SAT solvers and
>> resolving the KConfig depdendencies that some techie people love
>> talking about. It's all about "what if we just had some kconfig
>> fragments to enable some commonly used stuff" (where "commonly used"
>> is obviously architecture dependent, but also target-dependent - a
>> "simpleconfig" for a PC workstation kind of config is very different
>> from a "simpleconfig" for a server or some ARM embedded thing).
>>
> 
> It sounds like the existing config fragment mechanism is sufficient for
> what you describe and what we need to do is create these fragments.
> 
> One thing that would be nice is if we could have fragment nesting so you
> could create your "simpleconfig" which in turn includes a few of the
> more specific config fragments.
> 
And what would be totally cool if we could have fragments _per default_.
EG by not having a massive .config, but rather keeping it per directory,
or maybe corresponding in the directory where each Kconfig lives.
That way it would be easier to figure out where this blasted option cam
from, plus one could easily provide (and check!) configurations for
several systems, keeping the common parts intact and modify only the
machine specific ones.

And it would solve the 'keeping the config current' problem, as one
could quite simply identify which configuration will need to be changed
for a Kconfig change, seeing that both will be kept in the same directory.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		   Teamlead Storage & Networking
hare@suse.com			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Kees Cook]

On Tue, Jun 27, 2017 at 6:58 AM, Sergey Senozhatsky
<sergey.senozhatsky.work@gmail.com> wrote:
> Hello,
>
> am I the only one who struggle with the Kconfig sometimes? can there
> be a way to make it more general/simpler, in some parts at least? e.g.
> the hardening effort? (just an example. *ABSOLUTELY NOT* blaming Kess
> or anyone else who is involved, that's not the point, they are doing
> great job, no doubt. it's just the most recent thing I saw was
> CONFIG_SLAB_MERGE_DEFAULT). do people who really want to harden their
> kernels go all-in anyway (enable all of the options at once)? if so,
> can there be a single Kconfig option then? just curious.

We've removed failed "single Kconfig options" in the past (e.g.
CONFIG_EXPERIMENTAL), so I'm not excited about trying that again. I
agree with Linus, though, Kconfig is still a mess.

As for why I think CONFIG_HARDENED specifically wouldn't work is
because of distro tolerances for security features. Some things are
"too much" for them (e.g. slab sanitization), but they want things
with lower overhead (e.g. hardened usercopy). And if one feature is
going to be under CONFIG_HARDENED, but not the other, then why not? Do
we then need CONFIG_HARDENED_A_LITTLE and CONFIG_HARDENED_PARANOID?
And then that'll get bike-shed too. Ultimately providing granularity
appears to be better than not providing it, but we still end up with
the mess that in Kconfig... :(

(I see mention of "make def..." in other replies, I'll comment there next...)

-Kees

-- 
Kees Cook
Pixel Security

Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Dan Carpenter]

People have mentioned "make oldconfig" but I've never had a lot of luck
with that.  It always just prints "* Restart config..." and deletes my
config.

Also I hate menus.  It's such a pain if you want to enable a feature and
you have to do a dungeon crawl through our menu system to try find it.

I wrote a script a couple years ago to create kernel configs.  I do a
make defconfig, then I take a distro config and I do:

    for i in $(grep =m old_config) ; do
	./scripts/kconfig/kconfig set $i
    done

This prints a lot of errors and the code is only half implemented but
it's honestly the easiest way for me to get a bootable kernel these
days.  If someone wanted to the could add a "./scripts/kconfig/kconfig
file <name>" command that would read a line at a time and call
`./scripts/kconfig/kconfig set $line` over and over.

regards,
dan carpenter

[Ksummit-discuss] [PATCH 1/2] kconfig: add a silent option to conf_write()

[Dan Carpenter]

The conf_write() function prints output "configuration written to .config" but
I don't want it to print anything so I have added an option for that.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
 scripts/kconfig/conf.c      | 4 ++--
 scripts/kconfig/confdata.c  | 5 +++--
 scripts/kconfig/gconf.c     | 4 ++--
 scripts/kconfig/lkc_proto.h | 2 +-
 scripts/kconfig/mconf.c     | 4 ++--
 scripts/kconfig/nconf.c     | 4 ++--
 6 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c
index 866369f10ff8..c73b5ab859a2 100644
--- a/scripts/kconfig/conf.c
+++ b/scripts/kconfig/conf.c
@@ -690,7 +690,7 @@ int main(int ac, char **av)
 		/* silentoldconfig is used during the build so we shall update autoconf.
 		 * All other commands are only used to generate a config.
 		 */
-		if (conf_get_changed() && conf_write(NULL)) {
+		if (conf_get_changed() && conf_write(NULL, 0)) {
 			fprintf(stderr, _("\n*** Error during writing of the configuration.\n\n"));
 			exit(1);
 		}
@@ -705,7 +705,7 @@ int main(int ac, char **av)
 			return 1;
 		}
 	} else if (input_mode != listnewconfig) {
-		if (conf_write(NULL)) {
+		if (conf_write(NULL, 0)) {
 			fprintf(stderr, _("\n*** Error during writing of the configuration.\n\n"));
 			exit(1);
 		}
diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
index 297b079ae4d9..7e8dbae6af30 100644
--- a/scripts/kconfig/confdata.c
+++ b/scripts/kconfig/confdata.c
@@ -738,7 +738,7 @@ int conf_write_defconfig(const char *filename)
 	return 0;
 }
 
-int conf_write(const char *name)
+int conf_write(const char *name, bool silent)
 {
 	FILE *out;
 	struct symbol *sym;
@@ -831,7 +831,8 @@ int conf_write(const char *name)
 			return 1;
 	}
 
-	conf_message(_("configuration written to %s"), newname);
+	if (!silent)
+		conf_message(_("configuration written to %s"), newname);
 
 	sym_set_change_count(0);
 
diff --git a/scripts/kconfig/gconf.c b/scripts/kconfig/gconf.c
index cfddddb9c9d7..115b5602d05e 100644
--- a/scripts/kconfig/gconf.c
+++ b/scripts/kconfig/gconf.c
@@ -523,7 +523,7 @@ void on_load1_activate(GtkMenuItem * menuitem, gpointer user_data)
 
 void on_save_activate(GtkMenuItem * menuitem, gpointer user_data)
 {
-	if (conf_write(NULL))
+	if (conf_write(NULL), 0)
 		text_insert_msg(_("Error"), _("Unable to save configuration !"));
 }
 
@@ -536,7 +536,7 @@ store_filename(GtkFileSelection * file_selector, gpointer user_data)
 	fn = gtk_file_selection_get_filename(GTK_FILE_SELECTION
 					     (user_data));
 
-	if (conf_write(fn))
+	if (conf_write(fn), 0)
 		text_insert_msg(_("Error"), _("Unable to save configuration !"));
 
 	gtk_widget_destroy(GTK_WIDGET(user_data));
diff --git a/scripts/kconfig/lkc_proto.h b/scripts/kconfig/lkc_proto.h
index d5398718ec2a..1690888bdbc4 100644
--- a/scripts/kconfig/lkc_proto.h
+++ b/scripts/kconfig/lkc_proto.h
@@ -5,7 +5,7 @@ void conf_parse(const char *name);
 int conf_read(const char *name);
 int conf_read_simple(const char *name, int);
 int conf_write_defconfig(const char *name);
-int conf_write(const char *name);
+int conf_write(const char *name, bool silent);
 int conf_write_autoconf(void);
 bool conf_get_changed(void);
 void conf_set_changed_callback(void (*fn)(void));
diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
index 315ce2c7cb9d..c029b5417fa9 100644
--- a/scripts/kconfig/mconf.c
+++ b/scripts/kconfig/mconf.c
@@ -937,7 +937,7 @@ static void conf_save(void)
 		case 0:
 			if (!dialog_input_result[0])
 				return;
-			if (!conf_write(dialog_input_result)) {
+			if (!conf_write(dialog_input_result, 0)) {
 				set_config_filename(dialog_input_result);
 				return;
 			}
@@ -971,7 +971,7 @@ static int handle_exit(void)
 
 	switch (res) {
 	case 0:
-		if (conf_write(filename)) {
+		if (conf_write(filename, 0)) {
 			fprintf(stderr, _("\n\n"
 					  "Error while writing of the configuration.\n"
 					  "Your configuration changes were NOT saved."
diff --git a/scripts/kconfig/nconf.c b/scripts/kconfig/nconf.c
index 003114779815..b4b0666bdc4c 100644
--- a/scripts/kconfig/nconf.c
+++ b/scripts/kconfig/nconf.c
@@ -666,7 +666,7 @@ static int do_exit(void)
 	/* if we got here, the user really wants to exit */
 	switch (res) {
 	case 0:
-		res = conf_write(filename);
+		res = conf_write(filename, 0);
 		if (res)
 			btn_dialog(
 				main_window,
@@ -1436,7 +1436,7 @@ static void conf_save(void)
 		case 0:
 			if (!dialog_input_result[0])
 				return;
-			res = conf_write(dialog_input_result);
+			res = conf_write(dialog_input_result, 0);
 			if (!res) {
 				set_config_filename(dialog_input_result);
 				return;
-- 
2.11.0

Re: [Ksummit-discuss] [PATCH 1/2] kconfig: add a silent option to conf_write()

[Steven Rostedt]

On Thu, 6 Jul 2017 17:41:16 +0300
Dan Carpenter <dan.carpenter@oracle.com> wrote:

> The conf_write() function prints output "configuration written to .config" but
> I don't want it to print anything so I have added an option for that.
> 
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---

I know you replied to the TECH TOPIC about kconfig, but did you really
mean to send patches to the ksummit-discuss mailing list and not to any
other mailing list (like LKML or linux-kbuild@vger.kernel.org)?

-- Steve

[Ksummit-discuss] [PATCH 2/2] kconfig: new command line kernel configuration tool

[Dan Carpenter]

This tool barely works, it's just a rough draft.

Sometimes I want to search for a config so I have to load menuconfig,
then search for the config entry, then exit.  With this script I
simply run:

    ./scripts/kconfig/kconfig search COMEDI

Quite often I find myself trying to enable a feature by doing this:

    echo CONFIG_FEATURE=y >> .config

But when I try to boot the new kernel, I find that the feature isn't
there because the kernel runs `make oldconfig` and I didn't have all
the depends selected so it silently removed it.  With this feature
what you can do is:

    ./scripts/kconfig/kconfig set FEATURE=y

It helps you enable the dependencies or it at least prints an error
if it can't enable the feature.

But this code isn't all implemented.  1) It doesn't calculate the
dependencies well.  See expr_parse() for more details.  2)  It
doesn't work well for things like:

	./scripts/kconfig/kconfig set BT_INTEL=m

because those aren't visible, they can only be using depend
statements.  Or say you try to set FEATURE=m when something else
depends on it be set =y then the error message is wrong.  The
other problem is that I don't know how to print the help text.
Again, this is just a rough draft.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
 scripts/kconfig/Makefile |   6 +-
 scripts/kconfig/kconfig  |  33 +++++
 scripts/kconfig/lconf.c  | 332 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 370 insertions(+), 1 deletion(-)
 create mode 100755 scripts/kconfig/kconfig
 create mode 100644 scripts/kconfig/lconf.c

diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index eb8144643b78..a2a90be2e149 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -33,6 +33,9 @@ config: $(obj)/conf
 nconfig: $(obj)/nconf
 	$< $(silent) $(Kconfig)
 
+lconfig: $(obj)/lconf
+	@ $< $(silent) $(Kconfig)
+
 silentoldconfig: $(obj)/conf
 	$(Q)mkdir -p include/config include/generated
 	$(Q)test -e include/generated/autoksyms.h || \
@@ -183,12 +186,13 @@ lxdialog += lxdialog/textbox.o lxdialog/yesno.o lxdialog/menubox.o
 conf-objs	:= conf.o  zconf.tab.o
 mconf-objs     := mconf.o zconf.tab.o $(lxdialog)
 nconf-objs     := nconf.o zconf.tab.o nconf.gui.o
+lconf-objs     := lconf.o zconf.tab.o
 kxgettext-objs	:= kxgettext.o zconf.tab.o
 qconf-cxxobjs	:= qconf.o
 qconf-objs	:= zconf.tab.o
 gconf-objs	:= gconf.o zconf.tab.o
 
-hostprogs-y := conf nconf mconf kxgettext qconf gconf
+hostprogs-y := conf nconf mconf kxgettext qconf gconf lconf
 
 clean-files	:= qconf.moc .tmp_qtcheck .tmp_gtkcheck
 clean-files	+= zconf.tab.c zconf.lex.c zconf.hash.c gconf.glade.h
diff --git a/scripts/kconfig/kconfig b/scripts/kconfig/kconfig
new file mode 100755
index 000000000000..beab8fc829c9
--- /dev/null
+++ b/scripts/kconfig/kconfig
@@ -0,0 +1,33 @@
+#!/bin/sh
+
+usage() {
+	echo "kconfig [search|set] string"
+	exit 1;
+}
+
+if [ "$1" = "" ] ; then
+	usage
+fi
+
+if [ "$1" = "search" ] ; then
+
+	search=$2
+	NCONFIG_MODE=kconfig_search SEARCH=${search} make lconfig
+
+elif [ "$1" = "set" ] ; then
+
+	config=$2
+	setting=$3
+
+	if [ $config = "" ] ; then
+		echo "nothing to set"
+		exit 1
+	fi
+
+	NCONFIG_MODE=kconfig_set CONFIG=${config} SETTING=${setting} make lconfig
+
+else
+	usage
+fi
+
+
diff --git a/scripts/kconfig/lconf.c b/scripts/kconfig/lconf.c
new file mode 100644
index 000000000000..ebc3cbd4ef83
--- /dev/null
+++ b/scripts/kconfig/lconf.c
@@ -0,0 +1,332 @@
+/*
+ * Copyright (C) 2015 Oracle
+ * Released under the terms of the GNU GPL v2.0.
+ *
+ */
+#define _GNU_SOURCE
+#include <string.h>
+#include <stdlib.h>
+
+#include "lkc.h"
+#include "nconf.h"
+#include <ctype.h>
+
+static int indent;
+static char line[128];
+
+static int get_depends(struct symbol *sym);
+
+static void strip(char *str)
+{
+	char *p = str;
+	int l;
+
+	while ((isspace(*p)))
+		p++;
+	l = strlen(p);
+	if (p != str)
+		memmove(str, p, l + 1);
+	if (!l)
+		return;
+	p = str + l - 1;
+	while ((isspace(*p)))
+		*p-- = 0;
+}
+
+static void xfgets(char *str, int size, FILE *in)
+{
+	if (fgets(str, size, in) == NULL)
+		fprintf(stderr, "\nError in reading or end of file.\n");
+}
+
+static tristate str_to_tristate(const char *str)
+{
+	switch (str[0]) {
+	case 'y': case 'Y':
+		return yes;
+	case 'm': case 'M':
+		return mod;
+	case 'n': case 'N':
+	default:
+		return no;
+	}
+}
+
+static int conf_askvalue(struct symbol *sym, const char *def)
+{
+	enum symbol_type type = sym_get_type(sym);
+
+	if (!sym_has_value(sym))
+		printf(_("(NEW) "));
+
+	line[0] = '\n';
+	line[1] = 0;
+
+	if (!sym_is_changable(sym)) {
+		printf("%s\n", def);
+		line[0] = '\n';
+		line[1] = 0;
+		return 0;
+	}
+
+	fflush(stdout);
+	xfgets(line, 128, stdin);
+
+	switch (type) {
+	case S_INT:
+	case S_HEX:
+	case S_STRING:
+		printf("%s\n", def);
+		return 1;
+	default:
+		;
+	}
+	printf("%s", line);
+	return 1;
+}
+
+static struct property *get_symbol_prop(struct symbol *sym)
+{
+	struct property *prop = NULL;
+
+	for_all_properties(sym, prop, P_SYMBOL)
+		break;
+	return prop;
+}
+
+static int conf_sym(struct symbol *sym)
+{
+	tristate oldval, newval;
+	struct property *prop;
+
+	while (1) {
+		if (sym->name)
+			printf("%s: ", sym->name);
+		for_all_prompts(sym, prop)
+			printf("%*s%s ", indent - 1, "",  _(prop->text));
+		putchar('[');
+		oldval = sym_get_tristate_value(sym);
+		switch (oldval) {
+		case no:
+			putchar('N');
+			break;
+		case mod:
+			putchar('M');
+			break;
+		case yes:
+			putchar('Y');
+			break;
+		}
+		if (oldval != no && sym_tristate_within_range(sym, no))
+			printf("/n");
+		if (oldval != mod && sym_tristate_within_range(sym, mod))
+			printf("/m");
+		if (oldval != yes && sym_tristate_within_range(sym, yes))
+			printf("/y");
+		/* FIXME: I don't know how to get the help text from the sym */
+		printf("] ");
+		if (!conf_askvalue(sym, sym_get_string_value(sym)))
+			return 0;
+		strip(line);
+
+		switch (line[0]) {
+		case 'n':
+		case 'N':
+			newval = no;
+			if (!line[1] || !strcmp(&line[1], "o"))
+				break;
+			continue;
+		case 'm':
+		case 'M':
+			newval = mod;
+			if (!line[1])
+				break;
+			continue;
+		case 'y':
+		case 'Y':
+			newval = yes;
+			if (!line[1] || !strcmp(&line[1], "es"))
+				break;
+			continue;
+		case 0:
+			newval = oldval;
+			break;
+		default:
+			continue;
+		}
+		if (sym_set_tristate_value(sym, newval)) {
+			/* FIXME: if I don't write it doesn't save */
+			conf_write(NULL, 1);
+			return 1;
+		}
+	}
+}
+
+static int enable_sym(struct symbol *sym)
+{
+	if (sym_get_tristate_value(sym) != no)
+		return 0;
+
+	if (!sym->visible) {
+		if (!get_depends(sym))
+			return 0;
+		printf("%s: has missing dependencies\n", sym->name);
+	}
+
+	return conf_sym(sym);
+}
+
+static void expr_parse(struct expr *e)
+{
+	if (!e)
+		return;
+
+	switch (e->type) {
+	case E_EQUAL:
+		printf("set '%s' to '%s'\n", e->left.sym->name, e->right.sym->name);
+		break;
+
+	case E_AND:
+		expr_parse(e->left.expr);
+		expr_parse(e->right.expr);
+		break;
+
+	case E_SYMBOL:
+		enable_sym(e->left.sym);
+		break;
+
+	case E_NOT:
+	case E_UNEQUAL:
+	case E_OR:
+	case E_LIST:
+	case E_RANGE:
+	default:
+		printf("HELP.  Lot of unimplemented code.  %d\n", e->type);
+		break;
+	}
+}
+
+static int get_depends(struct symbol *sym)
+{
+	struct property *prop;
+	struct gstr res = str_new();
+
+	prop = get_symbol_prop(sym);
+	if (!prop)
+		return 0;
+
+	expr_gstr_print(prop->visible.expr, &res);
+	printf("%s\n\n", str_get(&res));
+
+	expr_parse(prop->visible.expr);
+
+	return 1;
+}
+
+static void kconfig_search(void)
+{
+	char *search_str;
+	struct symbol **sym_arr;
+	struct gstr res;
+
+	search_str = getenv("SEARCH");
+	if (!search_str)
+		return;
+
+	sym_arr = sym_re_search(search_str);
+	res = get_relations_str(sym_arr, NULL);
+	printf("%s", str_get(&res));
+}
+
+static void kconfig_set(void)
+{
+	struct symbol *sym;
+	char *config;
+	char *setting;
+	int res;
+
+	config = getenv("CONFIG");
+	if (!config)
+		return;
+	if (strncmp(config, "CONFIG_", 7) == 0)
+		config += 7;
+
+	setting = strchr(config, '=');
+	if (setting) {
+		*setting = '\0';
+		setting++;
+	} else {
+		setting = getenv("SETTING");
+		if (setting && *setting == '\0')
+			setting = NULL;
+	}
+
+	sym = sym_find(config);
+	if (!sym) {
+		printf("Error: '%s' not found.\n", config);
+		return;
+	}
+
+	if (sym->curr.tri == str_to_tristate(setting)) {
+		printf("Already set:  %s=%s\n", sym->name, setting);
+		return;
+	}
+
+	if (!sym->visible) {
+		printf("\n%s: has missing dependencies\n", sym->name);
+		if (!get_depends(sym))
+			return;
+	}
+	if (!sym->visible) {
+		printf("Error: unmet dependencies\n");
+		return;
+	}
+
+	if (!setting) {
+		conf_sym(sym);
+	} else if (!sym_set_string_value(sym, setting)) {
+		printf("Error: setting '%s=%s' failed.\n", sym->name, setting);
+		return;
+	}
+
+	res = conf_write(NULL, 1);
+	if (res) {
+		printf("Error during writing of configuration.\n"
+			"Your configuration changes were NOT saved.\n");
+		return;
+	}
+
+	printf("set: %s=%s\n", config, sym_get_string_value(sym));
+}
+
+int main(int ac, char **av)
+{
+	char *mode;
+
+	setlocale(LC_ALL, "");
+	bindtextdomain(PACKAGE, LOCALEDIR);
+	textdomain(PACKAGE);
+
+	if (ac > 1 && strcmp(av[1], "-s") == 0) {
+		/* Silence conf_read() until the real callback is set up */
+		conf_set_message_callback(NULL);
+		av++;
+	}
+	conf_parse(av[1]);
+	conf_read(NULL);
+
+	mode = getenv("NCONFIG_MODE");
+	if (!mode)
+		return 1;
+
+	if (strcmp(mode, "kconfig_search") == 0) {
+		kconfig_search();
+		return 0;
+	}
+	if (strcmp(mode, "kconfig_set") == 0) {
+		kconfig_set();
+		return 0;
+	}
+
+	return 1;
+}
-- 
2.11.0

Re: [Ksummit-discuss] [PATCH 2/2] kconfig: new command line kernel configuration tool

[Krzysztof Kozlowski]

On Thu, Jul 6, 2017 at 4:42 PM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> This tool barely works, it's just a rough draft.
>
> Sometimes I want to search for a config so I have to load menuconfig,
> then search for the config entry, then exit.  With this script I
> simply run:
>
>     ./scripts/kconfig/kconfig search COMEDI
>
> Quite often I find myself trying to enable a feature by doing this:
>
>     echo CONFIG_FEATURE=y >> .config
>
> But when I try to boot the new kernel, I find that the feature isn't
> there because the kernel runs `make oldconfig` and I didn't have all
> the depends selected so it silently removed it.  With this feature
> what you can do is:
>
>     ./scripts/kconfig/kconfig set FEATURE=y

Sounds useful. I need to enable few options from scripts and if
dependencies change they could be silently skipped.

Probably it would be nice to print what was effectively enabled to get
your feature in. However why not extending existing scripts/config? It
already has the feature for setting kconfig options (without looking
at dependencies - so like >> of yours).

Best regards,
Krzysztof

>
> It helps you enable the dependencies or it at least prints an error
> if it can't enable the feature.
>
> But this code isn't all implemented.  1) It doesn't calculate the
> dependencies well.  See expr_parse() for more details.  2)  It
> doesn't work well for things like:
>
>         ./scripts/kconfig/kconfig set BT_INTEL=m
>
> because those aren't visible, they can only be using depend
> statements.  Or say you try to set FEATURE=m when something else
> depends on it be set =y then the error message is wrong.  The
> other problem is that I don't know how to print the help text.
> Again, this is just a rough draft.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
>  scripts/kconfig/Makefile |   6 +-
>  scripts/kconfig/kconfig  |  33 +++++
>  scripts/kconfig/lconf.c  | 332 +++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 370 insertions(+), 1 deletion(-)
>  create mode 100755 scripts/kconfig/kconfig
>  create mode 100644 scripts/kconfig/lconf.c
>

Re: [Ksummit-discuss] [PATCH 2/2] kconfig: new command line kernel configuration tool

[Dan Carpenter]

On Fri, Jul 07, 2017 at 07:55:27AM +0200, Krzysztof Kozlowski wrote:
> On Thu, Jul 6, 2017 at 4:42 PM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> > This tool barely works, it's just a rough draft.
> >
> > Sometimes I want to search for a config so I have to load menuconfig,
> > then search for the config entry, then exit.  With this script I
> > simply run:
> >
> >     ./scripts/kconfig/kconfig search COMEDI
> >
> > Quite often I find myself trying to enable a feature by doing this:
> >
> >     echo CONFIG_FEATURE=y >> .config
> >
> > But when I try to boot the new kernel, I find that the feature isn't
> > there because the kernel runs `make oldconfig` and I didn't have all
> > the depends selected so it silently removed it.  With this feature
> > what you can do is:
> >
> >     ./scripts/kconfig/kconfig set FEATURE=y
> 
> Sounds useful. I need to enable few options from scripts and if
> dependencies change they could be silently skipped.
> 
> Probably it would be nice to print what was effectively enabled to get
> your feature in. However why not extending existing scripts/config? It
> already has the feature for setting kconfig options (without looking
> at dependencies - so like >> of yours).
> 

I didn't know about scripts/config when I wrote it.  scripts/config is
essentially a UI around "echo CONFIG_FOO=m >> .config".  It's totally
useless.

regards,
dan carpenter

Re: [Ksummit-discuss] [PATCH 2/2] kconfig: new command line kernel configuration tool

[Linus Walleij]

On Fri, Jul 7, 2017 at 11:02 AM, Dan Carpenter <dan.carpenter@oracle.com> wrote:

> Krzysztof Kozlowski wrote:
>> However why not extending existing scripts/config? It
>> already has the feature for setting kconfig options (without looking
>> at dependencies - so like >> of yours).
>
> I didn't know about scripts/config when I wrote it.  scripts/config is
> essentially a UI around "echo CONFIG_FOO=m >> .config".  It's totally
> useless.

Maybe useless for you but i use it every day in my work. To compile a kernel
for a purpose I have a custom makefile.mak in my top kernel dir
that calls scripts/config to set stuff up on-the-fly with multiple rules like
this:

config-base: FORCE
        @mkdir -p $(build_dir)
        @cp $(rootfs) $(build_dir)/$(rootfsbase)
        $(MAKE) $(make_options) u8500_defconfig

config-initramfs: have-rootfs config-base
        # Configure in the initramfs
        $(CURDIR)/scripts/config --file $(config_file) \
        --enable BLK_DEV_INITRD \
        --set-str INITRAMFS_SOURCE $(rootfsbase) \
        --enable RD_GZIP \
        --enable INITRAMFS_COMPRESSION_GZIP

(....)

config: config-common config-distro config-initramfs
        $(CURDIR)/scripts/config --file $(config_file) \
        --enable USE_OF \
        --enable ARM_APPENDED_DTB \
        --enable ARM_ATAG_DTB_COMPAT \
        --enable PROC_DEVICETREE
        yes "" | make $(make_options) oldconfig

For the full Makefile see:

https://dflund.se/~triad/krad/makefiles/ux500.mak

There are several of these, like some that create a minimal
i586 system with busybox on an initramfs:
https://dflund.se/~triad/krad/makefiles/i586.mak

I don't know if I am stupid in using this rather than config
fragments, but it works for me.

That said, what you have brewing looks better :)

Yours,
Linus Walleij

Re: [Ksummit-discuss] [PATCH 2/2] kconfig: new command line kernel configuration tool

[Geert Uytterhoeven]

On Sun, Jul 9, 2017 at 5:56 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
>> Krzysztof Kozlowski wrote:
>>> However why not extending existing scripts/config? It
>>> already has the feature for setting kconfig options (without looking
>>> at dependencies - so like >> of yours).
>>
>> I didn't know about scripts/config when I wrote it.  scripts/config is
>> essentially a UI around "echo CONFIG_FOO=m >> .config".  It's totally
>> useless.
>
> Maybe useless for you but i use it every day in my work. To compile a kernel

I assume the script has it uses.
But to scratch Dan's itch (and mine, for generating .config from DTS), which
is the non-trivial case, it may not work.
So I'll definitely give Dan's script a try, thanks!

>         yes "" | make $(make_options) oldconfig

That will become an infinite loop if "y" is not a valid answer for the newly
introduced option (e.g. if it needs a number)?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [Ksummit-discuss] [PATCH 2/2] kconfig: new command line kernel configuration tool

[Randy Dunlap]

On 07/09/2017 01:31 AM, Geert Uytterhoeven wrote:
> On Sun, Jul 9, 2017 at 5:56 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
>>> Krzysztof Kozlowski wrote:
>>>> However why not extending existing scripts/config? It
>>>> already has the feature for setting kconfig options (without looking
>>>> at dependencies - so like >> of yours).
>>>
>>> I didn't know about scripts/config when I wrote it.  scripts/config is
>>> essentially a UI around "echo CONFIG_FOO=m >> .config".  It's totally
>>> useless.
>>
>> Maybe useless for you but i use it every day in my work. To compile a kernel
> 
> I assume the script has it uses.
> But to scratch Dan's itch (and mine, for generating .config from DTS), which
> is the non-trivial case, it may not work.
> So I'll definitely give Dan's script a try, thanks!
> 
>>         yes "" | make $(make_options) oldconfig
> 
> That will become an infinite loop if "y" is not a valid answer for the newly
> introduced option (e.g. if it needs a number)?

yes ""
just answers with a null string, not 'y'.


-- 
~Randy

Re: [Ksummit-discuss] [PATCH 2/2] kconfig: new command line kernel configuration tool

[Geert Uytterhoeven]

On Sun, Jul 9, 2017 at 7:03 PM, Randy Dunlap <rdunlap@infradead.org> wrote:
> On 07/09/2017 01:31 AM, Geert Uytterhoeven wrote:
>> On Sun, Jul 9, 2017 at 5:56 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
>>>> Krzysztof Kozlowski wrote:
>>>>> However why not extending existing scripts/config? It
>>>>> already has the feature for setting kconfig options (without looking
>>>>> at dependencies - so like >> of yours).
>>>>
>>>> I didn't know about scripts/config when I wrote it.  scripts/config is
>>>> essentially a UI around "echo CONFIG_FOO=m >> .config".  It's totally
>>>> useless.
>>>
>>> Maybe useless for you but i use it every day in my work. To compile a kernel
>>
>> I assume the script has it uses.
>> But to scratch Dan's itch (and mine, for generating .config from DTS), which
>> is the non-trivial case, it may not work.
>> So I'll definitely give Dan's script a try, thanks!
>>
>>>         yes "" | make $(make_options) oldconfig
>>
>> That will become an infinite loop if "y" is not a valid answer for the newly
>> introduced option (e.g. if it needs a number)?
>
> yes ""
> just answers with a null string, not 'y'.

Oops, that's correct. /me on a lazy Sunday afternoon...
So the difficult part is "yes y" or "yes n".

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [Ksummit-discuss] [PATCH 2/2] kconfig: new command line kernel configuration tool

[Frank Rowand]

On 07/09/17 01:31, Geert Uytterhoeven wrote:
> On Sun, Jul 9, 2017 at 5:56 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
>>> Krzysztof Kozlowski wrote:
>>>> However why not extending existing scripts/config? It
>>>> already has the feature for setting kconfig options (without looking
>>>> at dependencies - so like >> of yours).
>>>
>>> I didn't know about scripts/config when I wrote it.  scripts/config is
>>> essentially a UI around "echo CONFIG_FOO=m >> .config".  It's totally
>>> useless.
>>
>> Maybe useless for you but i use it every day in my work. To compile a kernel
> 
> I assume the script has it uses.
> But to scratch Dan's itch (and mine, for generating .config from DTS), which
> is the non-trivial case, it may not work.

Hi Geert,

An aid, though not a full solution, is scripts/dtc/dt_to_config.  Though
if I remember correctly, you are already familiar with that.  For anyone
who wants more information on the complexities of using dt_to_config, how
to use it, and why it has difficulties providing a precise configuration
automatically, see: http://elinux.org/Device_Tree_presentations_papers_articles#linux_kernel_configuration
slides 33 - 80.

-Frank


> So I'll definitely give Dan's script a try, thanks!
> 
>>         yes "" | make $(make_options) oldconfig
> 
> That will become an infinite loop if "y" is not a valid answer for the newly
> introduced option (e.g. if it needs a number)?
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
> 

Re: [Ksummit-discuss] [PATCH 2/2] kconfig: new command line kernel configuration tool

[Geert Uytterhoeven]

Hi Dan,

On Thu, Jul 6, 2017 at 4:42 PM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> This tool barely works, it's just a rough draft.
>
> Sometimes I want to search for a config so I have to load menuconfig,
> then search for the config entry, then exit.  With this script I
> simply run:
>
>     ./scripts/kconfig/kconfig search COMEDI
>
> Quite often I find myself trying to enable a feature by doing this:
>
>     echo CONFIG_FEATURE=y >> .config
>
> But when I try to boot the new kernel, I find that the feature isn't
> there because the kernel runs `make oldconfig` and I didn't have all
> the depends selected so it silently removed it.  With this feature
> what you can do is:
>
>     ./scripts/kconfig/kconfig set FEATURE=y
>
> It helps you enable the dependencies or it at least prints an error
> if it can't enable the feature.
>
> But this code isn't all implemented.  1) It doesn't calculate the
> dependencies well.  See expr_parse() for more details.  2)  It
> doesn't work well for things like:
>
>         ./scripts/kconfig/kconfig set BT_INTEL=m
>
> because those aren't visible, they can only be using depend
> statements.  Or say you try to set FEATURE=m when something else
> depends on it be set =y then the error message is wrong.  The
> other problem is that I don't know how to print the help text.
> Again, this is just a rough draft.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>

Thanks! With the small fixes below, it worked fine for all cases I tried it
with.

> --- /dev/null
> +++ b/scripts/kconfig/lconf.c
> @@ -0,0 +1,332 @@
> +/*
> + * Copyright (C) 2015 Oracle
> + * Released under the terms of the GNU GPL v2.0.
> + *
> + */
> +#define _GNU_SOURCE

    scripts/kconfig/lconf.c:6:0: warning: "_GNU_SOURCE" redefined
     #define _GNU_SOURCE
     ^
    <command-line>:0:0: note: this is the location of the previous definition

You can do:

    #ifndef _GNU_SOURCE
    #define _GNU_SOURCE
    #endif

like scripts/kconfig/nconf.c does.


> +static int conf_sym(struct symbol *sym)
> +{

> +               if (sym_set_tristate_value(sym, newval)) {
> +                       /* FIXME: if I don't write it doesn't save */
> +                       conf_write(NULL, 1);

    scripts/kconfig/lconf.c: In function ‘conf_sym’:
    scripts/kconfig/lconf.c:159:4: error: too many arguments to
function ‘conf_write’
        conf_write(NULL, 1);
        ^
    In file included from scripts/kconfig/lkc.h:24:0,
                     from scripts/kconfig/lconf.c:10:
    scripts/kconfig/lkc_proto.h:8:5: note: declared here

It seems it never took 2 parameters in upstream?
Dropping the "1" works.


> +static void kconfig_set(void)
> +{

> +       res = conf_write(NULL, 1);

Likewise


For search, it doesn't work with the CONFIG_ prefix:

$ path-to-source-tree/scripts/kconfig/kconfig search CONFIG_IPMMU_VMSA
  GEN     ./Makefile
No matches found.
$ path-to-source-tree/scripts/kconfig/kconfig search IPMMU_VMSA
  GEN     ./Makefile
Symbol: IPMMU_VMSA [=n]
Type  : boolean
Prompt: Renesas VMSA-compatible IPMMU
  Location:
    -> Device Drivers
      -> IOMMU Hardware Support (IOMMU_SUPPORT [=n])
  Defined at drivers/iommu/Kconfig:275
  Depends on: IOMMU_SUPPORT [=n] && (ARM [=y] || IOMMU_DMA [=n]) &&
(ARCH_RENESAS [=y] || COMPILE_TEST [=n])
  Selects: IOMMU_API [=n] && IOMMU_IO_PGTABLE_LPAE [=n] &&
ARM_DMA_USE_IOMMU [=n]


For set, it works with or without the CONFIG_ prefix:

$ path-to-source-tree/scripts/kconfig/kconfig set CONFIG_IPMMU_VMSA=y
  GEN     ./Makefile

IPMMU_VMSA: has missing dependencies
IOMMU_SUPPORT [=n] && (ARM [=y] || IOMMU_DMA [=n]) && (ARCH_RENESAS
[=y] || COMPILE_TEST [=n])

IOMMU_SUPPORT:  IOMMU Hardware Support [N/y] y
y
#
# configuration written to .config
#
HELP.  Lot of unimplemented code.  1
HELP.  Lot of unimplemented code.  1
#
# configuration written to .config
#
set: IPMMU_VMSA=y
$ diff .config{.orig,}
--- .config.orig        2017-07-10 11:34:13.181395059 +0200
+++ .config     2017-07-10 11:34:23.297370970 +0200
@@ -4,6 +4,9 @@
 #
 CONFIG_ARM=y
 CONFIG_ARM_HAS_SG_CHAIN=y
+CONFIG_NEED_SG_DMA_LENGTH=y
+CONFIG_ARM_DMA_USE_IOMMU=y
+CONFIG_ARM_DMA_IOMMU_ALIGNMENT=8
 CONFIG_MIGHT_HAVE_PCI=y
 CONFIG_SYS_SUPPORTS_APM_EMULATION=y
 CONFIG_HAVE_PROC_CPU=y
@@ -3452,6 +3455,7 @@ CONFIG_SYNC_FILE=y
 # CONFIG_SW_SYNC is not set
 # CONFIG_AUXDISPLAY is not set
 # CONFIG_UIO is not set
+# CONFIG_VFIO is not set
 # CONFIG_VIRT_DRIVERS is not set

 #
@@ -3634,7 +3638,19 @@ CONFIG_RENESAS_OSTM=y
 CONFIG_SH_TIMER_TMU=y
 CONFIG_EM_TIMER_STI=y
 # CONFIG_MAILBOX is not set
-# CONFIG_IOMMU_SUPPORT is not set
+CONFIG_IOMMU_API=y
+CONFIG_IOMMU_SUPPORT=y
+
+#
+# Generic IOMMU Pagetable Support
+#
+CONFIG_IOMMU_IO_PGTABLE=y
+CONFIG_IOMMU_IO_PGTABLE_LPAE=y
+# CONFIG_IOMMU_IO_PGTABLE_LPAE_SELFTEST is not set
+# CONFIG_IOMMU_IO_PGTABLE_ARMV7S is not set
+CONFIG_OF_IOMMU=y
+CONFIG_IPMMU_VMSA=y
+# CONFIG_ARM_SMMU is not set

 #
 # Remoteproc drivers

Nice!

BTW, forgetting the =y causes a crash:

$ path-to-source-tree/scripts/kconfig/kconfig set IPMMU_VMSA
  GEN     ./Makefile
path-to-source-tree/scripts/kconfig/Makefile:37: recipe for target
'lconfig' failed
make[4]: *** [lconfig] Segmentation fault
path-to-source-tree/Makefile:548: recipe for target 'lconfig' failed
make[3]: *** [lconfig] Error 2
Makefile:152: recipe for target 'sub-make' failed
make[2]: *** [sub-make] Error 2
Makefile:24: recipe for target '__sub-make' failed
make[1]: *** [__sub-make] Error 2
GNUmakefile:10: recipe for target 'all' failed
make: *** [all] Error 2

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [Ksummit-discuss] [PATCH 2/2] kconfig: new command line kernel configuration tool

[Dan Carpenter]

On Mon, Jul 10, 2017 at 11:44:22AM +0200, Geert Uytterhoeven wrote:
> > --- /dev/null
> > +++ b/scripts/kconfig/lconf.c
> > @@ -0,0 +1,332 @@
> > +/*
> > + * Copyright (C) 2015 Oracle
> > + * Released under the terms of the GNU GPL v2.0.
> > + *
> > + */
> > +#define _GNU_SOURCE
> 
>     scripts/kconfig/lconf.c:6:0: warning: "_GNU_SOURCE" redefined
>      #define _GNU_SOURCE
>      ^
>     <command-line>:0:0: note: this is the location of the previous definition
> 
> You can do:
> 
>     #ifndef _GNU_SOURCE
>     #define _GNU_SOURCE
>     #endif
> 
> like scripts/kconfig/nconf.c does.

Will do.

> 
> 
> > +static int conf_sym(struct symbol *sym)
> > +{
> 
> > +               if (sym_set_tristate_value(sym, newval)) {
> > +                       /* FIXME: if I don't write it doesn't save */
> > +                       conf_write(NULL, 1);
> 
>     scripts/kconfig/lconf.c: In function ‘conf_sym’:
>     scripts/kconfig/lconf.c:159:4: error: too many arguments to
> function ‘conf_write’
>         conf_write(NULL, 1);


I added that in [PATCH 1/2], otherwise there is a lot of unwanted
output.

> Likewise
> 
> 
> For search, it doesn't work with the CONFIG_ prefix:


Will fix.

> 
> Nice!
> 
> BTW, forgetting the =y causes a crash:
> 

Oops.  Sorry.  Will fix.

regards,
dan carpenter

Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Linus Torvalds]

On Thu, Jul 6, 2017 at 7:40 AM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> People have mentioned "make oldconfig" but I've never had a lot of luck
> with that.  It always just prints "* Restart config..." and deletes my
> config.

Really?

For me, "make oldconfig" is pretty much the only thing I ever use
(apart from build testing).

It's very convenient once you have a baseline, and want to just get
the new questions for when the Kconfig files change. It's also how I
notice when somebody adds a new config entry that doesn't default to
'n'.

It's also very convenient when you end up changing your config: just
edit the damn .config file directly, and then re-run "make oldconfig"
just to make sure everything gets updated (and then you'll notice that
you tried to disable some config entry, but it got re-enabled again
because there was something else that depended on it and selected it
;)

So I wonder why it wouldn't work for you.

Now, admittedly, I literally only ever use two source files: the
previous ".config" file, and if that is missing (after a "git clean
-dqfx" or similar), just /etc/kernel-config.

The oldconfig logic has fallbacks to other cases, but they are all useless imho.

Also, I build in the source tree. Maybe you use a separate object tree
and it gets that case wrong.

                   Linus

Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Randy Dunlap]

On 07/06/2017 09:41 AM, Linus Torvalds wrote:
> On Thu, Jul 6, 2017 at 7:40 AM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
>> People have mentioned "make oldconfig" but I've never had a lot of luck
>> with that.  It always just prints "* Restart config..." and deletes my
>> config.
> 
> Really?
> 
> For me, "make oldconfig" is pretty much the only thing I ever use
> (apart from build testing).
> 
> It's very convenient once you have a baseline, and want to just get
> the new questions for when the Kconfig files change. It's also how I
> notice when somebody adds a new config entry that doesn't default to
> 'n'.
> 
> It's also very convenient when you end up changing your config: just
> edit the damn .config file directly, and then re-run "make oldconfig"
> just to make sure everything gets updated (and then you'll notice that
> you tried to disable some config entry, but it got re-enabled again
> because there was something else that depended on it and selected it
> ;)
> 
> So I wonder why it wouldn't work for you.
> 
> Now, admittedly, I literally only ever use two source files: the
> previous ".config" file, and if that is missing (after a "git clean
> -dqfx" or similar), just /etc/kernel-config.
> 
> The oldconfig logic has fallbacks to other cases, but they are all useless imho.
> 
> Also, I build in the source tree. Maybe you use a separate object tree
> and it gets that case wrong.

Nah, I use O=objdir all the time and oldconfig works for me.

-- 
~Randy

Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Dan Carpenter]

On Thu, Jul 06, 2017 at 09:41:36AM -0700, Linus Torvalds wrote:
> On Thu, Jul 6, 2017 at 7:40 AM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> > People have mentioned "make oldconfig" but I've never had a lot of luck
> > with that.  It always just prints "* Restart config..." and deletes my
> > config.
> 
> Really?
> 

Argh.  You're right.  I'm an idiot.  It's actually working fine, but it
asked so many questions I thought it was broken.

regards,
dan carpenter

Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Luck, Tony]

> Argh.  You're right.  I'm an idiot.  It's actually working fine, but it
> asked so many questions I thought it was broken.

I run:

$ yes "" | make oldconfig

to just pick the default answer for all the questions.  It works
almost all of the time.  Only recent break was when using
a RHEL config as the start point some change in the MPT2SAS
and MPT3SAS bits left me with a kernel with no driver to get to
my root file system.

-Tony

Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Alexandre Belloni]

On 10/07/2017 at 17:15:33 +0000, Luck, Tony wrote:
> > Argh.  You're right.  I'm an idiot.  It's actually working fine, but it
> > asked so many questions I thought it was broken.
> 
> I run:
> 
> $ yes "" | make oldconfig
> 

I know the yes trick works for kernels older than 3.7 but maybe people
should start using make olddefconfig ;)


-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Linus Torvalds]

On Mon, Jul 10, 2017 at 10:33 AM, Alexandre Belloni
<alexandre.belloni@free-electrons.com> wrote:
>
> I know the yes trick works for kernels older than 3.7 but maybe people
> should start using make olddefconfig ;)

Honestly, I wish more people just ran "oldconfig" and then started
complaining about people adding insane Kconfig options.

I seem to be the only one ever pushing back against some of the people
out there that add Kconfig options that really make zero sense (or
that add the oddest drivers or features with a crazy "default this
thing to on").

                       Linus

Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Randy Dunlap]

On 07/10/2017 11:28 AM, Linus Torvalds wrote:
> On Mon, Jul 10, 2017 at 10:33 AM, Alexandre Belloni
> <alexandre.belloni@free-electrons.com> wrote:
>>
>> I know the yes trick works for kernels older than 3.7 but maybe people
>> should start using make olddefconfig ;)
> 
> Honestly, I wish more people just ran "oldconfig" and then started
> complaining about people adding insane Kconfig options.
> 
> I seem to be the only one ever pushing back against some of the people
> out there that add Kconfig options that really make zero sense (or
> that add the oddest drivers or features with a crazy "default this
> thing to on").

I could -- and I have a few times. But usually it needs a $maintainer
to make others listen.  I'm just a lurker.


-- 
~Randy

Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Valentin Rothberg]

On Jul 10 '17 11:28, Linus Torvalds wrote:
> On Mon, Jul 10, 2017 at 10:33 AM, Alexandre Belloni
> <alexandre.belloni@free-electrons.com> wrote:
> >
> > I know the yes trick works for kernels older than 3.7 but maybe people
> > should start using make olddefconfig ;)
> 
> Honestly, I wish more people just ran "oldconfig" and then started
> complaining about people adding insane Kconfig options.

If you want, we could add a "--diff-options" to checkkconfigsymbols.py.
It runs reasonably fast and would also report options outside the
current architecture.

Kind regards,
 Valentin

Re: [Ksummit-discuss] [TECH TOPIC] is Kconfig a bit hard sometimes?

[Laurent Pinchart]

On Thursday 06 Jul 2017 17:40:29 Dan Carpenter wrote:
> People have mentioned "make oldconfig" but I've never had a lot of luck
> with that.  It always just prints "* Restart config..." and deletes my
> config.

I like oldconfig as it makes it easy to find about new options when upgrading 
the kernel. However, there's one thing that bothers me. When jumping by more 
than one kernel version, the number of options can be quite high, in which 
case I sometimes make mistakes answering questions. I'd love it if Kconfig 
allowed me to go back and correct mistakes, instead of having to note the 
option down and modify it manually afterwards.

> Also I hate menus.  It's such a pain if you want to enable a feature and
> you have to do a dungeon crawl through our menu system to try find it.
> 
> I wrote a script a couple years ago to create kernel configs.  I do a
> make defconfig, then I take a distro config and I do:
> 
>     for i in $(grep =m old_config) ; do
> 	./scripts/kconfig/kconfig set $i
>     done
> 
> This prints a lot of errors and the code is only half implemented but
> it's honestly the easiest way for me to get a bootable kernel these
> days.  If someone wanted to the could add a "./scripts/kconfig/kconfig
> file <name>" command that would read a line at a time and call
> `./scripts/kconfig/kconfig set $line` over and over.

-- 
Regards,

Laurent Pinchart