Re: Feedback on my development setup

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

[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