Feedback on my development setup

Feedback on my development setup

[Josh Marshall]

Hello all,

I am trying to work on and improve some aspects of the "fanotify"
parts of the VFS subsystem with Amir Goldstein being the person I
brought these to.  Amir has me doing some work to see what is going on
since I have observed some unexpected behaviors.  In doing so, I have
cobbled together the following iteration pattern which I would like
feedback on.  It doesn't feel like it is as concise as it should be in
practice and I am hoping someone can offer pointers on how to improve
it.  By the end of this, I would like to have a fully documented and
replicable script to share for certain kinds of non-hardware kernel
development like I am doing here.  As a word of warning, I haven't
gotten to fully test this either.  It feels like I'm trying to cut
down a hydra with everything new I need to account for.

```
Source:
https://github.com/archlinux/arch-boxes

Term 1:
guestmount -w -a ~/Downloads/Arch-Linux-x86_64-basic.qcow2 -m
/dev/sda3 ~/mnt/arch/
<copy sources, files, perform compilation steps, etc as needed to
inside the VM image as needed each development iteration>
cp ~/mnt/ arch/home/arch/linux/boot/x86/vmlinux .
umount ~/mnt/arch

Term 2:
kvm -s -cpu host -display gtk -vga qxl -accel kvm -drive
format=qcow2,file=$HOME/Downloads/Arch-Linux-x86_64-basic.qcow2 -m 1G
-smp 2 -S

Term 3:
gdb vmlinux
: target remote:1234
<set break points>
: continue

Qemu:
<time sensitive, boot into the right kernel if available>
<perform development tasks>
```

Re: Feedback on my development setup

[ngn]

On Tue, Apr 16, 2024 at 08:38:54AM -0400, Josh Marshall wrote:
> Hello all,
> 
> I am trying to work on and improve some aspects of the "fanotify"
> parts of the VFS subsystem with Amir Goldstein being the person I
> brought these to.  Amir has me doing some work to see what is going on
> since I have observed some unexpected behaviors.  In doing so, I have
> cobbled together the following iteration pattern which I would like
> feedback on.  It doesn't feel like it is as concise as it should be in
> practice and I am hoping someone can offer pointers on how to improve
> it.  By the end of this, I would like to have a fully documented and
> replicable script to share for certain kinds of non-hardware kernel
> development like I am doing here.  As a word of warning, I haven't
> gotten to fully test this either.  It feels like I'm trying to cut
> down a hydra with everything new I need to account for.
> 
> ```
> Source:
> https://github.com/archlinux/arch-boxes
> 
> Term 1:
> guestmount -w -a ~/Downloads/Arch-Linux-x86_64-basic.qcow2 -m
> /dev/sda3 ~/mnt/arch/
> <copy sources, files, perform compilation steps, etc as needed to
> inside the VM image as needed each development iteration>
> cp ~/mnt/ arch/home/arch/linux/boot/x86/vmlinux .
> umount ~/mnt/arch
> 
> Term 2:
> kvm -s -cpu host -display gtk -vga qxl -accel kvm -drive
> format=qcow2,file=$HOME/Downloads/Arch-Linux-x86_64-basic.qcow2 -m 1G
> -smp 2 -S
> 
> Term 3:
> gdb vmlinux
> : target remote:1234
> <set break points>
> : continue
> 
> Qemu:
> <time sensitive, boot into the right kernel if available>
> <perform development tasks>
> ```
> 

Hello,

You don't have to mount and copy over the vmlinux file, QEMU/KVM has the -kernel option, 
which you can use to specify the kernel image:

kvm -s cpu host                                   \
    -display gtk                                  \
    -vga qxl                                      \
    -accel kvm                                    \
    -m 1G                                         \
    -kernel arch/home/arch/linux/boot/x86/vmlinux \
    -drive format=qcow2,file=$HOME/Downloads/Arch-Linux-x86_64-basic.qcow2

However you will need mount and copy any modules you build to the /lib/modules
directory or you won't be able to load them.

Re: Feedback on my development setup

[Josh Marshall]

I tried that, but there was some non-descript error with code -2 (any
major error) about launching the init process for [init,
rdinit]=/lib/systemd and /usr/bin/bash.  Can you provide a working
sample?  Sorry if I'm being difficult.  I am really tired of dead ends
and trying them alone.

On Tue, Apr 16, 2024 at 10:56 AM ngn <ngn@ngn.tf> wrote:
>
> On Tue, Apr 16, 2024 at 08:38:54AM -0400, Josh Marshall wrote:
> > Hello all,
> >
> > I am trying to work on and improve some aspects of the "fanotify"
> > parts of the VFS subsystem with Amir Goldstein being the person I
> > brought these to.  Amir has me doing some work to see what is going on
> > since I have observed some unexpected behaviors.  In doing so, I have
> > cobbled together the following iteration pattern which I would like
> > feedback on.  It doesn't feel like it is as concise as it should be in
> > practice and I am hoping someone can offer pointers on how to improve
> > it.  By the end of this, I would like to have a fully documented and
> > replicable script to share for certain kinds of non-hardware kernel
> > development like I am doing here.  As a word of warning, I haven't
> > gotten to fully test this either.  It feels like I'm trying to cut
> > down a hydra with everything new I need to account for.
> >
> > ```
> > Source:
> > https://github.com/archlinux/arch-boxes
> >
> > Term 1:
> > guestmount -w -a ~/Downloads/Arch-Linux-x86_64-basic.qcow2 -m
> > /dev/sda3 ~/mnt/arch/
> > <copy sources, files, perform compilation steps, etc as needed to
> > inside the VM image as needed each development iteration>
> > cp ~/mnt/ arch/home/arch/linux/boot/x86/vmlinux .
> > umount ~/mnt/arch
> >
> > Term 2:
> > kvm -s -cpu host -display gtk -vga qxl -accel kvm -drive
> > format=qcow2,file=$HOME/Downloads/Arch-Linux-x86_64-basic.qcow2 -m 1G
> > -smp 2 -S
> >
> > Term 3:
> > gdb vmlinux
> > : target remote:1234
> > <set break points>
> > : continue
> >
> > Qemu:
> > <time sensitive, boot into the right kernel if available>
> > <perform development tasks>
> > ```
> >
>
> Hello,
>
> You don't have to mount and copy over the vmlinux file, QEMU/KVM has the -kernel option,
> which you can use to specify the kernel image:
>
> kvm -s cpu host                                   \
>     -display gtk                                  \
>     -vga qxl                                      \
>     -accel kvm                                    \
>     -m 1G                                         \
>     -kernel arch/home/arch/linux/boot/x86/vmlinux \
>     -drive format=qcow2,file=$HOME/Downloads/Arch-Linux-x86_64-basic.qcow2
>
> However you will need mount and copy any modules you build to the /lib/modules
> directory or you won't be able to load them.

Re: Feedback on my development setup

[ngn]

On Tue, Apr 16, 2024 at 11:03:52AM -0400, Josh Marshall wrote:
> I tried that, but there was some non-descript error with code -2 (any
> major error) about launching the init process for [init,
> rdinit]=/lib/systemd and /usr/bin/bash.  Can you provide a working
> sample?  Sorry if I'm being difficult.  I am really tired of dead ends
> and trying them alone.
> 

If the kernel fails to start the init, try adding the -append "root=/dev/sda rw" option:

