Re: [RFC] An idea for general kernel post-processing automation in FreeBSD

From: Alexander Leidinger <Alexander_at_leidinger.net>
Date: Tue, 23 May 2023 06:42:11 UTC
Quoting Hans Petter Selasky <hps@selasky.org> (from Tue, 23 May 2023  
08:00:53 +0200):

> This is not a technical fight, it is a political fight.

I'm watching this from the sideline. I'm looking at this with a  
pragmatic approach: what can *I* gain on my systems from this. I  
consider myself on no particular side in this discussion.

With this point of view I do not think that this is a political fight.

I agree with Hans Petter that qsort is not the best solution for a  
sorting problem. I also understand that a pre-sorted list is better  
than sorting at each boot. I agree with Warner that for this  
particular problem, the complexity of the proposed solution of  
pre-sorting the list looks high compared to the benefit. For my  
_taste_ it crosses the threashold where I would prefer the KISS  
principle.

I would rather prefer a better sorting algorithm in the kernel (which  
looks like something Hans Petter may be interested in too).

I had a look where qsort is used (or rather "mentioned") in freebsd  
(http://fxr.watson.org/fxr/search?string=qsort). Some of those places  
may (I haven't really analysed it, I just glanced at them) be  
performance critical in principle, but maybe the amount of sorting per  
invocation could be small in those places (jail and network related  
use _seems_ to be not critical, not sure about the use in zstd, drm or  
dtrace).

So it may be the case that there is a bigger benefit for a better  
sorting routine in the kernel for run-time use compared to the  
introduction of a build-time sorting solution for a boot-time issue.

Bye,
Alexander.

-- 
http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF