Re: Kernel configurations for Fedora -- a proposal

[Laura Abbott]

On 12/06/2016 04:44 AM, Thorsten Leemhuis wrote:
> Lo! On 21.11.2016 19:46, Laura Abbott wrote:
>>
>> As a follow up to the previous discussion about kernel configuration
>> in Fedora 
>> (https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/thread/DBOBI6F3SLEAW2O5RLGZOOXQ5VKEWQIW/)
>> I have a prototype of what a method of keeping each configuration
>> file in a separate file would look like. This method takes care of
>> several of my gripes of the current version (and found a few errors
>> in the existing config files). The biggest question I have is if
>> this will scale for how frequently Fedora adjusts configuration
>> options. Some of that could possibly be solved with more scripting
>> improvements.
>>
>> The repo is at https://pagure.io/fedora-kernel-labbott/branch/split_configs
> 
> I took a brief look. Overall I thought "if it makes maintaining the
> configs easier, go ahead, I don't care much". There are just a few
> things I noticed while looking at it:
> 
> * nitpicking: I found the filenames "generate_(all|debug)_configs.sh"
> misleading, because those scripts do not generate a config, as they
> afaics just put a pre-generated config in place so they are going to be
> used.
> 
> * I really like that this finally gets rids of the noise in the config
> file diffs that the frequent enabling/disabling using "make
> (debug|release)" creates currently.
> 
> * Just thinking aloud: I wonder if the pre-generated *debug.configs are
> a good idea. Wouldn't it be more obvious what is happening if we'd ship
> one base config (e.g. where debugging is turned off) and then have
> something in the spec file itself that builds slightly modified version
> depending on what is needed in the current build? Having a mechanism
> like this might be handy for other situations as well. For example we
> could have something in the spec file that automatically disables
> "CONFIG_ARM64_VA_BITS_48" and "CONFIG_ARM64_VA_BITS" when building for
> "$fedora_release <= F25"; this way we'd make sure things like that do
> not accidental make it into older releases during a rebase.

I'm not sure how that would be more obvious. Generating the configs
makes it easier to check each file to see what's present vs not
being able to see what's enabled until it is built. I'm wary
to put anything more in the .spec file than we have to since the
file is complicated enough as is. Having the spec file enforce config
policy would be a step in the wrong direction.

Thanks,
Laura

> 
> HTH, CU, knurd
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
> 
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Kernel configurations for Fedora -- a proposal

[Thorsten Leemhuis]

Lo! On 21.11.2016 19:46, Laura Abbott wrote:
>
> As a follow up to the previous discussion about kernel configuration
> in Fedora 
> (https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/thread/DBOBI6F3SLEAW2O5RLGZOOXQ5VKEWQIW/)
> I have a prototype of what a method of keeping each configuration
> file in a separate file would look like. This method takes care of
> several of my gripes of the current version (and found a few errors
> in the existing config files). The biggest question I have is if
> this will scale for how frequently Fedora adjusts configuration
> options. Some of that could possibly be solved with more scripting
> improvements.
> 
> The repo is at https://pagure.io/fedora-kernel-labbott/branch/split_configs

I took a brief look. Overall I thought "if it makes maintaining the
configs easier, go ahead, I don't care much". There are just a few
things I noticed while looking at it:

* nitpicking: I found the filenames "generate_(all|debug)_configs.sh"
misleading, because those scripts do not generate a config, as they
afaics just put a pre-generated config in place so they are going to be
used.

* I really like that this finally gets rids of the noise in the config
file diffs that the frequent enabling/disabling using "make
(debug|release)" creates currently.

* Just thinking aloud: I wonder if the pre-generated *debug.configs are
a good idea. Wouldn't it be more obvious what is happening if we'd ship
one base config (e.g. where debugging is turned off) and then have
something in the spec file itself that builds slightly modified version
depending on what is needed in the current build? Having a mechanism
like this might be handy for other situations as well. For example we
could have something in the spec file that automatically disables
"CONFIG_ARM64_VA_BITS_48" and "CONFIG_ARM64_VA_BITS" when building for
"$fedora_release <= F25"; this way we'd make sure things like that do
not accidental make it into older releases during a rebase.

HTH, CU, knurd
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Kernel configurations for Fedora -- a proposal

[Laura Abbott]

On 11/30/2016 05:54 PM, Peter Robinson wrote:
> On Wed, Nov 30, 2016 at 4:51 PM, Laura Abbott  wrote:
>> On 11/21/2016 10:46 AM, Laura Abbott wrote:
>>> Hi,
>>>
>>> As a follow up to the previous discussion about kernel configuration
>>> in Fedora 
>>> (https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/thread/DBOBI6F3SLEAW2O5RLGZOOXQ5VKEWQIW/)
>>> I have a prototype of what a method of keeping each configuration
>>> file in a separate file would look like. This method takes care of
>>> several of my gripes of the current version (and found a few errors
>>> in the existing config files). The biggest question I have is if
>>> this will scale for how frequently Fedora adjusts configuration
>>> options. Some of that could possibly be solved with more scripting
>>> improvements.
>>>
>>> The repo is at https://pagure.io/fedora-kernel-labbott/branch/split_configs
>>>
>>> Thanks,
>>> Laura
>>>
>>
>> A reminder of this for those who may have missed it. I'm going to take
>> silence as no objection or opinion.
> 
> My silence is neither but rather "not had time to read the thread and
> digest it yet". Is the proposed change in a git repoo somewhere I
> could checkout to see?
> 
> P
> 

The repo is at https://pagure.io/fedora-kernel-labbott/branch/split_configs
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Kernel configurations for Fedora -- a proposal

[Peter Robinson]

On Wed, Nov 30, 2016 at 4:51 PM, Laura Abbott  wrote:
> On 11/21/2016 10:46 AM, Laura Abbott wrote:
>> Hi,
>>
>> As a follow up to the previous discussion about kernel configuration
>> in Fedora 
>> (https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/thread/DBOBI6F3SLEAW2O5RLGZOOXQ5VKEWQIW/)
>> I have a prototype of what a method of keeping each configuration
>> file in a separate file would look like. This method takes care of
>> several of my gripes of the current version (and found a few errors
>> in the existing config files). The biggest question I have is if
>> this will scale for how frequently Fedora adjusts configuration
>> options. Some of that could possibly be solved with more scripting
>> improvements.
>>
>> The repo is at https://pagure.io/fedora-kernel-labbott/branch/split_configs
>>
>> Thanks,
>> Laura
>>
>
> A reminder of this for those who may have missed it. I'm going to take
> silence as no objection or opinion.

My silence is neither but rather "not had time to read the thread and
digest it yet". Is the proposed change in a git repoo somewhere I
could checkout to see?

P
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Kernel configurations for Fedora -- a proposal

[Jarod Wilson]

On 2016-11-30 11:59 AM, Dan Horák wrote:

On Wed, 30 Nov 2016 08:51:29 -0800
Laura Abbott  wrote:


On 11/21/2016 10:46 AM, Laura Abbott wrote:

Hi,

As a follow up to the previous discussion about kernel configuration
in Fedora
(https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/thread/DBOBI6F3SLEAW2O5RLGZOOXQ5VKEWQIW/
) I have a prototype of what a method of keeping each configuration
file in a separate file would look like. This method takes care of
several of my gripes of the current version (and found a few errors
in the existing config files). The biggest question I have is if
this will scale for how frequently Fedora adjusts configuration
options. Some of that could possibly be solved with more scripting
improvements.

The repo is at
https://pagure.io/fedora-kernel-labbott/branch/split_configs

Thanks,
Laura



A reminder of this for those who may have missed it. I'm going to take
silence as no objection or opinion.


With my s390x hat on, my wish for kernel config is to have a way to
inherit the generic Fedora config, but still be able to build for
example only white-listed network drivers. Right now globally enabled
"PCI" enables also all drivers for all PCI-based devices (network,
storage, ...), but the s390x hardware has an internal whitelist of PCI
ids, so doesn't make sense to them all except the white-listed ones
(seen eg. in mainline default config). Is it feasible with the new
scheme?


