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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 2 Jan 2021 15:44:19 -0500 From: "Theodore Ts'o" <tytso@....edu> To: Hongyi Zhao <hongyi.zhao@...il.com> Cc: linux-kernel@...r.kernel.org Subject: Re: Generate the config file for kernel compilation non-interactively in script. 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
Powered by blists - more mailing lists