qemu-system-x86_64 -s -cpu host                   \
    -display gtk                                  \
    -vga qxl                                      \
    -accel kvm                                    \
    -m 1G                                         \
    -kernel arch/home/arch/linux/boot/x86/vmlinux \
    -append "root=/dev/sda rw"                    \
    -drive format=qcow2,file=$HOME/Downloads/Arch-Linux-x86_64-basic.qcow

Re: Feedback on my development setup

[Josh Marshall]

Further tweaking to use sda3 for the root partition in the disk, I get
the following: success!

This is a pretty good setup now but it could use an automation harness
and documentation.  I'm willing to make the script and write-up.
Where should I post it?  My inclination would be to submit it
somewhere near https://docs.kernel.org/kernel-hacking/hacking.html .

On Tue, Apr 16, 2024 at 11:22 AM ngn <ngn@ngn.tf> wrote:
>
> On Tue, Apr 16, 2024 at 11:03:52AM -0400, Josh Marshall wrote:
> > I tried that, but there was some non-descript error with code -2 (any
> > major error) about launching the init process for [init,
> > rdinit]=/lib/systemd and /usr/bin/bash.  Can you provide a working
> > sample?  Sorry if I'm being difficult.  I am really tired of dead ends
> > and trying them alone.
> >
>
> If the kernel fails to start the init, try adding the -append "root=/dev/sda rw" option:
>
> qemu-system-x86_64 -s -cpu host                   \
>     -display gtk                                  \
>     -vga qxl                                      \
>     -accel kvm                                    \
>     -m 1G                                         \
>     -kernel arch/home/arch/linux/boot/x86/vmlinux \
>     -append "root=/dev/sda rw"                    \
>     -drive format=qcow2,file=$HOME/Downloads/Arch-Linux-x86_64-basic.qcow

Re: Feedback on my development setup

[Josh Marshall]

One issue I'm seeing is that gdb isn't seeing debugging symbols.  I'm
getting the following output with the config linked.

https://pastebin.com/tjq7QtQk

```
anadon@botamon:~/Documents/code/linux$ gdb arch/x86/boot/bzImage
GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from arch/x86/boot/bzImage...
(No debugging symbols found in arch/x86/boot/bzImage)
```

On Wed, Apr 17, 2024 at 1:28 PM Samantha Miyamoto
<samantha.miyamoto10@gmail.com> wrote:
>
> Hi Josh and admins,
>
> I would appreciate reading the docs - I’m pretty new and have dreams of tinkering sometime. Thank you for the work you do.
>
> Sam
>
> On Wed, Apr 17, 2024 at 9:22 AM Josh Marshall <joshua.r.marshall.1991@gmail.com> wrote:
>>
>> Further tweaking to use sda3 for the root partition in the disk, I get
>> the following: success!
>>
>> This is a pretty good setup now but it could use an automation harness
>> and documentation.  I'm willing to make the script and write-up.
>> Where should I post it?  My inclination would be to submit it
>> somewhere near https://docs.kernel.org/kernel-hacking/hacking.html .
>>
>> On Tue, Apr 16, 2024 at 11:22 AM ngn <ngn@ngn.tf> wrote:
>> >
>> > On Tue, Apr 16, 2024 at 11:03:52AM -0400, Josh Marshall wrote:
>> > > I tried that, but there was some non-descript error with code -2 (any
>> > > major error) about launching the init process for [init,
>> > > rdinit]=/lib/systemd and /usr/bin/bash.  Can you provide a working
>> > > sample?  Sorry if I'm being difficult.  I am really tired of dead ends
>> > > and trying them alone.
>> > >
>> >
>> > If the kernel fails to start the init, try adding the -append "root=/dev/sda rw" option:
>> >
>> > qemu-system-x86_64 -s -cpu host                   \
>> >     -display gtk                                  \
>> >     -vga qxl                                      \
>> >     -accel kvm                                    \
>> >     -m 1G                                         \
>> >     -kernel arch/home/arch/linux/boot/x86/vmlinux \
>> >     -append "root=/dev/sda rw"                    \
>> >     -drive format=qcow2,file=$HOME/Downloads/Arch-Linux-x86_64-basic.qcow
>>

Re: Feedback on my development setup

[ngn]

On Wed, Apr 17, 2024 at 05:18:34PM -0400, Josh Marshall wrote:
> One issue I'm seeing is that gdb isn't seeing debugging symbols.  I'm
> getting the following output with the config linked.
> 
> https://pastebin.com/tjq7QtQk
> 
> ```
> anadon@botamon:~/Documents/code/linux$ gdb arch/x86/boot/bzImage
> GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git
> Copyright (C) 2024 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <https://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
>     <http://www.gnu.org/software/gdb/documentation/>.
> 
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from arch/x86/boot/bzImage...
> (No debugging symbols found in arch/x86/boot/bzImage)
> ```
> 

You should load vmlinux to the gdb, not the bzImage. bzImage is a
compressed version of the kernel and its used boot, vmlinux is the
static ELF binary that contains the debugging symbols.

Re: Feedback on my development setup

[Josh Marshall]

So the final outline would look like the following?

Source:
https://github.com/archlinux/arch-boxes

setup:

git clone $LINUX_REPO &
wget https://geo.mirror.pkgbuild.com/images/latest/Arch-Linux-x86_64-basic.qcow2

echo add-auto-load-safe-path
“$LINUX_REPO_PATH/scripts/gdb/vmlinux-gdb.py” >>
"$HOME/.config/gdb/gdbinit"

echo ‘export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1’ >> $HOME/.bashrc
echo ‘export USERCFLAGS=" -ggdb "’ >> $HOME/.bashrc

push $LINUX_REPO_PATH

echo “CONFIG_SATA_AHCI=y” >> .config
echo “CONFIG_DEBUG_INFO=y” >> .config
echo “CONFIG_DEBUG_INFO_DWARF5=y” >> .config
echo “CONFIG_GDB_SCRIPTS=y” >> .config
echo “CONFIG_GDB_INFO_REDUCED=n” >> .config
echo “CONFIG_KGDB=y” >> .config
echo “CONFIG_FRAME_POINTER=y” >> .config
echo “CONFIG_KVM_GUEST=y” >> .config
echo “CONFIG_RANDOMIZE_BASE=n” >> .config

make localyesconfig
pop

source $HOME/.bashrc
mkdir -p $HOME/mnt/arch

Iterate:
guestmount  -w -a $HOME/Downloads/Arch-Linux-x86_64-basic.qcow2 -m
/dev/sda3 ~/mnt/arch/
<copy sources, files, perform compilation steps, etc as needed to
inside the VM image as needed each development iteration>
umount ~/mnt/arch

Term 1:
qemu-system-x86_64 -s -cpu host -nographic -accel kvm -m 1G -kernel
vmlinux2 -append "root=/dev/sda3 rw console=ttyS0,115200n8 nokaslr
" -drive format=qcow2,file=$HOME/Downloads/Arch-Linux-x86_64-basic.qcow2

Term 2:
gdb $LINUX_REPO_PATH/vmlinux
: target remote:1234
<set break points>
: continue

