Re: [OE-core] [PATCH] udev-extraconf: fix ifupdown for non hotplug devices

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Wed, 2025-04-09 at 12:40 +0200, Jeroen Hofstee wrote:
> Hello Richard,
> 
> On 4/9/25 11:27, Richard Purdie via lists.openembedded.org wrote:
> > > > We've purposefully kept the code called from udev and in our
> > > > initscripts relatively minimal/simple as the overhead of executing
> > > > multiple programs does build up over time. Taking the above, we have
> > > > loops, then pipelines, each of which runs more commands. Each command
> > > > has a fork/exec overhead.
> > > > 
> > > > Is there some way we can simplify this rather than all the shell
> > > > pipelines and loops?
> > > The simplest solution is to patch busybox to respect  --allow=hotplug I guess.
> > Yes, I as wondering about that. I see patches from a long time ago but
> > I guess they were never merged. It probably is easier for busybox to
> > handle this rather than shell code but I don't know what chance they'd
> > have of being merged upstream.
> > 
> > I would probably perfer to fix busybox to support this but I don't know
> > how well that is going to work out...
> 
> Unless they changed their mind, upstream busybox won't accept it, so it
> has to be a patch in OE. But feel free to try to upstream it.

It would be worth a try at least asking as that was a long time ago and
we do have a specific need here which doesn't involve feature creep (as
far as I know).

> 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.

Right, I don't doubt the issue and agree we should fix it, it is just a
question of how.

> The sed stuff isn't that complicated, is it?

It is about the principle and precedent. If I take this, it becomes so
much harder to me to argue against the next similar change and hard to
keep things simple overall. I'm therefore really torn.

I'm spelling things out to see if anyone else has opinions too. Mike's
alternative way of handling things is potentially interesting but I
worry that may also be "against spec".

Cheers,

Richard