From: "Nícolas F. R. A. Prado" <nfraprado@collabora.com>
To: "Bird, Tim" <Tim.Bird@sony.com>
Cc: Christopher Obbard <chris.obbard@collabora.com>,
Shuah Khan <shuah@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Saravana Kannan <saravanak@google.com>,
Rob Herring <robh+dt@kernel.org>,
"kernelci@lists.linux.dev" <kernelci@lists.linux.dev>,
David Gow <davidgow@google.com>,
Guenter Roeck <groeck@chromium.org>,
"linux-kselftest@vger.kernel.org"
<linux-kselftest@vger.kernel.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"kernel@collabora.com" <kernel@collabora.com>,
Dan Carpenter <dan.carpenter@linaro.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Doug Anderson <dianders@chromium.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH v2 2/2] kselftest: devices: Add sample board file for google,spherion
Date: Tue, 28 Nov 2023 16:05:33 -0500 [thread overview]
Message-ID: <ca434109-7f98-42a3-98b1-eb39480d707d@notapiano> (raw)
In-Reply-To: <BN8PR13MB2738FFDE8693A90B781CCADDFDBCA@BN8PR13MB2738.namprd13.prod.outlook.com>
On Tue, Nov 28, 2023 at 06:33:52PM +0000, Bird, Tim wrote:
>
>
> > -----Original Message-----
> > From: Christopher Obbard <chris.obbard@collabora.com>
> > Hi Nícolas,
> >
> > On Mon, 2023-11-27 at 18:34 -0500, Nícolas F. R. A. Prado wrote:
> > > Add a sample board file describing the file's format and with the list
> > > of devices expected to be probed on the google,spherion machine as an
> > > example.
> >
> > Did you consider using some machine-readable & extensible format like yaml?
> > Surely we don't need to invent yet-another file-format? :-)
For this RFC my focus was to gather feedback on even more basic aspects of the
test, mainly:
- Is using a device's match properties (the ones that constitute modalias) a
good way to encode a device in a stable way or can we do better? (See cover
letter for comparison to HW topology approach)
So I just went for the simplest format I could think of. Moving forward, I agree
YAML might be a better fit and I can try it out for the next version.
>
> I went back to examine the test more closely. These board files are loaded via
> the shell's 'source' command.
>
> If I'm reading the test correctly, the format is machine-readable and extensible, since
> it's a fragment of a shell script. The 'usb' and 'pci' first entries on the lines are
> actually function calls, and the other items in a test line are arguments.
>
> So, as an RFC - how about calling the board files: "<compatible-string>.sh" to make this
> clear, and maybe adding a comment at the top about the nature of the file?
>
> There's probably a use case for reading this file not in this original shell script context,
> so I think Christopher's point about a machine-readable AND easily human-readable
> format is valid. Personally, I find this format not too bad to read (but then I'm a
> shell junky.)
That's right, the board files are shell scripts that are sourced. I went this
route for simplicity rather than necessity. In fact, I'd prefer to have the
board files be dumb files with just the data necessary to describe the devices
on the platform moving forward. For this purpose I'll try using YAML for the
next version and seeing how it goes.
>
> I believe, Nicolas, that you were already planning on putting some comments in the
> file to describe the line format (function arguments?), based on feedback from Greg KH.
> IMHO, knowing that the format allows comments is useful, so adding a sample
> comment would be welcome.
Well, the text added at the top of this file describing the format of each line
was already done in response to Greg's comment. Although I didn't mention
anything about comments indeed, I'll make sure to document that for next
version (even if it is in YAML it doesn't hurt to have comments as part of the
example).
Also, I've noticed that my patches show "(no changes since v1)". Please
disregard these. There have clearly been changes since v1 (the whole approach is
different), which I've documented on the cover letter, but those trailers were
added by mistake when generating the patches.
Thanks,
Nícolas
prev parent reply other threads:[~2023-11-28 21:05 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-27 23:34 [RFC PATCH v2 0/2] Add test to verify probe of devices from discoverable busses Nícolas F. R. A. Prado
2023-11-27 23:34 ` [RFC PATCH v2 1/2] kselftest: " Nícolas F. R. A. Prado
2023-11-27 23:34 ` [RFC PATCH v2 2/2] kselftest: devices: Add sample board file for google,spherion Nícolas F. R. A. Prado
2023-11-28 0:10 ` Bird, Tim
2023-11-28 14:10 ` Mark Brown
2023-11-28 14:43 ` Nícolas F. R. A. Prado
2023-11-28 17:54 ` Bird, Tim
2023-11-28 19:52 ` Nícolas F. R. A. Prado
2023-11-28 17:59 ` Christopher Obbard
2023-11-28 18:33 ` Bird, Tim
2023-11-28 21:05 ` Nícolas F. R. A. Prado [this message]
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=ca434109-7f98-42a3-98b1-eb39480d707d@notapiano \
--to=nfraprado@collabora.com \
--cc=Tim.Bird@sony.com \
--cc=bhelgaas@google.com \
--cc=chris.obbard@collabora.com \
--cc=dan.carpenter@linaro.org \
--cc=davidgow@google.com \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=gregkh@linuxfoundation.org \
--cc=groeck@chromium.org \
--cc=kernel@collabora.com \
--cc=kernelci@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=saravanak@google.com \
--cc=shuah@kernel.org \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).