Yes, absolutely, but it's also doable with the current scheme, as Laura 
was suggesting.


--
Jarod Wilson
ja...@redhat.com
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Kernel configurations for Fedora -- a proposal

[Laura Abbott]

On 11/30/2016 08:59 AM, Dan Horák wrote:
> On Wed, 30 Nov 2016 08:51:29 -0800
> Laura Abbott  wrote:
> 
>> On 11/21/2016 10:46 AM, Laura Abbott wrote:
>>> Hi,
>>>
>>> As a follow up to the previous discussion about kernel configuration
>>> in Fedora
>>> (https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/thread/DBOBI6F3SLEAW2O5RLGZOOXQ5VKEWQIW/
>>> ) I have a prototype of what a method of keeping each configuration
>>> file in a separate file would look like. This method takes care of
>>> several of my gripes of the current version (and found a few errors
>>> in the existing config files). The biggest question I have is if
>>> this will scale for how frequently Fedora adjusts configuration
>>> options. Some of that could possibly be solved with more scripting
>>> improvements.
>>>
>>> The repo is at
>>> https://pagure.io/fedora-kernel-labbott/branch/split_configs
>>>
>>> Thanks,
>>> Laura
>>>
>>
>> A reminder of this for those who may have missed it. I'm going to take
>> silence as no objection or opinion.
> 
> With my s390x hat on, my wish for kernel config is to have a way to
> inherit the generic Fedora config, but still be able to build for
> example only white-listed network drivers. Right now globally enabled
> "PCI" enables also all drivers for all PCI-based devices (network,
> storage, ...), but the s390x hardware has an internal whitelist of PCI
> ids, so doesn't make sense to them all except the white-listed ones
> (seen eg. in mainline default config). Is it feasible with the new
> scheme?

I don't think I completely understand your question. This should be
possible with the existing setup where config-s390x can set CONFIG_FOO=n
to turn off any drivers it doesn't want enabled. Is there something
more than that you want to happen?

Thanks,
Laura

> 
> 
>   Dan
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Kernel configurations for Fedora -- a proposal

[Dan Horák]

On Wed, 30 Nov 2016 08:51:29 -0800
Laura Abbott  wrote:

> On 11/21/2016 10:46 AM, Laura Abbott wrote:
> > Hi,
> > 
> > As a follow up to the previous discussion about kernel configuration
> > in Fedora
> > (https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/thread/DBOBI6F3SLEAW2O5RLGZOOXQ5VKEWQIW/
> > ) I have a prototype of what a method of keeping each configuration
> > file in a separate file would look like. This method takes care of
> > several of my gripes of the current version (and found a few errors
> > in the existing config files). The biggest question I have is if
> > this will scale for how frequently Fedora adjusts configuration
> > options. Some of that could possibly be solved with more scripting
> > improvements.
> > 
> > The repo is at
> > https://pagure.io/fedora-kernel-labbott/branch/split_configs
> > 
> > Thanks,
> > Laura
> > 
> 
> A reminder of this for those who may have missed it. I'm going to take
> silence as no objection or opinion.

With my s390x hat on, my wish for kernel config is to have a way to
inherit the generic Fedora config, but still be able to build for
example only white-listed network drivers. Right now globally enabled
"PCI" enables also all drivers for all PCI-based devices (network,
storage, ...), but the s390x hardware has an internal whitelist of PCI
ids, so doesn't make sense to them all except the white-listed ones
(seen eg. in mainline default config). Is it feasible with the new
scheme?


Dan
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Kernel configurations for Fedora -- a proposal

[Laura Abbott]

On 11/21/2016 10:46 AM, Laura Abbott wrote:
> Hi,
> 
> As a follow up to the previous discussion about kernel configuration
> in Fedora 
> (https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/thread/DBOBI6F3SLEAW2O5RLGZOOXQ5VKEWQIW/)
> I have a prototype of what a method of keeping each configuration
> file in a separate file would look like. This method takes care of
> several of my gripes of the current version (and found a few errors
> in the existing config files). The biggest question I have is if
> this will scale for how frequently Fedora adjusts configuration
> options. Some of that could possibly be solved with more scripting
> improvements.
> 
> The repo is at https://pagure.io/fedora-kernel-labbott/branch/split_configs
> 
> Thanks,
> Laura
> 

