All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Hongyi Zhao <hongyi.zhao@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Generate the config file for kernel compilation non-interactively in script.
Date: Sat, 2 Jan 2021 15:44:19 -0500	[thread overview]
Message-ID: <X/DbIyM2aUn+ZSCO@mit.edu> (raw)
In-Reply-To: <CAGP6POJ1pRgSP+FSC2ds9afx4rDxm0BkbKK-RAJQuwLUE_2WhQ@mail.gmail.com>

On Fri, Jan 01, 2021 at 12:51:13PM +0800, Hongyi Zhao wrote:
> 
> I want to build the realtime Linux for ROS 2 according to the
> guidelines here:
> <https://index.ros.org/doc/ros2/Tutorials/Building-Realtime-rt_preempt-kernel-for-ROS-2/>.
> 
> For this purpose, I must enable the rt_preempt relative options in the
> kernel withe the following method interactively:
> 
> But this is very inconvenient for doing the above job in script. Is
> there an alternative method to generate the above configurations for
> kernel compilation  non-interactively in script.

What I do for a slightly different use case is to use defconfigs.
After setting up a minimum kernel that has what I need for my use case
(in my case, to build a kernel that works for kvm-xfstests and
gce-xfststs), I save a defconfig: "make savedefconfig", and then stash
in a git repository:

https://github.com/tytso/xfstests-bld/tree/master/kernel-configs

Then when I need to build a kernel, I just copy a defconfig to
.config, and then run the command "make olddefconfig" to expand it
out.  The reason why I use defconfigs is that very often, at least for
my use cases, a defconfig generated for kernel version X.Y tends to
work for X.Y+1, X.Y+2, etc.  That's not always true, of course, which
is why there are a few extra lines added to:

https://github.com/tytso/xfstests-bld/blob/master/kernel-configs/x86_64-config-4.19

This was needed so that the this defconfig will work for 4.19.y
through 5.3.y.  The special cases were needed for 5.1 and 5.2, but I
haven't needed it for any other kernel versions in terms of making a
kernel that would correctly boot on KVM and GCE and correctly run
xfstests for ext4, xfs, btrfs, f2fs, etc.  So I just create a
defconfig for each LTS kernel version, and for the most part, it will
work for future kernel versions until the next LTS kerenl version gets
released, at which point I create a new defconfig for my test
appliance use case.

If your goal is to build newer kernel versions for RT_PREMPT kernels
for your use case, perhaps this technique will be helpful for you.

Hope this helps,

					- Ted

      parent reply	other threads:[~2021-01-02 20:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-01  4:51 Generate the config file for kernel compilation non-interactively in script Hongyi Zhao
2021-01-01  6:32 ` Randy Dunlap
2021-01-01  9:55   ` Hongyi Zhao
2021-01-01 16:28     ` Randy Dunlap
2021-01-02  0:12       ` Hongyi Zhao
2021-01-02  0:28   ` Hongyi Zhao
2021-01-02 20:44 ` Theodore Ts'o [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=X/DbIyM2aUn+ZSCO@mit.edu \
    --to=tytso@mit.edu \
    --cc=hongyi.zhao@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.