linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Gow <davidgow@google.com>
To: Bagas Sanjaya <bagasdotme@gmail.com>
Cc: "open list:KERNEL SELFTEST FRAMEWORK" 
	<linux-kselftest@vger.kernel.org>,
	KUnit Development <kunit-dev@googlegroups.com>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Brendan Higgins <brendan.higgins@linux.dev>,
	Jonathan Corbet <corbet@lwn.net>,
	Khalid Masum <khalid.masum.92@gmail.com>,
	Sadiya Kazi <sadiyakazi@google.com>
Subject: Re: [PATCH v2] Documentation: kunit: rewrite writing first test instructions
Date: Fri, 30 Sep 2022 18:32:16 +0800	[thread overview]
Message-ID: <CABVgOSko6kgA_T3LNgTPxQZS8Ab8E+XhMcOGHFx76nd2HN_RBg@mail.gmail.com> (raw)
In-Reply-To: <464981b6-d9d7-e656-261f-ef48661deaa2@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4549 bytes --]

On Fri, Sep 30, 2022 at 5:51 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:
>
> On 9/30/22 13:42, David Gow wrote:
> >
> > While I like the idea behind this, the wording probably needs a bit of
> > tweaking. In addition, by describing everything in too much detail, I
> > fear we might just be adding some needless redundancy. My suspicion is
> > that everyone who's going to be writing KUnit tests already knows C
> > (or has access to better learning materials than this), so we're
> > unlikely to need to describe in detail that, e.g., misc_example_add()
> > adds two numbers together when the code is right there,
> >
>
> We should just say "First, write the driver implementation" (without
> describing writing C code in detail), right?
>

Yeah, that should be fine. I'm wavering back and forth on whether we
should call this a driver, given that in a lot of ways it isn't one,
but given it's in drivers/misc, it shouldn't be a problem.

> >>
> >> -.. code-block:: c
> >> +   .. code-block:: c
> >
> > Why are all of these code-block declarations being indented? It
> > doesn't seem to affect the actual documentation build, so I guess it's
> > harmless, but it'd be better not to have it change unnecessarily and
> > clutter up the diff.
> >
>
> The indentation for code-block directive is required, since the preceding
> paragraph is multiline; otherwise there will be Sphinx warnings.
>

I don't see any such warnings on my machine (which claims to have
sphinx-build 4.5.0).

Could you send an example warning, and your sphinx version to me so I
can try to reproduce it.

Regardless, if it's causing warnings, keep these changes. (Though it'd
be nice to include the warnings in the commit message, so it's obvious
that these are being re-aligned for a reason.)

> >>
> >>         int misc_example_add(int left, int right);
> >>
> >> -2. Create a file ``drivers/misc/example.c``, which includes:
> >> +   Then implement the function in ``drivers/misc/example.c``:
> >
> >>
> >> -.. code-block:: c
> >> +   .. code-block:: c
> >
> > Again, code-block indentation?
>
> Yes, for consistency.
>
> >
> >>
> >>         #include <linux/errno.h>
> >>
> >> @@ -152,24 +154,25 @@ In your kernel repository, let's add some code that we can test.
> >>                 return left + right;
> >>         }
> >>
> >> -3. Add the following lines to ``drivers/misc/Kconfig``:
> >> +2. Add Kconfig menu entry for the feature to ``drivers/misc/Kconfig``:
> >
> > This needs rewording to add back an article ("a" or "the"), and we
> > probably want to call this a "Kconfig entry" rather than a "Kconfig
> > menu entry". Maybe "Add a Kconfig entry for the driver..."?
> >
> >>
> >> -.. code-block:: kconfig
> >> +   .. code-block:: kconfig
> >
> > Indentation again?
>
> Yes, see above reply.
>
> >
> >>
> >>         config MISC_EXAMPLE
> >>                 bool "My example"
> >>
> >> -4. Add the following lines to ``drivers/misc/Makefile``:
> >> +3. Add the kbuild goal that will build the feature to
> >> +   ``drivers/misc/Makefile``:
> >
> > Kbuild goal? I've never heard of this being called a Kbuild goal before?
> >
> > How about a "make target"?
> >
>
> At the time of writing this patch, I use terminology in
> Documentation/kbuild/makefiles.rst, which the "make target" is called
> "Kbuild goal".
>
> >>
> >> -.. code-block:: make
> >> +   .. code-block:: make
> >
> > Indentation?
>
> Yes, for consistency with the first code-block directive.
>
> >>
> >> -.. code-block:: c
> >> +   .. code-block:: c
> >
> > Indentation.
> >
>
> See above reply.
>
> >>
> >> -.. code-block:: kconfig
> >> +   .. code-block:: kconfig
> >
> > Indentation?
>
> See above reply.
>
> >>
> >> -.. code-block:: make
> >> +   .. code-block:: make
> >
> > Indentation?
>
> See above reply.
>
> >>
> >> -.. code-block:: none
> >> +   .. code-block:: none
> >
> > Indentation?
> >
>
> See above reply.
>
> >>
> >>         CONFIG_MISC_EXAMPLE=y
> >>         CONFIG_MISC_EXAMPLE_TEST=y
> >>
> >>  5. Run the test:
> >>
> >> -.. code-block:: bash
> >> +   .. code-block:: bash
> >
> > Indentation?
>
> See above reply.
>
> Thanks for reviewing.
>
> --
> An old man doll... just what I always wanted! - Clara
>
> --
> You received this message because you are subscribed to the Google Groups "KUnit Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kunit-dev+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kunit-dev/464981b6-d9d7-e656-261f-ef48661deaa2%40gmail.com.

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4003 bytes --]

  reply	other threads:[~2022-09-30 11:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-29 13:25 [PATCH v2] Documentation: kunit: rewrite writing first test instructions Bagas Sanjaya
2022-09-30  6:42 ` David Gow
2022-09-30  9:51   ` Bagas Sanjaya
2022-09-30 10:32     ` David Gow [this message]
2022-10-01  3:07       ` Bagas Sanjaya
2022-10-01  6:51         ` David Gow
     [not found] ` <CAO2JNKUqkt3p1OcRt9tSa9T=sv8RG+F3LydZfTdVBc0WewhHVg@mail.gmail.com>
2022-10-07  3:03   ` Bagas Sanjaya

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=CABVgOSko6kgA_T3LNgTPxQZS8Ab8E+XhMcOGHFx76nd2HN_RBg@mail.gmail.com \
    --to=davidgow@google.com \
    --cc=bagasdotme@gmail.com \
    --cc=brendan.higgins@linux.dev \
    --cc=corbet@lwn.net \
    --cc=khalid.masum.92@gmail.com \
    --cc=kunit-dev@googlegroups.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=sadiyakazi@google.com \
    /path/to/YOUR_REPLY

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

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).