On Tue, Apr 23, 2024 at 11:39:59AM -0500, Bilbao, Carlos wrote: > > If I may offer a suggestion, focusing on documenting the challenges you've > encountered with KVM, etc., could be more valuable that trying to cover > everything. Many people have their own scripts for building and testing kernels. Very often those scripts tend to be specialized for a particular use case, or development workflow, and trying to enshrine it as _the_ way to develop kernels may not all that helpful. For example, my preferred workflow, and the one which I recommend to people who want to contribute to my file system, will build kernels which can then be used to run tests using either kvm/qemu, Google Compute Engine, or on Android devices. It's also a bit more turn-key that the instructions that you've given which is both a plus and a minus. On the plus side, it means much easier to get started, and they don't have to cut and paste expect scripts, and manually edit kernel config files. On the minus side, because a lot of the steps are automated, people don't have as much of an opportunity to learn about what various kernel config options mean. If you're interested, documentation for my scripts can be found here: https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-quickstart.md https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-xfstests.md https://thunk.org/gce-xfstests The short version is after you've downloaded the git tree, installed the binaries via "make install", and installed some package dependencies, setting up a kernel config which is suitable for KVM, a GCE VM, or Android, is done via: install-kconfig Then building a kernel is done via: kbuild And then running said kernel under KVM is done via: kvm-xfstests shell Or if you want to run a file system smoke test: kvm-xfstests smoke It was designed so that even graduate students who have no interest in kernel development other than getting their FAST academic paper published, can use it to test their research file systems, hopefully helping them to understand the gulf that can sometimes exist between research prototypes and production file systems. :-) - Ted
