Re:“Fast Kernel Headers” Tree -v1: Eliminate the Linux Kerne...
by wott on Monday January 03, 2022 @02:09AM
(#29778174)
> As someone who had to go rattling over the USB gadget subsystem, I can tell you that running "grep" with "find" was the standard way to find some data structure buried in a file included 8 layers deep.
It has always amazed me how finding something which originally seemed a trivial little thing, usually meant going through a chain of #defines and typedefs across many header files. It's the same with GLibc, by the way. It' a bit like when you hike to a summit by following a crest path: you always think the next hump in sight is the right one, your destination, the promise land; and when you reach it, dammit, it wasn't, your goal is actually the next one. Or perhaps the next after the next. Or...
Re:“Fast Kernel Headers” Tree -v1: Eliminate the Linux Kerne...
by cassepipe on Monday January 03, 2022 @11:18AM
(#29782309)
Yes, actually when I came to C and asked on stackexchange/unix&linux how I could search which libc header I had to include in order to use a defined macro or find type declaration,without a web search, my question was shot down in the hour and I was recommended to either make a web search or grep and good luck.
This how desperate we are : We can't handle newbies putting that truth in front of us.
Re:“Fast Kernel Headers” Tree -v1: Eliminate the Linux Kerne...
by yjftsjthsd-h on Sunday January 02, 2022 @09:30PM
(#29776656)
> As someone who had to go rattling over the USB gadget subsystem, I can tell you that running "grep" with "find" was the standard way to find some data structure buried in a file included 8 layers deep.
As someone who tried poking around: Oh good; I assumed I was just missing something. Alternatively, oh no; I had assumed I was missing something and there was a more elegant tool out there.
Re:“Fast Kernel Headers” Tree -v1: Eliminate the Linux Kerne...
by alexforencich on Monday January 03, 2022 @03:26AM
(#29778550)
https://elixir.bootlin.com/linux/latest/source can be far more helpful than grep for this sort of thing
In Ingo's post, he points out that the main speedup is coming from the fact that the expansion after the C preprocessor step is a LOT smaller.
That's a lot of decoupling. As someone who had to go rattling over the USB gadget subsystem, I can tell you that running "grep" with "find" was the standard way to find some data structure buried in a file included 8 layers deep. Having those data structures in files actually mentioned by the file you're working on would be a huge cognitive load improvement as well as make tool assistance much more plausible.
Even if this particular patch doesn't land, it lights the path. What types of changes need to be made are now clear. How many changes are required before you see the improvement is now clear. With those, the changes required can be driven down into the maintainers and rolled out incrementally, if desired.