linux-kernel - Re: [PATCH v2 3/3] drivers: cleanup Kconfig stuff

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 19 Oct 2010 17:13:07 -0700
From:	Kevin Hilman <khilman@...prootsystems.com>
To:	Tony Lindgren <tony@...mide.com>
Cc:	Felipe Contreras <felipe.contreras@...il.com>,
	Felipe Balbi <me@...ipebalbi.com>, balbi@...com,
	linux-usb@...r.kernel.org, linux-omap <linux-omap@...r.kernel.org>,
	linux-main <linux-kernel@...r.kernel.org>,
	Greg KH <greg@...ah.com>
Subject: Re: [PATCH v2 3/3] drivers: cleanup Kconfig stuff

Tony Lindgren <tony@...mide.com> writes:

> * Felipe Contreras <felipe.contreras@...il.com> [101019 13:43]:
>> On Tue, Oct 19, 2010 at 6:05 PM, Felipe Balbi <me@...ipebalbi.com> wrote:
>> > On Tue, 19 Oct 2010 17:32:07 +0300, Felipe Contreras
>> > <felipe.contreras@...il.com> wrote:
>> >> There are two parts, one part is to fix the Kconfigs, and another was
>> >> to come up with a way to replace the horrible defconfigs. Part two is
>> >> mostly fixed thanks to 'make savedefconfig', since the defconfigs are
>> >> not so horrible any more, but part one is a continued effort.
>> >>
>> >> For part two Linus had the idea to use Kconfigs instead of defconfigs,
>> >> but they would mostly look very similar to the current ones generated
>> >> by 'make savedefconfig'.
>> >>
>> >> I don't know what makes you think Linus didn't want part one to be
>> >> done. He wanted the Kconfig.rx51 to be human readable, and you are
>> >> proposing that TWL4030_USB should be manually added there... I don't
>> >> think TWL4030_USB says anything to human beings.
>> >
>> > I don't read anywhere Linus saying we should clutter drivers/*/Kconfig
>> > with defaults. I think you're inverting things, it's much better
>> > to select TWL4030_USB when you enable MACH_OMAP_RX51 then default y
>> > if MACH_OMAP_RX51.
>> 
>> So say, if you have 100 board defconfigs with OMAP3 chips and TWL4030,
>> each and every one of them should select both USB_MUSB_HDRC and
>> TWL4030_USB?
>> 
>> And you are saying if somebody is doing 'make menuconfig', that person
>> should somehow know that _obviously_ he needs TWL4030_USB in order to
>> use USB_MUSB_HDRC, or USB_G_NOKIA?
>
> Hey we're already dealing with stuff like this :)
>
> See ARCH_OMAP2PLUS_TYPICAL in arch/arm/mach-omap2/Kconfig:
>
> config ARCH_OMAP2PLUS_TYPICAL
>         bool "Typical OMAP configuration"
>         default y
>         select AEABI
>         select REGULATOR
>         select PM
>         select PM_RUNTIME
>         select VFP
>         select NEON if ARCH_OMAP3 || ARCH_OMAP4
>         select SERIAL_OMAP
>         select SERIAL_OMAP_CONSOLE
>         select I2C
>         select I2C_OMAP
>         select MFD
>         select MENELAUS if ARCH_OMAP2
>         select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4
>         select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4
>         help
>           Compile a kernel suitable for booting most boards
>
> This actually produces a booting omap2+ kernel with no .config
> at all. I've tested it with:
>
> $ echo CONFIG_ARCH_OMAP=y > .config
> $ yes "" | ARCH=arm make oldconfig
>
> So if you have something that's needed on almost every omap,
> you can select it there.

One thing I don't like about this is that there is currently no way to
'select' as a module.

In order to get to a minimal kernel, in theory, we don't need regulator,
i2c, MFD, or twl4030* built in.  They should all be built as modules.
Yes, there are some assumptions made today that some of these things are
built in, and then are used from init code, but that is broken.

If someone is looking for a good omap-kernel-janitors project, I would
suggest getting to a *really* minimal OMAP2+ kernel with everything
possible built as modules to be a very good project.

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