Re: [PATCH] x86: defconfig: Enable CONFIG_FHANDLE

From: Richard Weinberger
Date: Wed Nov 26 2014 - 03:13:28 EST


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)
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 thought we were getting rid of the defconfig files entirely one of
> these days, didn't some arches already do this?

Please don't.

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