On Thu, Apr 18, 2024 at 11:36 AM ngn <ngn@ngn.tf> wrote:
>
> On Wed, Apr 17, 2024 at 05:18:34PM -0400, Josh Marshall wrote:
> > One issue I'm seeing is that gdb isn't seeing debugging symbols.  I'm
> > getting the following output with the config linked.
> >
> > https://pastebin.com/tjq7QtQk
> >
> > ```
> > anadon@botamon:~/Documents/code/linux$ gdb arch/x86/boot/bzImage
> > GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git
> > Copyright (C) 2024 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law.
> > Type "show copying" and "show warranty" for details.
> > This GDB was configured as "x86_64-linux-gnu".
> > Type "show configuration" for configuration details.
> > For bug reporting instructions, please see:
> > <https://www.gnu.org/software/gdb/bugs/>.
> > Find the GDB manual and other documentation resources online at:
> >     <http://www.gnu.org/software/gdb/documentation/>.
> >
> > For help, type "help".
> > Type "apropos word" to search for commands related to "word"...
> > Reading symbols from arch/x86/boot/bzImage...
> > (No debugging symbols found in arch/x86/boot/bzImage)
> > ```
> >
>
> You should load vmlinux to the gdb, not the bzImage. bzImage is a
> compressed version of the kernel and its used boot, vmlinux is the
> static ELF binary that contains the debugging symbols.

Re: Feedback on my development setup

[Josh Marshall]

There's a type already.  Term 1 should be:

qemu-system-x86_64 -s -cpu host -nographic -accel kvm -m 1G -kernel
arch/x86/boot/bzImage -append "root=/dev/sdb3 rw
console=ttyS0,115200n8" -drive
format=qcow2,file=$HOME/Downloads/Arch-Linux-x86_64-basic.qcow2

However, the kernel panics because it can't mount the root FS on an
unknown block.  I don't know what the cause is.  However, the UUIDs
are scrambled from what are in GRUB.  Is there some sort of security
going on here?

On Thu, Apr 18, 2024 at 3:15 PM Josh Marshall
<joshua.r.marshall.1991@gmail.com> wrote:
>
> So the final outline would look like the following?
>
> Source:
> https://github.com/archlinux/arch-boxes
>
> setup:
>
> git clone $LINUX_REPO &
> wget https://geo.mirror.pkgbuild.com/images/latest/Arch-Linux-x86_64-basic.qcow2
>
> echo add-auto-load-safe-path
> “$LINUX_REPO_PATH/scripts/gdb/vmlinux-gdb.py” >>
> "$HOME/.config/gdb/gdbinit"
>
> echo ‘export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1’ >> $HOME/.bashrc
> echo ‘export USERCFLAGS=" -ggdb "’ >> $HOME/.bashrc
>
> push $LINUX_REPO_PATH
>
> echo “CONFIG_SATA_AHCI=y” >> .config
> echo “CONFIG_DEBUG_INFO=y” >> .config
> echo “CONFIG_DEBUG_INFO_DWARF5=y” >> .config
> echo “CONFIG_GDB_SCRIPTS=y” >> .config
> echo “CONFIG_GDB_INFO_REDUCED=n” >> .config
> echo “CONFIG_KGDB=y” >> .config
> echo “CONFIG_FRAME_POINTER=y” >> .config
> echo “CONFIG_KVM_GUEST=y” >> .config
> echo “CONFIG_RANDOMIZE_BASE=n” >> .config
>
> make localyesconfig
> pop
>
> source $HOME/.bashrc
> mkdir -p $HOME/mnt/arch
>
> Iterate:
> guestmount  -w -a $HOME/Downloads/Arch-Linux-x86_64-basic.qcow2 -m
> /dev/sda3 ~/mnt/arch/
> <copy sources, files, perform compilation steps, etc as needed to
> inside the VM image as needed each development iteration>
> umount ~/mnt/arch
>
> Term 1:
> qemu-system-x86_64 -s -cpu host -nographic -accel kvm -m 1G -kernel
> vmlinux2 -append "root=/dev/sda3 rw console=ttyS0,115200n8 nokaslr
> " -drive format=qcow2,file=$HOME/Downloads/Arch-Linux-x86_64-basic.qcow2
>
> Term 2:
> gdb $LINUX_REPO_PATH/vmlinux
> : target remote:1234
> <set break points>
> : continue
>
> On Thu, Apr 18, 2024 at 11:36 AM ngn <ngn@ngn.tf> wrote:
> >
> > On Wed, Apr 17, 2024 at 05:18:34PM -0400, Josh Marshall wrote:
> > > One issue I'm seeing is that gdb isn't seeing debugging symbols.  I'm
> > > getting the following output with the config linked.
> > >
> > > https://pastebin.com/tjq7QtQk
> > >
> > > ```
> > > anadon@botamon:~/Documents/code/linux$ gdb arch/x86/boot/bzImage
> > > GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git
> > > Copyright (C) 2024 Free Software Foundation, Inc.
> > > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> > > This is free software: you are free to change and redistribute it.
> > > There is NO WARRANTY, to the extent permitted by law.
> > > Type "show copying" and "show warranty" for details.
> > > This GDB was configured as "x86_64-linux-gnu".
> > > Type "show configuration" for configuration details.
> > > For bug reporting instructions, please see:
> > > <https://www.gnu.org/software/gdb/bugs/>.
> > > Find the GDB manual and other documentation resources online at:
> > >     <http://www.gnu.org/software/gdb/documentation/>.
> > >
> > > For help, type "help".
> > > Type "apropos word" to search for commands related to "word"...
> > > Reading symbols from arch/x86/boot/bzImage...
> > > (No debugging symbols found in arch/x86/boot/bzImage)
> > > ```
> > >
> >
> > You should load vmlinux to the gdb, not the bzImage. bzImage is a
> > compressed version of the kernel and its used boot, vmlinux is the
> > static ELF binary that contains the debugging symbols.

Re: Feedback on my development setup

[Josh Marshall]

Looks like there are some fiddly bits about configuring the kernel.
Practically speaking, configuration needs to first be done within the
VM, then everything can be moved and compiled outside of it.

How do I submit a final writeup to put somewhere?

