On Mon, 22 Mar 2021 09:53:36 +0100 Andrew Jones <drjones@xxxxxxxxxx> wrote: > On Thu, Mar 18, 2021 at 06:07:23PM +0000, Nikos Nikoleris wrote: > > This set of patches fixes the way we parse the stdout-path > > property in the DT. The stdout-path property is used to set up > > the console. Prior to this, the code ignored the fact that > > stdout-path is made of the path to the uart node as well as > > parameters. As a result, it would fail to find the relevant DT > > node. In addition to minor fixes in the device tree code, this > > series pulls a new version of libfdt from upstream. > > > > v1: https://lore.kernel.org/kvm/20210316152405.50363-1-nikos.nikoleris@xxxxxxx/ > > > > Changes in v2: > > - Added strtoul and minor fix in strrchr > > - Fixes in libfdt_clean > > - Minor fix in lib/libfdt/README > > > > Thanks, > > > > Nikos > > > > Applied to arm/queue So I understand that this is a bit late now, but is this really the way forward: to just implement libc functions as we go, from scratch, and merge them without any real testing? I understand that hacking up strchr() is fun, but when it comes to those string parsing functions, it gets a bit hairy, and I feel like we are dismissing decades of experience here by implementing stuff from scratch. At the very least we should run some unit tests (!) on newly introduced C library functions? Or probably the better alternative: we pick some existing C library, and start to borrow implementations from there? Is klibc[1] a good choice, maybe? Cheers, Andre [1] https://git.kernel.org/pub/scm/libs/klibc/klibc.git/ > > https://gitlab.com/rhdrjones/kvm-unit-tests/-/commits/arm/queue > > Thanks, > drew >
