From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3B5C7C3601E for ; Thu, 10 Apr 2025 18:33:05 +0000 (UTC) Received: from outbound3.mail.transip.nl (outbound3.mail.transip.nl [136.144.136.12]) by mx.groups.io with SMTP id smtpd.web10.5790.1744309982227470044 for ; Thu, 10 Apr 2025 11:33:03 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="dkim: body hash did not verify" header.i=@myspectrum.nl header.s=transip-a header.b=hYRzHWFA; spf=pass (domain: myspectrum.nl, ip: 136.144.136.12, mailfrom: oe@myspectrum.nl) Received: from submission10.mail.transip.nl (unknown [10.103.8.161]) by outbound3.mail.transip.nl (Postfix) with ESMTP id 4ZYT2g5fq8zbB7t; Thu, 10 Apr 2025 20:32:59 +0200 (CEST) Received: from yellow.myspectrum.nl (unknown [IPv6:2a01:7c8:bb0c:45:5054:ff:fe01:854]) by submission10.mail.transip.nl (Postfix) with ESMTPSA id 4ZYT2f5RGQz2nC0cg; Thu, 10 Apr 2025 20:32:58 +0200 (CEST) Received: from [192.168.178.63] (84-27-20-154.cable.dynamic.v4.ziggo.nl [84.27.20.154]) (Authenticated sender: oe@myspectrum.nl) by yellow.myspectrum.nl (Postfix) with ESMTPSA id 9E72120077; Thu, 10 Apr 2025 18:32:56 +0000 (UTC) Authentication-Results: yellow.myspectrum.nl; auth=pass smtp.auth=oe@myspectrum.nl smtp.mailfrom=oe@myspectrum.nl Content-Type: multipart/alternative; boundary="------------bmjVUfPu1ypMq2kSeAQwikil" Message-ID: <8eee9b46-7e9a-4c1d-8daa-4e58a135d9eb@myspectrum.nl> Date: Thu, 10 Apr 2025 20:32:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [OE-core] [PATCH] udev-extraconf: fix ifupdown for non hotplug devices To: yoann.congal@smile.fr, alex.kanavin@gmail.com Cc: richard.purdie@linuxfoundation.org, Jeroen Hofstee , openembedded-core@lists.openembedded.org, Jeroen Hofstee References: <20250407174904.1191173-1-jeroen@myspectrum.nl> <687a5c15fb54930b999cf16a59baaff8f9897a94.camel@linuxfoundation.org> <7eb23b12-1fd1-48a5-83cd-eab2edb8777b@myspectrum.nl> Content-Language: en-US From: Jeroen Hofstee In-Reply-To: X-Scanned-By: ClueGetter at submission10.mail.transip.nl DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=transip-a; d=myspectrum.nl; t=1744309978; h=from:subject:to:cc: references:in-reply-to:date:mime-version:content-type; bh=sJbCf9sNUDku2kJBelyMAwVmOIuEfgpFNg9t2aM535A=; b=hYRzHWFAiL9HESTPTMFR5Vavsc67u8XL8zeTc4PXjzB5gh5/2d6k0kJ4XsUOJivy2I2aPl 4Q97EeFuCVkfFuHEFl/9Jbj9XaMn80GArSDtMWHJLpNPRdBP8WekPAUXsIy4bEE4Wb5lVl Jo0rVCeVc2vV/lwqiXhpKnp92gz9Yrw5ua2h0Voe9cMSODHPozIqBJQ9069Im/pKLNz65S LWBrADNFQOe6eCErIewRTM/s2mjjsuK2K37bWxCXDRkZiU7da/azJnKoqUloZ7Uim/5Hsv 0D/GoDAd5ilWLEI1c9wBu63P/Urg8My8YDMecwqOthlqCEJdIJnsr7hhLZ4kQw== X-Report-Abuse-To: abuse@transip.nl List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Thu, 10 Apr 2025 18:33:05 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/214690 This is a multi-part message in MIME format. --------------bmjVUfPu1ypMq2kSeAQwikil Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello Alex and Yoann, On 4/10/25 14:17, Yoann Congal via lists.openembedded.org wrote: > Le=C2=A0jeu. 10 avr. 2025 =C3=A0=C2=A012:14, Alexander Kanavin via=20 > lists.openembedded.org =20 > a =C3=A9crit=C2=A0: > > On Wed, 9 Apr 2025 at 12:40, Jeroen Hofstee via > lists.openembedded.org > wrote: > > For completeness, this is not some theoretical issue, always > calling if up > > directly after a network device is discovered does cause issues > and is > > against spec as well. > > > > The sed stuff isn't that complicated, is it? > > I beg to differ. The code is basically unreadable (unless you want = to > write an elaborate comment with example input->output transformatio= ns > for every single line it), and that in itself is reason not to take > it. Any software solution must not only solve the problem, it must > also be written such that other humans can understand and change it= . > > I think I'd prefer a patch to busybox; even if upstream rejects or > ignores it, we still have something that is easier to take care of. > > > FWIW, I agree with Alexander here. > A patch (even a local one) will be easier to maintain in the long run. > Cool, let me know when these patches have landed. Regards, Jeroen --------------bmjVUfPu1ypMq2kSeAQwikil Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello Alex and Yoann,

On 4/10/25 14:17, Yoann Congal via lists.openembedded.org wrote:
Le=C2=A0jeu. 10 avr. 2025 =C3=A0=C2=A012:14, Alexander Kanavin via lists.openembedded.org <alex.kanavin=3Dgm= ail.com@lists.openembedded.org> a =C3=A9crit=C2=A0:
On Wed, 9 Apr 2025 at 12:40, Jeroen Hofstee via lists.openembedd= ed.org
<oe=3Dmyspectrum.nl@lists.openemb= edded.org> wrote:
> For completeness, this is not some theoretical issue, always calling if up
> directly after a network device is discovered does cause issues and is
> against spec as well.
>
> The sed stuff isn't that complicated, is it?

I beg to differ. The code is basically unreadable (unless you want to
write an elaborate comment with example input->output transformations
for every single line it), and that in itself is reason not to take
it. Any software solution must not only solve the problem, it must
also be written such that other humans can understand and change it.

I think I'd prefer a patch to busybox; even if upstream rejects or
ignores it, we still have something that is easier to take care of.

FWIW, I agree with Alexander here.
A patch (even a local one) will be easier to maintain in the long run.
=C2=A0

Cool, let me know when these patches have landed.

Regards,
Jeroen
--------------bmjVUfPu1ypMq2kSeAQwikil--