A reminder of this for those who may have missed it. I'm going to take
silence as no objection or opinion.

Thanks,
Laura
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Kernel configurations for Fedora -- a proposal

[Laura Abbott]

Hi,

As a follow up to the previous discussion about kernel configuration
in Fedora 
(https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/thread/DBOBI6F3SLEAW2O5RLGZOOXQ5VKEWQIW/)
I have a prototype of what a method of keeping each configuration
file in a separate file would look like. This method takes care of
several of my gripes of the current version (and found a few errors
in the existing config files). The biggest question I have is if
this will scale for how frequently Fedora adjusts configuration
options. Some of that could possibly be solved with more scripting
improvements.

The repo is at https://pagure.io/fedora-kernel-labbott/branch/split_configs

Thanks,
Laura
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Kernel configurations for Fedora

[Laura Abbott]

On 10/25/2016 10:53 AM, Paul Bolle wrote:

On Tue, 2016-10-25 at 10:46 -0700, Laura Abbott wrote:

Anyone have experiences with or opinions about the kernel
configuration generation? The goal is to only change the way
the configurations are generated and not the options that are
enabled.


Naive question: why can't we use one .config per target?


Paul Bolle



This is one of the options being considered. The feedback I got
was that it might end up being more work to maintain because there
would many large files which all need to be modified. New options
would need to be added all of them.

Thanks,
Laura
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Kernel configurations for Fedora

[Paul Bolle]

On Tue, 2016-10-25 at 16:26 -0400, Jarod Wilson wrote:
> Should be a simple enough thing to script even,
> to get a "stale config options" report, the output of which could be fed
> to a find command that removes them from the configs/ tree...

Something like scripts/check-configs.pl?


Paul Bolle
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Kernel configurations for Fedora

[Jarod Wilson]

On Tue, Oct 25, 2016 at 04:17:25PM -0400, John W. Linville wrote:
> On Tue, 2016-10-25 at 15:59 -0400, Jarod Wilson wrote:
> > On Tue, Oct 25, 2016 at 02:14:08PM -0400, Don Zickus wrote:
> > > 
> > > On Tue, Oct 25, 2016 at 10:46:00AM -0700, Laura Abbott wrote:
> > > > 
> > > > The Fedora kernel has had roughly the same system for generating
> > > > the kernel configuration for a very long time. There are a series
> > > > of files listing configuration choices (CONFIG_FOO=y, CONFIG_FOO
> > > > is not set etc.) that get combined to generate the final config
> > > > files. This has gotten unsustainable for several reasons:
> > > > 
> > > > - When the system was first introduced, the only supported
> > > > arches were x86_32 and x86_64. Fedora now supports enough
> > > > other arches that we have a config-$arch-generic in addition to
> > > > config-generic
> > > > - It's difficult to tell what is actually enabled since
> > > > there are several layers of configuration combining (I have to
> > > > look at config-generic, then config-$arch-generic, then
> > > > the final config-$specific file to see what the option actually
> > > > is)
> > > > - Keeping the files organized requires manual work and pruning
> > > > 
> > > > I've been thinking about alternatives to the existing config
> > > > generation. One proposal was to take advantage of the upstream
> > > > kernel now supporting config fragments and keep some part of
> > > > the fedora configuration upstream. This would have the
> > > > disadvantage
> > > > of requiring the configuration to be kept in sync with upstream.
> > > > 
> > > > Another option is to switch to a system of generation where
> > > > each configuration option is kept in a separate file. There
> > > > is no sorting or organization necessary. This would result
> > > > in a lot of small files for all the arches Fedora supports
> > > > though.
> > > 
> > > Hi Laura,
> > > 
> > > Just to throw it out there,  RHEL has been using the one option per
> > > file
> > > mechanism for years now with success.  Minimizes the maintenance
> > > and
> > > conflicts.  ( I know you already know that, just wanted to publicly
> > > state
> > > that).
> > > 
> > > The volume of files is large, but it is hidden away and you only
> > > package the
> > > resulting kernel.config files into the src.rpm.
> > 
> > I'm quite fond of the was things were done in el7 too, but I'm
> > biased,
> > since I'm the one that implemented it. ;)
> > 
> > Honestly though, part of the reason for doing it was because those
> > various
> > stacked config hunks were *terrible* to deal with in el6, and people
> > constantly touched the wrong one, had no idea how the end configs
> > were
> > actually compiled, etc., and I don't think anyone has ever gotten it
> > wrong
> > with the approach used now in el7. In the end, the srpm uses a merged
> > config for each kernel build/arch, so it's simple for people doing
> > their
> > own custom builds to modify the right config, and the git tree
> > heirarchy
> > still makes it pretty obvious what's enabled where -- the path from
> > single
> > files to kernel-foo.config is pretty straight-forward and obvious. I
> > don't
> > think I have anything bad to say about this approach, other than
> > "there
> > are a lot of files", and the most difficult part was the initial
> > conversion, making sure no end result config values differred from
> > the
> > prior method.
> 
> What happens in RHEL7 if a kernel config option disappears (i.e. is
> eliminated from all Kconfig files)? I don't think I've ever hit that
> situation, so I honestly don't know.
> 
> The reason I ask, of course, is that such a situation seems much more
> likely with Fedora kernels than with RHEL kernels, since the latter are
> ostensibly less tumultuous with features and options coming and going.
> The answer may be to simply sweep the config to eliminate unused
> options periodically, but it is worth stating that if so.