On Thu, Apr 18, 2024 at 3:27 PM Josh Marshall
<joshua.r.marshall.1991@gmail.com> wrote:
>
> There's a type already.  Term 1 should be:
>
> qemu-system-x86_64 -s -cpu host -nographic -accel kvm -m 1G -kernel
> arch/x86/boot/bzImage -append "root=/dev/sdb3 rw
> console=ttyS0,115200n8" -drive
> format=qcow2,file=$HOME/Downloads/Arch-Linux-x86_64-basic.qcow2
>
> However, the kernel panics because it can't mount the root FS on an
> unknown block.  I don't know what the cause is.  However, the UUIDs
> are scrambled from what are in GRUB.  Is there some sort of security
> going on here?
>
> On Thu, Apr 18, 2024 at 3:15 PM Josh Marshall
> <joshua.r.marshall.1991@gmail.com> wrote:
> >
> > So the final outline would look like the following?
> >
> > Source:
> > https://github.com/archlinux/arch-boxes
> >
> > setup:
> >
> > git clone $LINUX_REPO &
> > wget https://geo.mirror.pkgbuild.com/images/latest/Arch-Linux-x86_64-basic.qcow2
> >
> > echo add-auto-load-safe-path
> > “$LINUX_REPO_PATH/scripts/gdb/vmlinux-gdb.py” >>
> > "$HOME/.config/gdb/gdbinit"
> >
> > echo ‘export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1’ >> $HOME/.bashrc
> > echo ‘export USERCFLAGS=" -ggdb "’ >> $HOME/.bashrc
> >
> > push $LINUX_REPO_PATH
> >
> > echo “CONFIG_SATA_AHCI=y” >> .config
> > echo “CONFIG_DEBUG_INFO=y” >> .config
> > echo “CONFIG_DEBUG_INFO_DWARF5=y” >> .config
> > echo “CONFIG_GDB_SCRIPTS=y” >> .config
> > echo “CONFIG_GDB_INFO_REDUCED=n” >> .config
> > echo “CONFIG_KGDB=y” >> .config
> > echo “CONFIG_FRAME_POINTER=y” >> .config
> > echo “CONFIG_KVM_GUEST=y” >> .config
> > echo “CONFIG_RANDOMIZE_BASE=n” >> .config
> >
> > make localyesconfig
> > pop
> >
> > source $HOME/.bashrc
> > mkdir -p $HOME/mnt/arch
> >
> > Iterate:
> > guestmount  -w -a $HOME/Downloads/Arch-Linux-x86_64-basic.qcow2 -m
> > /dev/sda3 ~/mnt/arch/
> > <copy sources, files, perform compilation steps, etc as needed to
> > inside the VM image as needed each development iteration>
> > umount ~/mnt/arch
> >
> > Term 1:
> > qemu-system-x86_64 -s -cpu host -nographic -accel kvm -m 1G -kernel
> > vmlinux2 -append "root=/dev/sda3 rw console=ttyS0,115200n8 nokaslr
> > " -drive format=qcow2,file=$HOME/Downloads/Arch-Linux-x86_64-basic.qcow2
> >
> > Term 2:
> > gdb $LINUX_REPO_PATH/vmlinux
> > : target remote:1234
> > <set break points>
> > : continue
> >
> > On Thu, Apr 18, 2024 at 11:36 AM ngn <ngn@ngn.tf> wrote:
> > >
> > > On Wed, Apr 17, 2024 at 05:18:34PM -0400, Josh Marshall wrote:
> > > > One issue I'm seeing is that gdb isn't seeing debugging symbols.  I'm
> > > > getting the following output with the config linked.
> > > >
> > > > https://pastebin.com/tjq7QtQk
> > > >
> > > > ```
> > > > anadon@botamon:~/Documents/code/linux$ gdb arch/x86/boot/bzImage
> > > > GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git
> > > > Copyright (C) 2024 Free Software Foundation, Inc.
> > > > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> > > > This is free software: you are free to change and redistribute it.
> > > > There is NO WARRANTY, to the extent permitted by law.
> > > > Type "show copying" and "show warranty" for details.
> > > > This GDB was configured as "x86_64-linux-gnu".
> > > > Type "show configuration" for configuration details.
> > > > For bug reporting instructions, please see:
> > > > <https://www.gnu.org/software/gdb/bugs/>.
> > > > Find the GDB manual and other documentation resources online at:
> > > >     <http://www.gnu.org/software/gdb/documentation/>.
> > > >
> > > > For help, type "help".
> > > > Type "apropos word" to search for commands related to "word"...
> > > > Reading symbols from arch/x86/boot/bzImage...
> > > > (No debugging symbols found in arch/x86/boot/bzImage)
> > > > ```
> > > >
> > >
> > > You should load vmlinux to the gdb, not the bzImage. bzImage is a
> > > compressed version of the kernel and its used boot, vmlinux is the
> > > static ELF binary that contains the debugging symbols.

Re: Feedback on my development setup

[Josh Marshall]

Looks like breakpoints aren't working?  https://paste.debian.net/1314501/

On Thu, Apr 18, 2024 at 3:52 PM Josh Marshall
<joshua.r.marshall.1991@gmail.com> wrote:
>
> Looks like there are some fiddly bits about configuring the kernel.
> Practically speaking, configuration needs to first be done within the
> VM, then everything can be moved and compiled outside of it.
>
> How do I submit a final writeup to put somewhere?
>
> On Thu, Apr 18, 2024 at 3:27 PM Josh Marshall
> <joshua.r.marshall.1991@gmail.com> wrote:
> >
> > There's a type already.  Term 1 should be:
> >
> > qemu-system-x86_64 -s -cpu host -nographic -accel kvm -m 1G -kernel
> > arch/x86/boot/bzImage -append "root=/dev/sdb3 rw
> > console=ttyS0,115200n8" -drive
> > format=qcow2,file=$HOME/Downloads/Arch-Linux-x86_64-basic.qcow2
> >
> > However, the kernel panics because it can't mount the root FS on an
> > unknown block.  I don't know what the cause is.  However, the UUIDs
> > are scrambled from what are in GRUB.  Is there some sort of security
> > going on here?
> >
> > On Thu, Apr 18, 2024 at 3:15 PM Josh Marshall
> > <joshua.r.marshall.1991@gmail.com> wrote:
> > >
> > > So the final outline would look like the following?
> > >
> > > Source:
> > > https://github.com/archlinux/arch-boxes
> > >
> > > setup:
> > >
> > > git clone $LINUX_REPO &
> > > wget https://geo.mirror.pkgbuild.com/images/latest/Arch-Linux-x86_64-basic.qcow2
> > >
> > > echo add-auto-load-safe-path
> > > “$LINUX_REPO_PATH/scripts/gdb/vmlinux-gdb.py” >>
> > > "$HOME/.config/gdb/gdbinit"
> > >
> > > echo ‘export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1’ >> $HOME/.bashrc
> > > echo ‘export USERCFLAGS=" -ggdb "’ >> $HOME/.bashrc
> > >
> > > push $LINUX_REPO_PATH
> > >
> > > echo “CONFIG_SATA_AHCI=y” >> .config
> > > echo “CONFIG_DEBUG_INFO=y” >> .config
> > > echo “CONFIG_DEBUG_INFO_DWARF5=y” >> .config
> > > echo “CONFIG_GDB_SCRIPTS=y” >> .config
> > > echo “CONFIG_GDB_INFO_REDUCED=n” >> .config
> > > echo “CONFIG_KGDB=y” >> .config
> > > echo “CONFIG_FRAME_POINTER=y” >> .config
> > > echo “CONFIG_KVM_GUEST=y” >> .config
> > > echo “CONFIG_RANDOMIZE_BASE=n” >> .config
> > >
> > > make localyesconfig
> > > pop
> > >
> > > source $HOME/.bashrc
> > > mkdir -p $HOME/mnt/arch
> > >
> > > Iterate:
> > > guestmount  -w -a $HOME/Downloads/Arch-Linux-x86_64-basic.qcow2 -m
> > > /dev/sda3 ~/mnt/arch/
> > > <copy sources, files, perform compilation steps, etc as needed to
> > > inside the VM image as needed each development iteration>
> > > umount ~/mnt/arch
> > >
> > > Term 1:
> > > qemu-system-x86_64 -s -cpu host -nographic -accel kvm -m 1G -kernel
> > > vmlinux2 -append "root=/dev/sda3 rw console=ttyS0,115200n8 nokaslr
> > > " -drive format=qcow2,file=$HOME/Downloads/Arch-Linux-x86_64-basic.qcow2
> > >
> > > Term 2:
> > > gdb $LINUX_REPO_PATH/vmlinux
> > > : target remote:1234
> > > <set break points>
> > > : continue
> > >
> > > On Thu, Apr 18, 2024 at 11:36 AM ngn <ngn@ngn.tf> wrote:
> > > >
> > > > On Wed, Apr 17, 2024 at 05:18:34PM -0400, Josh Marshall wrote:
> > > > > One issue I'm seeing is that gdb isn't seeing debugging symbols.  I'm
> > > > > getting the following output with the config linked.
> > > > >
> > > > > https://pastebin.com/tjq7QtQk
> > > > >
> > > > > ```
> > > > > anadon@botamon:~/Documents/code/linux$ gdb arch/x86/boot/bzImage
> > > > > GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git
> > > > > Copyright (C) 2024 Free Software Foundation, Inc.
> > > > > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> > > > > This is free software: you are free to change and redistribute it.
> > > > > There is NO WARRANTY, to the extent permitted by law.
> > > > > Type "show copying" and "show warranty" for details.
> > > > > This GDB was configured as "x86_64-linux-gnu".
> > > > > Type "show configuration" for configuration details.
> > > > > For bug reporting instructions, please see:
> > > > > <https://www.gnu.org/software/gdb/bugs/>.
> > > > > Find the GDB manual and other documentation resources online at:
> > > > >     <http://www.gnu.org/software/gdb/documentation/>.
> > > > >
> > > > > For help, type "help".
> > > > > Type "apropos word" to search for commands related to "word"...
> > > > > Reading symbols from arch/x86/boot/bzImage...
> > > > > (No debugging symbols found in arch/x86/boot/bzImage)
> > > > > ```
> > > > >
> > > >
> > > > You should load vmlinux to the gdb, not the bzImage. bzImage is a
> > > > compressed version of the kernel and its used boot, vmlinux is the
> > > > static ELF binary that contains the debugging symbols.

