linux-kernel - Re: [PATCH] x86: defconfig: Enable CONFIG

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 26 Nov 2014 10:30:56 +0100
From:	Paul Bolle <pebolle@...cali.nl>
To:	Richard Weinberger <richard@....at>
Cc:	Greg KH <gregkh@...uxfoundation.org>, x86@...nel.org,
	tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
	rafael.j.wysocki@...el.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86: defconfig: Enable CONFIG_FHANDLE

On Wed, 2014-11-26 at 09:13 +0100, Richard Weinberger wrote:
> Am 26.11.2014 um 01:55 schrieb Greg KH:
> > On Wed, Nov 26, 2014 at 01:11:01AM +0100, Richard Weinberger wrote:
> >> Am 26.11.2014 um 00:51 schrieb Greg KH:
> >>> On Wed, Nov 26, 2014 at 12:36:52AM +0100, Richard Weinberger wrote:
> >>>> systemd has a hard dependency on CONFIG_FHANDLE.
> >>>
> >>> It's been this way for a very long time, why is this suddenly an issue?
> >>
> >> Because nobody cared to create patch and just called systemd names? ;-)
> > 
> > systemd documents what is needed in order for it to boot properly quite
> > well, I don't see why this needs to be here.
> 
> Because not every kernel developer knows the contents of the damn systemd readme file.
> Face it, systemd is common userspace and if a defconfig is unable to boot common userspace
> we have a problem.
> 
> Yesterday I was hunting down a regression in libvirt on the shiny new openSUSE 13.2,
> I had to build an older kernel.
> So I did a defconfig because I know that config has all drivers for my KVM setup.
> (No, I my laptop don't has to power to build the bloated .config from suse)

Isn't that considered best practice? Ie, you use a .config provided by
the distribution that you run - of which you know that it will boot your
(hardware/software) setup - as a base to build new kernels. That's what
I do, while my most powerful machine tends to be a laptop bought after
its production already stopped (ie, in clearance sales).

> But systemd went nuts (in terms of doing completely crap things beside of not spawning
> a getty).
> After one hour of painful systemd debugging I found out that I was missing
> CONFIG_FHANDLE.
> 
> I really don't understand why you are so opposed to that change.
> Let's make thing easier for us.
> 
> >>> Do these files even make any sense anymore?  Who uses them?  The distros
> >>> sure do not...
> >>
> >> Maybe I'm oldschool but I expect a defconfig kernel to be able to boot a
> >> recent distro.
> > 
> > You are :)
> > How does the defconfig know your hardware in order to be able to find
> > the root disk properly?  Video device?  USB keyboard?  and so on...

I think I never tried booting a kernel built with a defconfig file. But
are the (hardware/software) setups used by people that build their own
kernel so diverse that it will make a defconfig that covers (a
substantial portion of) that group grow too big? Ie, we end up with
something that looks a lot like what distributions use?

> > I thought we were getting rid of the defconfig files entirely one of
> > these days, didn't some arches already do this?

Looking at
    git ls-files "*defconfig*" | sed -e "s/arch\///; s/\/.*//" | sort -u

it seems all arches have at least one defconfig file. I do think,
however, that arch/arm dropped a substantial number of defconfig files a
few years back.

Anyhow, why should we get rid of the defconfig files entirely? Because
they aren't really useful, since they won't help in building a kernel
that actually boots the targeted systems? Or is it because of the churn
involved in keeping them up to date? (Last time I checked most of them
had accumulated quite a bit of outdated stuff. But the kconfig tools
don't mind, they just skip what isn't used in the Kconfig files
anymore.)

If it's churn, perhaps the defconfig files could be moved into a
separate repository. In that repository they should be regenerated for
every release (and every -rc). That ought to be possible automagically.
The only actual fixes would then be for the problems people notice when
using those defconfig files. I'm not sure how to detect for that
repository which defconfig files can be dropped entirely - because their
targets are not supported anymore. That seems to happen often enough
with obscure, outdated, etc. ARM boards, things like that.

> Please don't.

Paul Bolle

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