Ah, yeah, we rarely have a config disappear in el7, and typically, it's
from a rename or some other patch that obsoletes it, so we do have to
delete the matching file too. That's a bit problematic with a rebasing
kernel, but I can see a relatively easy way to sweep for options that have
gone by the wayside: just ls the configs/ sub-dir(s) and git grep for them
in the kernel source... Means having to have a separate Linus kernel git
tree around too, but meh. Should be a simple enough thing to script even,
to get a "stale config options" report, the output of which could be fed
to a find command that removes them from the configs/ tree...

-- 
Jarod Wilson
ja...@redhat.com
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Kernel configurations for Fedora

[John W. Linville]

On Tue, 2016-10-25 at 15:59 -0400, Jarod Wilson wrote:
> On Tue, Oct 25, 2016 at 02:14:08PM -0400, Don Zickus wrote:
> > 
> > On Tue, Oct 25, 2016 at 10:46:00AM -0700, Laura Abbott wrote:
> > > 
> > > The Fedora kernel has had roughly the same system for generating
> > > the kernel configuration for a very long time. There are a series
> > > of files listing configuration choices (CONFIG_FOO=y, CONFIG_FOO
> > > is not set etc.) that get combined to generate the final config
> > > files. This has gotten unsustainable for several reasons:
> > > 
> > > - When the system was first introduced, the only supported
> > > arches were x86_32 and x86_64. Fedora now supports enough
> > > other arches that we have a config-$arch-generic in addition to
> > > config-generic
> > > - It's difficult to tell what is actually enabled since
> > > there are several layers of configuration combining (I have to
> > > look at config-generic, then config-$arch-generic, then
> > > the final config-$specific file to see what the option actually
> > > is)
> > > - Keeping the files organized requires manual work and pruning
> > > 
> > > I've been thinking about alternatives to the existing config
> > > generation. One proposal was to take advantage of the upstream
> > > kernel now supporting config fragments and keep some part of
> > > the fedora configuration upstream. This would have the
> > > disadvantage
> > > of requiring the configuration to be kept in sync with upstream.
> > > 
> > > Another option is to switch to a system of generation where
> > > each configuration option is kept in a separate file. There
> > > is no sorting or organization necessary. This would result
> > > in a lot of small files for all the arches Fedora supports
> > > though.
> > 
> > Hi Laura,
> > 
> > Just to throw it out there,  RHEL has been using the one option per
> > file
> > mechanism for years now with success.  Minimizes the maintenance
> > and
> > conflicts.  ( I know you already know that, just wanted to publicly
> > state
> > that).
> > 
> > The volume of files is large, but it is hidden away and you only
> > package the
> > resulting kernel.config files into the src.rpm.
> 
> I'm quite fond of the was things were done in el7 too, but I'm
> biased,
> since I'm the one that implemented it. ;)
> 
> Honestly though, part of the reason for doing it was because those
> various
> stacked config hunks were *terrible* to deal with in el6, and people
> constantly touched the wrong one, had no idea how the end configs
> were
> actually compiled, etc., and I don't think anyone has ever gotten it
> wrong
> with the approach used now in el7. In the end, the srpm uses a merged
> config for each kernel build/arch, so it's simple for people doing
> their
> own custom builds to modify the right config, and the git tree
> heirarchy
> still makes it pretty obvious what's enabled where -- the path from
> single
> files to kernel-foo.config is pretty straight-forward and obvious. I
> don't
> think I have anything bad to say about this approach, other than
> "there
> are a lot of files", and the most difficult part was the initial
> conversion, making sure no end result config values differred from
> the
> prior method.