Re: Feedback on my development setup

[ngn]

On Thu, Apr 18, 2024 at 05:40:20PM -0400, Josh Marshall wrote:
> Looks like breakpoints aren't working?  https://paste.debian.net/1314501/
> 

This maybe caused by Kernel Address Space Randomization (KASLR), try
disabling it by adding nokaslr option to the boot options.

Re: Feedback on my development setup

[Josh Marshall]

I have a draft document which I would like broader review on, which
currently lives here:
https://gitlab.com/anadon/getting-started-on-kernel-dev-guide-workspace.
This document is to ease the setup of Kernel Development.  I intend to
send this in as a patch to the mainline doc tree once it gets by a
suitable number of reviewers.

On Fri, Apr 19, 2024 at 12:15 PM ngn <ngn@ngn.tf> wrote:
>
> On Thu, Apr 18, 2024 at 05:40:20PM -0400, Josh Marshall wrote:
> > Looks like breakpoints aren't working?  https://paste.debian.net/1314501/
> >
>
> This maybe caused by Kernel Address Space Randomization (KASLR), try
> disabling it by adding nokaslr option to the boot options.

Re: Feedback on my development setup

[Pranjal Singh]

On 23/04/24 21:04, Josh Marshall wrote:
> I have a draft document which I would like broader review on, which
> currently lives here:
> https://gitlab.com/anadon/getting-started-on-kernel-dev-guide-workspace.
> This document is to ease the setup of Kernel Development.  I intend to
> send this in as a patch to the mainline doc tree once it gets by a
> suitable number of reviewers.

Hi Josh,
Commendable effort.
I find the doc a little verbose: The official documentation, (for better 
or worse) doesn't explain things in such detail, and assumes 
considerable maturity in OSs and the shell.

For instance, the paragraph in the beginning doesn't give a crisp 
description of what's going on - I think you can split it into two. "It 
uses as an example..." can go to the end. Same goes for the first note: 
are all of the details even needed?

The later sections are user-manual-y: "Here we need to obtain the basic 
materials to work with. These are ..." can be "Download a VM image and 
the Linux source."

Unrelated: a mistake I made many times when compiling Linux was to go 
with [Y]s and [n]s - it may be worth mentioning in that section that 
some prompts take an empty string for an answer, at least in Debian/Ubuntu.

Disclaimer: Linux Newbie here. Suggestions/disagreement will make my day.
Thanks,
Pranjal

Re: Feedback on my development setup

[Bilbao, Carlos]

Hello Josh,

On 4/23/2024 10:34 AM, Josh Marshall wrote:
> I have a draft document which I would like broader review on, which
> currently lives here:
> https://gitlab.com/anadon/getting-started-on-kernel-dev-guide-workspace.
> This document is to ease the setup of Kernel Development.  I intend to
> send this in as a patch to the mainline doc tree once it gets by a
> suitable number of reviewers.

It's great that you're interested in improving the documentation. I've CCed
linux-doc list for visibility.

However, please note that we already have existing documentation, and it
might be better to extend what's already there rather than creating
something entirely new. You can refer to:

https://www.kernel.org/doc/html/latest/process/development-process.html

If you still feel the need to start a new document and host it remotely, I
suggest updating:

https://www.kernel.org/doc/html/v6.1/process/kernel-docs.html

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.

> 
> On Fri, Apr 19, 2024 at 12:15 PM ngn <ngn@ngn.tf> wrote:
>>
>> On Thu, Apr 18, 2024 at 05:40:20PM -0400, Josh Marshall wrote:
>>> Looks like breakpoints aren't working?  https://paste.debian.net/1314501/
>>>
>>
>> This maybe caused by Kernel Address Space Randomization (KASLR), try
>> disabling it by adding nokaslr option to the boot options.

Thanks,
Carlos

Re: Feedback on my development setup

[Josh Marshall]

Hello Carlos,

My intention right now is still to gather feedback on the draft!
Everything, including if it should be sliced and diced into other
places, is up for consideration.  The final intent is a patch into the
central doc tree and not remote documentation.  I'll wait longer to
gather more input before replying to particular points.

On Tue, Apr 23, 2024 at 12:40 PM Bilbao, Carlos <carlos.bilbao@amd.com> wrote:
>
> Hello Josh,
>
> On 4/23/2024 10:34 AM, Josh Marshall wrote:
> > I have a draft document which I would like broader review on, which
> > currently lives here:
> > https://gitlab.com/anadon/getting-started-on-kernel-dev-guide-workspace.
> > This document is to ease the setup of Kernel Development.  I intend to
> > send this in as a patch to the mainline doc tree once it gets by a
> > suitable number of reviewers.
>
> It's great that you're interested in improving the documentation. I've CCed
> linux-doc list for visibility.
>
> However, please note that we already have existing documentation, and it
> might be better to extend what's already there rather than creating
> something entirely new. You can refer to:
>
> https://www.kernel.org/doc/html/latest/process/development-process.html
>
> If you still feel the need to start a new document and host it remotely, I
> suggest updating:
>
> https://www.kernel.org/doc/html/v6.1/process/kernel-docs.html
>
> 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.
>
> >
> > On Fri, Apr 19, 2024 at 12:15 PM ngn <ngn@ngn.tf> wrote:
> >>
> >> On Thu, Apr 18, 2024 at 05:40:20PM -0400, Josh Marshall wrote:
> >>> Looks like breakpoints aren't working?  https://paste.debian.net/1314501/
> >>>
> >>
> >> This maybe caused by Kernel Address Space Randomization (KASLR), try
> >> disabling it by adding nokaslr option to the boot options.
>
> Thanks,
> Carlos

