Hi, > -----Original Message----- > From: openwrt-devel [mailto:[email protected]] On > Behalf Of Petr Štetiar > Sent: Montag, 13. Januar 2020 10:24 > To: Paul Spooren <[email protected]>; John Crispin <[email protected]> > Cc: Martin Blumenstingl <[email protected]>; 'OpenWrt > Development List' <[email protected]> > Subject: Re: [OpenWrt-Devel] [RFC] commit message in YAML format for new > devices > > Paul Spooren <[email protected]> [2020-01-12 11:47:29]: > > Hi, > > > Every commit message for newly added devices must contain a number of > > hardware information and steps for an initial installation. > > The hardware information should contain at least the following information, > > maybe more: > > YAML is really PITA, so you don't want to do this in commit description.
There are also cases where we use information about devices which is subject to change, e.g. unsupported features. If we rely on the commit message, those will stick to their original state/values, no matter whether support has been patched in later. I'd much prefer to have a dedicated file, which then could be updated as needed. I never understood why the old discussion on this stopped. ynezz' concept discussed below looks promising to me, I would support this approach if someone actually wanted to make the effort. Best Adrian > > It should be external file YAML file, with defined schema, so you can validate > its correctness. > > See my previous info http://lists.infradead.org/pipermail/openwrt-devel/2019- > May/017082.html > > > If you have a tool to extract such data or ideas on how to create such, > > that'd be great. > > See the kernel tooling link above. > > > As an alternative I could also create a shell script that extracts data on a > > running machine, but that might miss some details. > > Or ideally merge the information from both sources (DTS and runtime). > > John Crispin <[email protected]> [2020-01-13 09:47:54]: > > > I think this will turn into aproblem where functionally sane patches will > > turn into hassle to get merged. we could encourage folks to send the yaml > > file as a companion email I guess. > > If there's good tooling(schema, validation etc.) and documentation around, it > should be as easy as: > > - make device-yaml-prepare IP=10.0.0.1 DTS=target/linux/foo/dts/device.dts > [*] generating device YAML from DTS... > [*] adding runtime details from device at 10.0.0.1 > [*] target/linux/foo/info/device.yaml created > > - $EDITOR target/linux/foo/info/device.yaml > > (add details which can't be gathered during runtime, factory flashing > instructions, UART pinout etc.) > > - make device-yaml-validate target/linux/foo/info/device.yaml > OK! > > - make device-yaml-preview target/linux/foo/info/device.yaml > [*] check http://127.0.0.1:8000 > (or launch browser directly via xdg-open or such) > > We could simply start with opt-in (bonus points if you include such YAML file > along with the support for a new device) and once the dust settles we could > start talking about it as somehow more or less mandatory requirement. > > -- ynezz > > _______________________________________________ > openwrt-devel mailing list > [email protected] > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
openpgp-digital-signature.asc
Description: PGP signature
_______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