What happens in RHEL7 if a kernel config option disappears (i.e. is
eliminated from all Kconfig files)? I don't think I've ever hit that
situation, so I honestly don't know.

The reason I ask, of course, is that such a situation seems much more
likely with Fedora kernels than with RHEL kernels, since the latter are
ostensibly less tumultuous with features and options coming and going.
The answer may be to simply sweep the config to eliminate unused
options periodically, but it is worth stating that if so.

John
-- 
John W. LinvilleHope is a good breakfast, but it is a
linvi...@redhat.com bad supper. -- Sir Francis Bacon
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Kernel configurations for Fedora

[Jarod Wilson]

On Tue, Oct 25, 2016 at 02:14:08PM -0400, Don Zickus wrote:
> On Tue, Oct 25, 2016 at 10:46:00AM -0700, Laura Abbott wrote:
> > The Fedora kernel has had roughly the same system for generating
> > the kernel configuration for a very long time. There are a series
> > of files listing configuration choices (CONFIG_FOO=y, CONFIG_FOO
> > is not set etc.) that get combined to generate the final config
> > files. This has gotten unsustainable for several reasons:
> > 
> > - When the system was first introduced, the only supported
> > arches were x86_32 and x86_64. Fedora now supports enough
> > other arches that we have a config-$arch-generic in addition to
> > config-generic
> > - It's difficult to tell what is actually enabled since
> > there are several layers of configuration combining (I have to
> > look at config-generic, then config-$arch-generic, then
> > the final config-$specific file to see what the option actually
> > is)
> > - Keeping the files organized requires manual work and pruning
> > 
> > I've been thinking about alternatives to the existing config
> > generation. One proposal was to take advantage of the upstream
> > kernel now supporting config fragments and keep some part of
> > the fedora configuration upstream. This would have the disadvantage
> > of requiring the configuration to be kept in sync with upstream.
> > 
> > Another option is to switch to a system of generation where
> > each configuration option is kept in a separate file. There
> > is no sorting or organization necessary. This would result
> > in a lot of small files for all the arches Fedora supports though.
> 
> Hi Laura,
> 
> Just to throw it out there,  RHEL has been using the one option per file
> mechanism for years now with success.  Minimizes the maintenance and
> conflicts.  ( I know you already know that, just wanted to publicly state
> that).
> 
> The volume of files is large, but it is hidden away and you only package the
> resulting kernel.config files into the src.rpm.

I'm quite fond of the was things were done in el7 too, but I'm biased,
since I'm the one that implemented it. ;)

