The fast kernel headers tree [LWN.net]

The fast kernel headers tree

Posted Jan 2, 2022 23:39 UTC (Sun) by Paf (subscriber, #91811) [Link] (35 responses)

John,

I was surprised to see no replies to Inyo’s posting, then checked a few timestamps. Did you really post this five minutes after his message or am I reading something wrong? 😂

Timing

Posted Jan 3, 2022 0:04 UTC (Mon) by corbet (editor, #1) [Link] (1 responses)

It's part of my routine to check in Sunday afternoon/evening (my time) for Linus's -rc posting, and I happened to notice that as well. Had Ingo posted it any other time it would have sat for longer.

Wait a little while, I'm sure you'll see replies ;)

Timing

Posted Jan 3, 2022 3:26 UTC (Mon) by jbailey (guest, #16890) [Link]

Nonono, you're supposed to say something enigmatic, like "I felt a great disturbance in the Force, as if millions of continuous builders suddenly cried out in terror and were suddenly silenced."

The fast kernel headers tree

Posted Jan 3, 2022 1:02 UTC (Mon) by dankamongmen (subscriber, #35141) [Link]

corbet was also explicitly cc'd on the mail

The fast kernel headers tree

Posted Jan 3, 2022 1:18 UTC (Mon) by pebolle (guest, #35204) [Link] (31 responses)

> 😂

One would hope that lwn.net subscribers would not use emojis. Since they actually do we might as well ask Jon to go all out and accept animated GIFs too. Why reject what the rest of the world is using so feverishly?

The fast kernel headers tree

Posted Jan 3, 2022 1:26 UTC (Mon) by banana (guest, #144773) [Link] (11 responses)

What’s wrong with emojis? They work OK on Linux.

The fast kernel headers tree

Posted Jan 3, 2022 1:40 UTC (Mon) by JoeBuck (subscriber, #2330) [Link] (5 responses)

Let's not derail the conversation arguing about emojis.

To get back on topic: is there any performance cost to the uninlining?

The fast kernel headers tree

Posted Jan 3, 2022 8:49 UTC (Mon) by smurf (subscriber, #17840) [Link] (2 responses)

Yes. Your kernel build is now too fast to wait for the coffee machine, so you need another justification to hang out there.

The fast kernel headers tree

Posted Jan 3, 2022 17:12 UTC (Mon) by flussence (guest, #85566) [Link] (1 responses)

Easy: just build the kernel with LTO and you'll have enough time to go get lunch ;-)

The fast kernel headers tree

Posted Jan 4, 2022 21:21 UTC (Tue) by tsoni.lwn (subscriber, #139617) [Link]

fullLTO to be specific. ThinLTO is going to slow it down too but fullLTO makes it very slow.

The fast kernel headers tree

Posted Jan 3, 2022 16:06 UTC (Mon) by Sesse (subscriber, #53779) [Link] (1 responses)

I believe Ingo posted somewhere that he had run performance tests with no ill effects.

In general, people do inline too much. Some things absolutely must be inlined, and many things are just fine without. Even worse, some things are faster locally when inlined, but slow down the rest of the system (due to code bloat).

The fast kernel headers tree

Posted Jan 3, 2022 23:53 UTC (Mon) by atnot (guest, #124910) [Link]

> In general, people do inline too much.

Agreed, especially these days with LTO being very widespread, it turns out that humans are usually significantly worse than compilers at deciding what would benefit from inlining.

The fast kernel headers tree

Posted Jan 9, 2022 11:08 UTC (Sun) by adobriyan (subscriber, #30858) [Link] (4 responses)

Emojis almost universally break the interline spacing, and most of them simply look badly (probably due to lowest bidder effect). Two "sarcasm" emoji posted in the very thread are perfect example the first one with tears of joy is quite nice.

And then there are too many of them so inferring the intended meaning can be quite hard if not harder than inferring the meaning new word in foreign language. They were tolerable when there were like 5-10 of them but hundreds all slightly different in different corners of the Internet.

In some sense emojis return the world 100-150 years ago when most of the humanity wasn't literate so pictures were essential for the illiterate.

Each and every self respecting computer program which can render emoji should offer an option to disable the race to intellectual bottom. I hope Emacs has it. If it doesn't, I hope Gentoo ships "USE=-emoji".

The fast kernel headers tree

Posted Jan 11, 2022 6:24 UTC (Tue) by flussence (guest, #85566) [Link]

> In some sense emojis return the world 100-150 years ago when most of the humanity wasn't literate so pictures were essential for the illiterate.

This is hilariously ironic to put in the middle of an outburst calling for conservatism and "return to tradition".

Change a handful of words around and it could be a stereotypical anti-systemd rant!

The fast kernel headers tree

Posted Jan 11, 2022 8:40 UTC (Tue) by jezuch (subscriber, #52988) [Link] (1 responses)

> emoji (...) the race to intellectual bottom

🤣

I believe future historians will argue that emoji are quite the opposite: they *enrich* the language. You're basically doing the same thing every conservative does when they can't keep up with the world: stop it from having fun and evolving (and call it "devolving").

I haven't read it, but I hear this book is highly recommended on the subject: https://gretchenmcculloch.com/book/

The fast kernel headers tree

Posted Jan 11, 2022 14:43 UTC (Tue) by mrshiny (guest, #4266) [Link]

I was half-way through your comment and thought "Because Internet is appropriate here", then finished reading. I recommend the book! But also, I recommend anyone who dislikes emoji or slang or kids these days to take a look at the state of modern linguistics, where there's a focus on understanding how language changes, and there's really nothing that can, or should, be done about it. As an armchair linguist, I love this! As a grumpy old man, I am grumpy about change!

The fast kernel headers tree

Posted Jan 11, 2022 9:39 UTC (Tue) by zdzichu (subscriber, #17118) [Link]

> Emojis almost universally break the interline spacing, and most of them simply look badly (probably due to lowest bidder effect). Two "sarcasm" emoji posted in the very thread are perfect example the first one with tears of joy is quite nice.

Emojis are just characters. How they are rendered depend on your system. You basically complain about your (or your system vendor's) font choice.

The fast kernel headers tree

Posted Jan 3, 2022 2:27 UTC (Mon) by Paf (subscriber, #91811) [Link]

Kids these days! Terrible!

The fast kernel headers tree

Posted Jan 3, 2022 4:15 UTC (Mon) by felixfix (subscriber, #242) [Link] (16 responses)

Many systems turn text emojis like colon dash close-paren into gifs. Let's find out if that is the case here.

:-)

Emojis began in the text world, probably on typewriters, and I say WE TAKE BACK OUR EMOJIS!!!!

The fast kernel headers tree

Posted Jan 3, 2022 8:21 UTC (Mon) by nilsmeyer (guest, #122604) [Link]

Let's do one better and convert all gifs back to text.

The fast kernel headers tree

Posted Jan 3, 2022 8:31 UTC (Mon) by Karellen (subscriber, #67644) [Link] (14 responses)

"text emojis" - we already have the word "emoticons" which predates "emojis" (in English) by at least 5 years. And they can pry my emoticons off of my cold, dead keyboard!!!! Or something.

The fast kernel headers tree

Posted Jan 3, 2022 17:42 UTC (Mon) by EnigmaticSeraph (subscriber, #50582) [Link] (12 responses)

While I understand the sentiment, Emojis are far better than emoticons. For example, screen readers for the blind cannot interpret emoticons, but Emoji are fine. To be inclusive, we should really move past emoticons.

The fast kernel headers tree

Posted Jan 3, 2022 18:20 UTC (Mon) by Wol (subscriber, #4433) [Link] (9 responses)

Are you *trying* to us exclude dinosaurs!?

I won't say I use emoticons much, but I don't use emojis AT ALL. I neither know, nor care, how to ... :-)

Cheers,
Wol

The fast kernel headers tree

Posted Jan 3, 2022 21:04 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (8 responses)

Wikipedia claims the following:

> Mary Kalantzis and Bill Cope write that the first digital emojis were created by Bruce Parello, a student at the University of Illinois, on PLATO IV, the first e-learning system, in 1972.

It cites a book as well as this open-access PDF: https://www.researchgate.net/publication/351400910_A_Litt...

If that year is correct, then it would predate the introduction of (digital) emoticons in 1982 by a full ten years (although Wikipedia again claims that emoticons have appeared in non-digital text as early as 1648).

However, there are a few caveats here:

1. To the best of my understanding, these emoji did not get incorporated into Unicode and therefore lack historical continuity with modern emoji.
2. The PLATO emoji can't have been very influential, because everybody and their dog incorrectly claims that Shigetaka Kurita created the first emoji in 1999.

The fast kernel headers tree

Posted Jan 4, 2022 1:48 UTC (Tue) by sfeam (subscriber, #2841) [Link] (7 responses)

I'm not sure that implementing a custom character on a PLATO system counts as "creating an emoji" as that would commonly be understood now. PLATO used a vector display; any arbitrary shape could be defined, used, and reused. The same was true for the PDP/PDS-IMLAC terminals of that same era. My first summer job project back in 1971 involved teaching an PDP+IMLAC system to draw logic diagrams, and that started with creating a library of routines to draw individual logic gates (AND NOR XOR ...) essentially as reusable custom characters. Those were 絵文字 (emoji) in the literal sense of being "picture (絵) characters (文字)" but obviously not in the current social media sense of "punctuation marks conveying emotion".

On the other hand, I concede that if Bruce Parello's PLATO emoji were promoted for use by students or instructors as markup annotations for PLATO assignments, they might qualify under the modern sense of emoji as well as under the original technical sense.

The fast kernel headers tree

Posted Jan 4, 2022 22:20 UTC (Tue) by EnigmaticSeraph (subscriber, #50582) [Link] (6 responses)

I just wanted to say that I strongly appreciate the diversity of generations and experiences from LWN. It yields much richer results, solutions, evolutions, etc. Thanks, comrades.

While I'm dropping by, a further argument for emoji is that they express a broad and at times deep sets of readily-understood signifiers independent of language or ultimately medium; yes, the Unicode repertoire remains e.g. Euro & Japanese -centric, but it's getting better.

The fast kernel headers tree

Posted Jan 5, 2022 3:57 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (5 responses)

I would argue that emoji are far less universal than people have claimed. For example:

😂 is in practice almost entirely synonymous with "lol," but its official Unicode name is FACE WITH TEARS OF JOY.
😤 is FACE WITH LOOK OF TRIUMPH but most westerners understand it to mean something like "I'm angry."
💅 is generally understood to express casual insouciance, but it literally depicts a person painting their nails.
💁‍♀️ and to some extent 💁‍♂️ are used to express sarcasm or snark, but they are officially an INFORMATION DESK PERSON (followed by a ZWJ and a gender marker), and some people incorrectly(?) call it the "hair flip emoji." It's not at all obvious to me what these emoji-people are supposed to be doing, but "person tipping hand" seems to be the modern-ish name for them.
👌 as a hand gesture is already quite ambiguous even before you turn it into an emoji. Some cultures think it means "OK," and some think it's vulgar.
There are emoji* for each national flag, but they don't even work on Windows. But they do work on Twitter, and any other platform that does their own custom emoji rendering rather than handing Unicode directly to the browser like a sensible website.

And those are the clean ones. I could go on all day about the dirty ones...

* The flags are not directly mapped in Unicode. Instead, Unicode defines 26 "regional indicator symbols" and you spell out the two-letter ISO code for the country whose flag you want. This is because the Unicode stability policy would be incompatible with adding and removing flags as countries rise and fall. Also, there are a wide variety of political and cultural issues which would make this fraught to do in Unicode (e.g. there is no consensus on whether TW should display the flag of Taiwan - it is a valid ISO 3166-1 code, but ISO also has codes for Puerto Rico, Antarctica, and a variety of other "non-independent" territories, which is the same category they put Taiwan under).

The fast kernel headers tree

Posted Jan 5, 2022 6:47 UTC (Wed) by neilbrown (subscriber, #359) [Link] (2 responses)

This comment confirms something that I'd been suspecting. Emoji often are too small for those of us with imperfect sight.
I can read all your words just fine (with the correct glasses).
I can see the first two emoji look like faces and are different, but I wouldn't trust my guess as to the important difference.

I don't much like emoji, but I can say one thing in their favour: they are still much better than animated emoji.

The fast kernel headers tree

Posted Jan 5, 2022 7:46 UTC (Wed) by sfeam (subscriber, #2841) [Link] (1 responses)

Well, the "characters are too small for these old eyes" problem is not limited to emoji. CJK glyphs with more than about 6 strokes start to become hard to distinguish at font sizes for which the English alphabet is perfectly legible. Of course context and familiarity help a lot, but even so I resort to toggling ever increased font size. And I can only dream wistfully of being able to read much of anything on a phone screen.

The fast kernel headers tree

Posted Jan 5, 2022 9:24 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

To be fair, you can afford to increase the font size for CJK glyphs since they are so dense. A typical Mandarin word is just 1.6 characters long.

And they're also so much easier to type on a phone!

The fast kernel headers tree

Posted Jan 5, 2022 15:26 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

Sure. Words change meaning over time too. Given that there's unlikely to be specific codepoints for what some food emoji[1] "mean" in typical usage, what do you suggest people use instead when they want to talk about…whatever they're talking about. They're going to use the tools available. Language is flexible like that.

- 😂 is "lol", sure. People have tears when laughing. I consider it more like "rofl", but it's in the same vein at least.
- 😤 is ambiguous in that the whisps could be going in (sure, "triumph" could work here though the eyes or eyebrows don't match what I'd expect) or out ("angry, but counting to ten").
- 💅 is depicting one of the things that someone expressing casual insouciance would do instead of fully paying attention to what you're saying or doing. I don't see an issue here; it's actually quite ingenious.
- 💁‍♀️ and 💁‍♂️ are fine for sarcasm (IME, in a "sorry not sorry" kind of way). I don't expect ‽ and ⸮ to be any more useful given the difficulty of finding them on keyboards compared to the emoji. Info desks aren't that common anymore anyways (at least in the US; I don't expect COVID to have made them more popular where they still exist with humans behind the desk instead of touch screen based phone tree-like kiosks), so repurposing existing codepoints is useful.
- 👌 Sure, and 🖕 exists too. What's your point? One can't say that Unicode refuses to make vulgar symbols for any one culture at least (government prudishness and pearl clutching is a different matter).

[1] 🍆 and 🍑

The fast kernel headers tree

Posted Jan 5, 2022 19:15 UTC (Wed) by mbunkus (subscriber, #87248) [Link]

Emojis mirror real life. In real life different people use different gestures to signal the same thought or feeling (e.g. one might fist pump in triumph, someone else might raise their hands Rocky-style, yet another one might stand there in the typical superhero pose). The inverse is also true: the same gesture might mean different things to different people or even the same person (the aforementioned superhero pose might also be taken as an angry parent berating their misbehaving child, depending on the facial expression). And lastly, a lot of gestures or sayings aren't globally used (e.g. "crossing your fingers" in English has an Emoji that doesn't make sense to us Germans who use "Daumen drücken" = squeezing your thumb as the corresponding saying, and there's no Emoji for that, so either we know the English equivalent and use that one ore we're simply out of luck).

As ambiguous real life is, you cannot make they pictograms trying to represent them unambiguous.

Same as any other piece of language, really, 'cause that's all Emojis are, a type of language we can use or not along the other types of language (spoken, written, body language, images, dance…). NONE of that is unambiguous. Of course the Unicode people know that; of course they don't expect Emojis to be universal.

The fast kernel headers tree

Posted Jan 3, 2022 20:50 UTC (Mon) by KJ7RRV (subscriber, #153595) [Link] (1 responses)

How hard would it be to create a font that shows emojis as emoticons? That, combined with existing emoticon-to-emoji converters, should make everyone happy.

The fast kernel headers tree

Posted Jan 3, 2022 20:54 UTC (Mon) by KJ7RRV (subscriber, #153595) [Link]

A browser extension would also work for Web sites (and any chat platforms accessed through a browser, as well as Web mail); that way it would actually be emoticons and not just look like them. An IRC bouncer could do the same for IRC.

The fast kernel headers tree

Posted Jan 4, 2022 3:19 UTC (Tue) by flussence (guest, #85566) [Link]

The "☺" in most DOS codepages predates Unicode by a few decades too...

The fast kernel headers tree

Posted Jan 3, 2022 14:09 UTC (Mon) by atnot (guest, #124910) [Link]

I am pleased to say for the future of the kernel that there are in fact people below the age of 40 using this website

The fast kernel headers tree

Posted Jan 2, 2022 23:48 UTC (Sun) by rgmoore (✭ supporter ✭, #75) [Link] (1 responses)

I guess we know who's going to be the leader in the LWN stats for the next kernel.

The fast kernel headers tree

Posted Jan 3, 2022 2:54 UTC (Mon) by JMB (guest, #74439) [Link]

So fast ... very unlikely ... this is an RFC for a reason - so not for the next kernel ...
The reviewing process will be ... interesting ... ;)

The fast kernel headers tree

Posted Jan 3, 2022 8:22 UTC (Mon) by adamg (guest, #42260) [Link] (10 responses)

>I'm pleased to announce the first public version of my new "Fast Kernel Headers" project that I've been working on since late 2020 (...)

This is mind blowing example of how determined kernel developers are. Imagine spending more than one year developing a feature you are not sure will be even accepted. And that's just a start of journey, merely first RFC, not even pull request. Guys like Ingo, Jason (for wireguard took about 4 years to be merged) and many others.

Hats off!

The fast kernel headers tree

Posted Jan 3, 2022 8:54 UTC (Mon) by zdzichu (subscriber, #17118) [Link] (5 responses)

Think about employer who tolerated working on such feature. Someone had to pay for this year of work :)

The fast kernel headers tree

Posted Jan 3, 2022 9:15 UTC (Mon) by metan (subscriber, #74107) [Link] (3 responses)

Actually this makes a perfect sense from an employers point of view, as long as CI is concerned speeding up the build twice significantly shortens the CI feedback loop. That alone a big win for developers. It also allows you to test twice as much patches or enable more automated testsuites without increasing the hardware lab size and power consumption.

The fast kernel headers tree

Posted Jan 3, 2022 11:34 UTC (Mon) by micka (subscriber, #38720) [Link] (2 responses)

There is probably some gain on test duration but I expect most test suite to run far longer than the kernel build part.

The fast kernel headers tree

Posted Jan 3, 2022 12:17 UTC (Mon) by metan (subscriber, #74107) [Link] (1 responses)

That really depends on the usecase. Some of the CI systems can identify, based on the patch, which parts of kernel were changed and tries to select minimal subset of tests that covers that exact area. Of course this is not bulletproof, but on the other hand it can identify bugs very fast and in that case the kernel build time may be significant part of the CI runtime. This is really about developers getting feedback fast in case that something is not right. Of course you want to run all the tests once this minimal set has passed, which will possibly identify more subtle problems, but that will also take much longer and the results will be produced probably after the developer has already started to work on a different task.

The fast kernel headers tree

Posted Jan 4, 2022 15:56 UTC (Tue) by simlo (guest, #10866) [Link]

In my book that is the job of the build system, not the CI. Due to lack of good build systems implementing reliable incremental builds, a lot of complexity is pushed to the CI system. In my book the CI system shall not perform anything that isn't a simple command which also can be called by an individual developer after closing or updating a git repository.

The fast kernel headers tree

Posted Jan 4, 2022 21:23 UTC (Tue) by tsoni.lwn (subscriber, #139617) [Link]

Believe me there is a huge amount of attention employers gives the build times including the full build and incremental builds.

Wow

Posted Jan 3, 2022 21:48 UTC (Mon) by david.a.wheeler (subscriber, #72896) [Link] (3 responses)

I agree, this is a crazy amount of work. Serious hat tip here.

Wow

Posted Jan 12, 2022 18:52 UTC (Wed) by nix (subscriber, #2304) [Link] (2 responses)

Quite so! Plus, because it speeds up the kernel build so much, those of us who have to adapt out-of-tree patches to it are probably going to do so happily rather than moaning about it like usual.

Wow

Posted Jan 12, 2022 20:08 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

> Quite so! Plus, because it speeds up the kernel build so much, those of us who have to adapt out-of-tree patches to it are probably going to do so happily rather than moaning about it like usual.

Is that going to result in less upstreaming of patches?

Wow

Posted Jan 12, 2022 21:16 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

Or perhaps more because there will be shorter coffee breaks while performing internal CI/QA prior to sending patches upstream and therefore patches can make their way upstream more easily?

What vendor is sitting there, planning on taking their stuff upstream but sees "oh, builds can be faster now" and decide "maybe we don't need to send things upstream"? If anything, I'd see a rush to get patches in first so that they can just be fixed when this lands (though I trust maintainers enough to not let that be an excuse to let crap in).

In any case, how would you suggest this be measured? It's not like the bottleneck is "not enough patches" anyways.

The fast kernel headers tree

Posted Jan 3, 2022 8:24 UTC (Mon) by tdz (subscriber, #58733) [Link] (1 responses)

Fantastic! I can't wait for this to get merged.

The fast kernel headers tree

Posted Jan 3, 2022 8:50 UTC (Mon) by smurf (subscriber, #17840) [Link]

Yes you can. In fact you'll have to, as it's somewhat far from finished.

The fast kernel headers tree

Posted Jan 3, 2022 17:25 UTC (Mon) by jhhaller (guest, #56103) [Link] (1 responses)

That's going to put a substantial drop in performance in my post-retirement plan to modify gcc to use openat for -I directives instead of concatenating each of the -I paths and trying to open the files from root, which cuts out a number of inode lookups and the string concatenation. I doubt it would have improved performance more than a few percent, and now there will be a lot fewer files to open. At least for the kernel, anyway, it could still help other compilations. But, someone may beat me to the change, or perhaps someone has already done it.

The fast kernel headers tree

Posted Jan 9, 2022 10:50 UTC (Sun) by adobriyan (subscriber, #30858) [Link]

It may not be that bad. Given that C compile times are proportional to the total size of files read, you improvements will stand out more percentage wise!

The fast kernel headers tree

Posted Jan 3, 2022 19:28 UTC (Mon) by jezuch (subscriber, #52988) [Link]

As I understand it, this is mostly what maven-enforcer-plugin does in Java land. Good dependency hygiene is important, hard to maintain (especially without any tooling support!) and close to impossible to attain in an older project.

Titanic work!

The fast kernel headers tree

Posted Jan 4, 2022 19:32 UTC (Tue) by marcH (subscriber, #57642) [Link]

If you never got the "upstream first" memo, no chance of missing this one...