Re: Feedback on my development setup

[Josh Marshall]

Hello everyone,

Last draft before I send in a patch.  Big change is an added preamble
to set tone and intent.  Also some stuff up top setting forth the
structure of the document.  Carlos, I tried figuring out what you
meant by troubles with KVM, but all that boiled down to was scant
documentation on use cases people rarely venture into.  I think that
is a different document from what I am trying to write, although I
might now be qualified to write it.  Pranjal, sorry man, more words :)

https://gitlab.com/anadon/getting-started-on-kernel-dev-guide-workspace/-/blob/main/Linux%20basic%20dev%20setup.rst?ref_type=heads

On Tue, Apr 23, 2024 at 1:43 PM Josh Marshall
<joshua.r.marshall.1991@gmail.com> wrote:
>
> Hello Carlos,
>
> My intention right now is still to gather feedback on the draft!
> Everything, including if it should be sliced and diced into other
> places, is up for consideration.  The final intent is a patch into the
> central doc tree and not remote documentation.  I'll wait longer to
> gather more input before replying to particular points.
>
> On Tue, Apr 23, 2024 at 12:40 PM Bilbao, Carlos <carlos.bilbao@amd.com> wrote:
> >
> > Hello Josh,
> >
> > On 4/23/2024 10:34 AM, Josh Marshall wrote:
> > > I have a draft document which I would like broader review on, which
> > > currently lives here:
> > > https://gitlab.com/anadon/getting-started-on-kernel-dev-guide-workspace.
> > > This document is to ease the setup of Kernel Development.  I intend to
> > > send this in as a patch to the mainline doc tree once it gets by a
> > > suitable number of reviewers.
> >
> > It's great that you're interested in improving the documentation. I've CCed
> > linux-doc list for visibility.
> >
> > However, please note that we already have existing documentation, and it
> > might be better to extend what's already there rather than creating
> > something entirely new. You can refer to:
> >
> > https://www.kernel.org/doc/html/latest/process/development-process.html
> >
> > If you still feel the need to start a new document and host it remotely, I
> > suggest updating:
> >
> > https://www.kernel.org/doc/html/v6.1/process/kernel-docs.html
> >
> > 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.
> >
> > >
> > > On Fri, Apr 19, 2024 at 12:15 PM ngn <ngn@ngn.tf> wrote:
> > >>
> > >> On Thu, Apr 18, 2024 at 05:40:20PM -0400, Josh Marshall wrote:
> > >>> Looks like breakpoints aren't working?  https://paste.debian.net/1314501/
> > >>>
> > >>
> > >> This maybe caused by Kernel Address Space Randomization (KASLR), try
> > >> disabling it by adding nokaslr option to the boot options.
> >
> > Thanks,
> > Carlos

Re: Feedback on my development setup

[Thomas Bertschinger]

On Tue, Apr 23, 2024 at 11:34:36AM -0400, Josh Marshall wrote:
> I have a draft document which I would like broader review on, which
> currently lives here:
> https://gitlab.com/anadon/getting-started-on-kernel-dev-guide-workspace.
> This document is to ease the setup of Kernel Development.  I intend to
> send this in as a patch to the mainline doc tree once it gets by a
> suitable number of reviewers.

Hi Josh,

Rather than using sed to update the config file, you might want to look
at scripts/config. It's a tool that's made for that purpose.

- Thomas Bertschinger

Re: Feedback on my development setup

[Bilbao, Carlos]

Hello Josh,

On 4/25/2024 12:37 AM, Josh Marshall wrote:
> Hello everyone,
> 
> Last draft before I send in a patch.  Big change is an added preamble
> to set tone and intent.  Also some stuff up top setting forth the
> structure of the document.  Carlos, I tried figuring out what you
> meant by troubles with KVM, but all that boiled down to was scant
> documentation on use cases people rarely venture into.  I think that
> is a different document from what I am trying to write, although I
> might now be qualified to write it.  Pranjal, sorry man, more words :)
> 

Exactly. Since you found the KVM documentation to be lacking in detail,
that's an excellent opportunity to expand upon it. That's what I was
suggesting: improving the documentation for these niche cases adds value
and could be included in your potential patch.

Before I talk about specifics of the document, have you thought about where
this text belongs in the broader kernel documentation? It's an important
part of your potential patch. I suggested incorporating it into 'A Guide to
the Kernel Development Process.' Have you had a chance to consider that?

> https://gitlab.com/anadon/getting-started-on-kernel-dev-guide-workspace/-/blob/main/Linux%20basic%20dev%20setup.rst?ref_type=heads
> 

It's difficult for us to discuss the details of your draft like this. It
would be more better if you paste the text directly into the email, and I
can provide inline responses. I'll paste the parts I need.

"
[...]
This document has been viewed through many perspectives from many reviewers,
each wanting a conflicting adaptation. [...]
"

Really? According to your GitLab history, the commit "Draft 1 complete and
ready for the first round of peer reviews!" was 2 days ago. What am I
missing?

"
[...]
`NOTE: On some distributions, kernels (/boot/vmlinuz\*) lack global read
permissions. Administrator permissions are required to make the kernel chosen by
``guestmount`` to be readable. There is debate about the effectiveness of this
security decision. On some distributions like  Ubuntu, this will cause a
problem. In the context of changing a one-off system, having this file globally
read-only is considered safe.`
[...]
"

Please specify the distro you used to prepare this doc.

"
[...]
.. code:: bash

   mkdir -p "$HOME/Documents/linux-workspace/kernel-dev"
   cd "$HOME/Documents/linux-workspace/kernel-dev"
   export LINUX_REPO_PATH="$(pwd)/linux"
[...]
"

Please explain to the reader what these commands are doing and continue to
do so for subsequent commands, as you've already done in some cases.

"
[...]
.. code:: bash

   make -j
[...]
"

s/-j/-j (num cores)

"
[...]
Citations
---------

-  https://github.com/archlinux/arch-boxes
[...]
"

Citations should be numbered and cited in the text where appropriate.

> On Tue, Apr 23, 2024 at 1:43 PM Josh Marshall
> <joshua.r.marshall.1991@gmail.com> wrote:
>>
>> Hello Carlos,
>>
>> My intention right now is still to gather feedback on the draft!
>> Everything, including if it should be sliced and diced into other
>> places, is up for consideration.  The final intent is a patch into the
>> central doc tree and not remote documentation.  I'll wait longer to
>> gather more input before replying to particular points.
>>
>> On Tue, Apr 23, 2024 at 12:40 PM Bilbao, Carlos <carlos.bilbao@amd.com> wrote:
>>>
>>> Hello Josh,
>>>
>>> On 4/23/2024 10:34 AM, Josh Marshall wrote:
>>>> I have a draft document which I would like broader review on, which
>>>> currently lives here:
>>>> https://gitlab.com/anadon/getting-started-on-kernel-dev-guide-workspace.
>>>> This document is to ease the setup of Kernel Development.  I intend to
>>>> send this in as a patch to the mainline doc tree once it gets by a
>>>> suitable number of reviewers.
>>>
>>> It's great that you're interested in improving the documentation. I've CCed
>>> linux-doc list for visibility.
>>>
>>> However, please note that we already have existing documentation, and it
>>> might be better to extend what's already there rather than creating
>>> something entirely new. You can refer to:
>>>
>>> https://www.kernel.org/doc/html/latest/process/development-process.html
>>>
>>> If you still feel the need to start a new document and host it remotely, I
>>> suggest updating:
>>>
>>> https://www.kernel.org/doc/html/v6.1/process/kernel-docs.html
>>>
>>> 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.
>>>
>>>>
>>>> On Fri, Apr 19, 2024 at 12:15 PM ngn <ngn@ngn.tf> wrote:
>>>>>
>>>>> On Thu, Apr 18, 2024 at 05:40:20PM -0400, Josh Marshall wrote:
>>>>>> Looks like breakpoints aren't working?  https://paste.debian.net/1314501/
>>>>>>
>>>>>
>>>>> This maybe caused by Kernel Address Space Randomization (KASLR), try
>>>>> disabling it by adding nokaslr option to the boot options.
>>>
>>> Thanks,
>>> Carlos