Honestly though, part of the reason for doing it was because those various
stacked config hunks were *terrible* to deal with in el6, and people
constantly touched the wrong one, had no idea how the end configs were
actually compiled, etc., and I don't think anyone has ever gotten it wrong
with the approach used now in el7. In the end, the srpm uses a merged
config for each kernel build/arch, so it's simple for people doing their
own custom builds to modify the right config, and the git tree heirarchy
still makes it pretty obvious what's enabled where -- the path from single
files to kernel-foo.config is pretty straight-forward and obvious. I don't
think I have anything bad to say about this approach, other than "there
are a lot of files", and the most difficult part was the initial
conversion, making sure no end result config values differred from the
prior method.

-- 
Jarod Wilson
ja...@redhat.com
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Kernel configurations for Fedora

[Don Zickus]

On Tue, Oct 25, 2016 at 10:46:00AM -0700, Laura Abbott wrote:
> The Fedora kernel has had roughly the same system for generating
> the kernel configuration for a very long time. There are a series
> of files listing configuration choices (CONFIG_FOO=y, CONFIG_FOO
> is not set etc.) that get combined to generate the final config
> files. This has gotten unsustainable for several reasons:
> 
> - When the system was first introduced, the only supported
> arches were x86_32 and x86_64. Fedora now supports enough
> other arches that we have a config-$arch-generic in addition to
> config-generic
> - It's difficult to tell what is actually enabled since
> there are several layers of configuration combining (I have to
> look at config-generic, then config-$arch-generic, then
> the final config-$specific file to see what the option actually
> is)
> - Keeping the files organized requires manual work and pruning
> 
> I've been thinking about alternatives to the existing config
> generation. One proposal was to take advantage of the upstream
> kernel now supporting config fragments and keep some part of
> the fedora configuration upstream. This would have the disadvantage
> of requiring the configuration to be kept in sync with upstream.
> 
> Another option is to switch to a system of generation where
> each configuration option is kept in a separate file. There
> is no sorting or organization necessary. This would result
> in a lot of small files for all the arches Fedora supports though.

Hi Laura,

Just to throw it out there,  RHEL has been using the one option per file
mechanism for years now with success.  Minimizes the maintenance and
conflicts.  ( I know you already know that, just wanted to publicly state
that).

The volume of files is large, but it is hidden away and you only package the
resulting kernel.config files into the src.rpm.

Just a thought.

Cheers,
Don

> 
> Anyone have experiences with or opinions about the kernel
> configuration generation? The goal is to only change the way
> the configurations are generated and not the options that are
> enabled.
> 
> Thanks,
> Laura
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Re: Kernel configurations for Fedora

[Paul Bolle]

On Tue, 2016-10-25 at 10:46 -0700, Laura Abbott wrote:
> Anyone have experiences with or opinions about the kernel
> configuration generation? The goal is to only change the way
> the configurations are generated and not the options that are
> enabled.

Naive question: why can't we use one .config per target?


Paul Bolle
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org

Kernel configurations for Fedora

[Laura Abbott]

The Fedora kernel has had roughly the same system for generating
the kernel configuration for a very long time. There are a series
of files listing configuration choices (CONFIG_FOO=y, CONFIG_FOO
is not set etc.) that get combined to generate the final config
files. This has gotten unsustainable for several reasons:

- When the system was first introduced, the only supported
arches were x86_32 and x86_64. Fedora now supports enough
other arches that we have a config-$arch-generic in addition to
config-generic
- It's difficult to tell what is actually enabled since
there are several layers of configuration combining (I have to
look at config-generic, then config-$arch-generic, then
the final config-$specific file to see what the option actually
is)
- Keeping the files organized requires manual work and pruning

I've been thinking about alternatives to the existing config
generation. One proposal was to take advantage of the upstream
kernel now supporting config fragments and keep some part of
the fedora configuration upstream. This would have the disadvantage
of requiring the configuration to be kept in sync with upstream.

Another option is to switch to a system of generation where
each configuration option is kept in a separate file. There
is no sorting or organization necessary. This would result
in a lot of small files for all the arches Fedora supports though.

Anyone have experiences with or opinions about the kernel
configuration generation? The goal is to only change the way
the configurations are generated and not the options that are
enabled.

Thanks,
Laura
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org