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

Quoting Hans Petter Selasky <[email protected]> (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 [email protected]: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    [email protected]  : PGP 0x8F31830F9F2772BF

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmRsYEMACgkQEg2wmwP4
2IanEg//VQSO1ybebnb1qLoMHdE/V3qfRJ2MN0CZiW+BqHBzOuz9qE+S+tOuzcVB
q6HDWFCGe5O+HszuwfHJqcYoPxScPy+zNmsmY32Qx7ueTUQfTj0GgL7AiYOetHZa
wPMSboHg3bNAM9WivD6Gmzm4bgCUXPHGbw1S0dqDgXsG9wbraG8wvv6+LIe9TYDs
WH42DN4Ap9FhjLJjYSsx6TVKz5PNtavRGw2kOt6tybywtdxA+HqS+br2uhXLsdEQ
O6w00BdyvBhB1/lhQ2W5C9XoDcxoY/9wWeJDR4ZtK615eoR3BbTOV1nLWYnwp4Qy
4qikmnTP8rAQul5dSQUHZUDaEGnMCasv8y8MTzp6pIHBSS0IKVESsKowcdyyH+Wb
8evOAinQpr3ZG6GpP72GeFIjLBgX12riCCBW/pRf2UGEGh6tTUThsJnWUBVk8rnb
BcDAIPJhuk5WUsmPF7ZYVBBBOZerhVhlIYy17TWCD5gDY92S0L4GDwsINbgmcD4X
R5b1Inzltvhc+I17fIJrwc6ii5fwZ9a7IuzPRYY71RjAzuxYtiiASJebnWAAGhpW
lVoe/QK0fEMDvyUFHsysVYeJxaTYfD9krEG5eIJ1VpRatMPcmLXm/ByfX7Esk0vx
Gd4o/TnlzczcD7M5w7d1RtHebsP8UesHn1M7QkOuaxNskSiD3UA=
=ciDa
-----END PGP SIGNATURE-----