Thanks,
Carlos

Re: Feedback on my development setup

[Josh Marshall]

Hello Carlos,

This is a generational shift.  For my peers, we understand the benefit
of keeping everything in a thread.  But at some point it becomes so
verbose and cumbersome as to defeat the purpose.  The size of the text
I'm working with and the number of text changes it has seen meets that
level.  And so I've kept it in git and referenced that.

1) I'm sending this out to people well outside of the mailing list.
It has gotten around.

2) Ubuntu.  That's why it has an explicit callout.  However, in my
research RHEL does not have this issue.  So I added text calling out
this difference.

3) There is some assumed knowledge.  If a reader doesn't know those
commands, honestly, I don't think it is safe for them to start Kernel
development.  As stated in the preamble, this is targeted towards
upper level CS university students and above.

4) I'm considering changing citations to sources.  It might be more
representative.  There's no specific text taken from them, but there
is knowledge referenced from them used to create  the document which I
did not already possess or, in the case of the VM image, a big ol'
file.

On Thu, Apr 25, 2024 at 10:36 AM Bilbao, Carlos <carlos.bilbao@amd.com> wrote:
>
> Hello Josh,
>
> On 4/25/2024 12:37 AM, Josh Marshall wrote:
> > Hello everyone,
> >
> > Last draft before I send in a patch.  Big change is an added preamble
> > to set tone and intent.  Also some stuff up top setting forth the
> > structure of the document.  Carlos, I tried figuring out what you
> > meant by troubles with KVM, but all that boiled down to was scant
> > documentation on use cases people rarely venture into.  I think that
> > is a different document from what I am trying to write, although I
> > might now be qualified to write it.  Pranjal, sorry man, more words :)
> >
>
> Exactly. Since you found the KVM documentation to be lacking in detail,
> that's an excellent opportunity to expand upon it. That's what I was
> suggesting: improving the documentation for these niche cases adds value
> and could be included in your potential patch.
>
> Before I talk about specifics of the document, have you thought about where
> this text belongs in the broader kernel documentation? It's an important
> part of your potential patch. I suggested incorporating it into 'A Guide to
> the Kernel Development Process.' Have you had a chance to consider that?
>
> > https://gitlab.com/anadon/getting-started-on-kernel-dev-guide-workspace/-/blob/main/Linux%20basic%20dev%20setup.rst?ref_type=heads
> >
>
> It's difficult for us to discuss the details of your draft like this. It
> would be more better if you paste the text directly into the email, and I
> can provide inline responses. I'll paste the parts I need.
>
> "
> [...]
> This document has been viewed through many perspectives from many reviewers,
> each wanting a conflicting adaptation. [...]
> "
>
> Really? According to your GitLab history, the commit "Draft 1 complete and
> ready for the first round of peer reviews!" was 2 days ago. What am I
> missing?
>
> "
> [...]
> `NOTE: On some distributions, kernels (/boot/vmlinuz\*) lack global read
> permissions. Administrator permissions are required to make the kernel chosen by
> ``guestmount`` to be readable. There is debate about the effectiveness of this
> security decision. On some distributions like  Ubuntu, this will cause a
> problem. In the context of changing a one-off system, having this file globally
> read-only is considered safe.`
> [...]
> "
>
> Please specify the distro you used to prepare this doc.
>
> "
> [...]
> .. code:: bash
>
>    mkdir -p "$HOME/Documents/linux-workspace/kernel-dev"
>    cd "$HOME/Documents/linux-workspace/kernel-dev"
>    export LINUX_REPO_PATH="$(pwd)/linux"
> [...]
> "
>
> Please explain to the reader what these commands are doing and continue to
> do so for subsequent commands, as you've already done in some cases.
>
> "
> [...]
> .. code:: bash
>
>    make -j
> [...]
> "
>
> s/-j/-j (num cores)
>
> "
> [...]
> Citations
> ---------
>
> -  https://github.com/archlinux/arch-boxes
> [...]
> "
>
> Citations should be numbered and cited in the text where appropriate.
>
> > On Tue, Apr 23, 2024 at 1:43 PM Josh Marshall
> > <joshua.r.marshall.1991@gmail.com> wrote:
> >>
> >> Hello Carlos,
> >>
> >> My intention right now is still to gather feedback on the draft!
> >> Everything, including if it should be sliced and diced into other
> >> places, is up for consideration.  The final intent is a patch into the
> >> central doc tree and not remote documentation.  I'll wait longer to
> >> gather more input before replying to particular points.
> >>
> >> On Tue, Apr 23, 2024 at 12:40 PM Bilbao, Carlos <carlos.bilbao@amd.com> wrote:
> >>>
> >>> Hello Josh,
> >>>
> >>> On 4/23/2024 10:34 AM, Josh Marshall wrote:
> >>>> I have a draft document which I would like broader review on, which
> >>>> currently lives here:
> >>>> https://gitlab.com/anadon/getting-started-on-kernel-dev-guide-workspace.
> >>>> This document is to ease the setup of Kernel Development.  I intend to
> >>>> send this in as a patch to the mainline doc tree once it gets by a
> >>>> suitable number of reviewers.
> >>>
> >>> It's great that you're interested in improving the documentation. I've CCed
> >>> linux-doc list for visibility.
> >>>
> >>> However, please note that we already have existing documentation, and it
> >>> might be better to extend what's already there rather than creating
> >>> something entirely new. You can refer to:
> >>>
> >>> https://www.kernel.org/doc/html/latest/process/development-process.html
> >>>
> >>> If you still feel the need to start a new document and host it remotely, I
> >>> suggest updating:
> >>>
> >>> https://www.kernel.org/doc/html/v6.1/process/kernel-docs.html
> >>>
> >>> 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.
> >>>
> >>>>
> >>>> On Fri, Apr 19, 2024 at 12:15 PM ngn <ngn@ngn.tf> wrote:
> >>>>>
> >>>>> On Thu, Apr 18, 2024 at 05:40:20PM -0400, Josh Marshall wrote:
> >>>>>> Looks like breakpoints aren't working?  https://paste.debian.net/1314501/
> >>>>>>
> >>>>>
> >>>>> This maybe caused by Kernel Address Space Randomization (KASLR), try
> >>>>> disabling it by adding nokaslr option to the boot options.
> >>>
> >>> Thanks,
> >>> Carlos
>
> Thanks,
> Carlos

Re: Feedback on my development setup

[Jonathan Corbet]

Josh Marshall <joshua.r.marshall.1991@gmail.com> writes:

> Hello Carlos,
>
> This is a generational shift.  For my peers, we understand the benefit
> of keeping everything in a thread.  But at some point it becomes so
> verbose and cumbersome as to defeat the purpose.  The size of the text
> I'm working with and the number of text changes it has seen meets that
> level.  And so I've kept it in git and referenced that.

Nonetheless, you are trying to engage with the kernel community, and
will have far better results if you follow that community's norms.
Those include sending patches by email and not top posting.

They also include listening to the advice you are being given.  Like
others, I appreciate your efforts to improve our documentation; it
certainly needs it!  But please think about improving the *existing*
documentation, rather than creating yet another file, disconnected from
the rest.  We already have far too much of that.

Thanks,

jon

Re: Feedback on my development setup

[Carlos Bilbao]

Hello Josh,

On 4/25/24 11:15, Josh Marshall wrote:
> 
> 
> On Thu, Apr 25, 2024, 11:14 AM Jonathan Corbet <corbet@lwn.net
> <mailto:corbet@lwn.net>> wrote:
> 
>     Josh Marshall <joshua.r.marshall.1991@gmail.com
>     <mailto:joshua.r.marshall.1991@gmail.com>> writes:
> 
>     > Hello Carlos,
>     >
>     > This is a generational shift.  For my peers, we understand the benefit
>     > of keeping everything in a thread.  But at some point it becomes so
>     > verbose and cumbersome as to defeat the purpose.  The size of the text
>     > I'm working with and the number of text changes it has seen meets that
>     > level.  And so I've kept it in git and referenced that.
> 
>     Nonetheless, you are trying to engage with the kernel community, and
>     will have far better results if you follow that community's norms.
>     Those include sending patches by email and not top posting.
> 
> 
>     They also include listening to the advice you are being given.  Like
>     others, I appreciate your efforts to improve our documentation; it
>     certainly needs it!  But please think about improving the *existing*
>     documentation, rather than creating yet another file, disconnected from
>     the rest.  We already have far too much of that.
> 
> 
> I cannot abide by this.  Not out of obstinance.  This document is not
> written for a veteran.  It probably isn't even written for anyone on this
> list.  It is meant to be much more approachable than that.  Comparing to
> the closest existing document at
> https://docs.kernel.org/dev-tools/gdb-kernel-debugging.html
> <https://docs.kernel.org/dev-tools/gdb-kernel-debugging.html> , the
> difference in intended audience and skill level is stark.  Let alone being
> able to find that document since it is so buried relative to the intent of
> someone trying to get started.  I have heard several times " you should
> rather improve existing docs" but without really breaking into all the

Jon is explaining how contributing works in the kernel community. I think
you would benefit from reading the documentation on this subject, for
example:

"Unsurprisingly, the kernel development community has evolved a set of
  conventions and procedures which are used in the posting of patches;
  following them will make life much easier for everybody involved"
  - Posting patches, Development Process

or:

"Top-posting is strongly discouraged in Linux kernel development
 discussions. Interleaved (or “inline”) replies make conversations much
 easier to follow." - Submitting Patches

It's simple: You are free to refuse to abide by such basic rules, but you
won't be able to get patches accepted in this community.

With that established, I fail to see the connection between the intended
audience of your document and whether you should make the effort to
integrate it within the existing documentation or not.

> implications that 'just' doesn't help.  Given the back and forth required
> to express the finesse here, I am willing to have a phone or video call to
> get this right.

People on the mailing lists typically prefer to resolve issues through
email.

> 
> 
>     Thanks,
> 
>     jon
> 

Thanks,
Carlos

Re: Feedback on my development setup

[Josh Marshall]

Sorry for the double post to some of you.  Mobile Gmail silently
converted to HTML and caused some problems.  Content is otherwise
identical.

On Thu, Apr 25, 2024 at 11:14 AM Jonathan Corbet <corbet@lwn.net> wrote:
>
> Josh Marshall <joshua.r.marshall.1991@gmail.com> writes:
>
> > Hello Carlos,
> >
> > This is a generational shift.  For my peers, we understand the benefit
> > of keeping everything in a thread.  But at some point it becomes so
> > verbose and cumbersome as to defeat the purpose.  The size of the text
> > I'm working with and the number of text changes it has seen meets that
> > level.  And so I've kept it in git and referenced that.
>
> Nonetheless, you are trying to engage with the kernel community, and
> will have far better results if you follow that community's norms.
> Those include sending patches by email and not top posting.
>
> They also include listening to the advice you are being given.  Like
> others, I appreciate your efforts to improve our documentation; it
> certainly needs it!  But please think about improving the *existing*
> documentation, rather than creating yet another file, disconnected from
> the rest.  We already have far too much of that.
>

I cannot abide by this.  Not out of obstinance.  This document is not
written for a veteran.  It probably isn't even written for anyone on
this list.  It is meant to be much more approachable than that.
Comparing to the closest existing document at
https://docs.kernel.org/dev-tools/gdb-kernel-debugging.html , the
difference in intended audience and skill level is stark.  Let alone
being able to find that document since it is so buried relative to the
intent of someone trying to get started.  I have heard several times "
you should rather improve existing docs" but without really breaking
into all the implications that 'just' doesn't help.  Given the back
and forth required to express the finesse here, I am willing to have a
phone or video call to get this right.

> Thanks,
>
> jon

Re: Feedback on my development setup

[Theodore Ts'o]

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

Re: Feedback on my development setup

[Theodore Ts'o]

On Thu, Apr 25, 2024 at 01:08:36PM -0400, Josh Marshall wrote:
> 
> I cannot abide by this.  Not out of obstinance.  This document is not
> written for a veteran.  It probably isn't even written for anyone on
> this list.  It is meant to be much more approachable than that.
> Comparing to the closest existing document at
> https://docs.kernel.org/dev-tools/gdb-kernel-debugging.html , the
> difference in intended audience and skill level is stark.  Let alone
> being able to find that document since it is so buried relative to the
> intent of someone trying to get started.  I have heard several times "
> you should rather improve existing docs" but without really breaking
> into all the implications that 'just' doesn't help.  Given the back
> and forth required to express the finesse here, I am willing to have a
> phone or video call to get this right.

Just as there are dozens of git tutorials which are floating around
the web which are separate from the official git documentation, if
what you want is to have an unofficial document designed for a
specific audience which is not the "vetran", that's totally fine.

Perhaps you can work with the kernel newbies folks, and look at
joining forces with their documentation, e.g.:

	https://kernelnewbies.org/FirstKernelPatch

The benefit of joining forces with them might be that more people will
see your document.  A random gitlab page is not going to be as
discoverable.

So I think there may be some crosstalk because your goals might not be
what others have been assuming your goals to be.  If you want to have
your own unofficial kernel tutorial, have at it!  You don't need to
get permission from anyone else, and you don't need to engage with the
community on this mailing list or anywhere else.

The flip side is if you want to get input from this community, you may
find that you are more likely to get that help if you are discussing
things on the mailing list, as opposed to expecting us to go find your
gitlab site and participating there.  We can't force you to use
mailing list threads; but at the same time, your expecting to us to
use gitlab might not be very fruitful.

Best regards,

						- Ted