Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Initial M1 support merged into Linux SoC tree

git.kernel.org

Post reply on HN
Print view View original

301–310 of 337 posts

Re: Initial M1 support merged into Linux SoC tree

#301

Post by DCKing »

ylyn wrote: post #111
RantyDave wrote: post #96

Earlier quoted context omitted.

There's a certain Zen to using Apple interfaces (IMHO): You have to relax and just accept that this is how it is, and it's best to get used to it. I fully understand if you find this to be not really good enough, but this is the only way to make them work for you.

Ah yes, but if you suggest that someone do this when using Linux, you get shit on.

Gnome is still by some distance the most popular user interface on Linux, and is also very strongly opinionated and appears to lack customization options [1]. The project's "our way or the highway" approach is frequently vocally criticized and compared to Apple's approach, but as a whole seems to be appreciated well enough. I wouldn't say the Linux community as a whole are assholes about this.

The fact that many online Linux users take offense to lack of customization is not really something to worry about in my opinion. I used to customize Linux installs endlessly, but only truly found zen when I stopped worrying committed to stick to Fedora's default install.

[1]: Besides the point but Gnome is arguably far and away the most customizable desktop shell on Linux, as its extension "mechanism" consists of literally overwriting the JS code that powers its shell interface. For better and worse.

Re: Initial M1 support merged into Linux SoC tree

#302

Post by tyingq »

comex wrote: post #300
tyingq wrote: post #243

Earlier quoted context omitted.

>lack of __threadlocal support in M1 An informative post about this from the Zig folks: http://www.jakubkonka.com/2021/01/21/llvm-tls-apple-silicon....

That's not a lack of support, it's just LLD, the LLVM linker, being broken. I hear LLD for Mach-O is being worked on again, after a long period of stagnation where it was sort of but not fully working. But the default linker on Apple platforms is still ld64.

I'd give them a little more grace. It sounds like the M1 requires a different approach than other ARMV7 cpus, and that fact wasn't documented.

Mimalloc had to trudge through the same thing: https://github.com/microsoft/mimalloc/issues/343

Re: Initial M1 support merged into Linux SoC tree

#303

Post by comex »

tyingq wrote: post #302
comex wrote: post #300

Earlier quoted context omitted.

That's not a lack of support, it's just LLD, the LLVM linker, being broken. I hear LLD for Mach-O is being worked on again, after a long period of stagnation where it was sort of but not fully working. But the default linker on Apple platforms is still ld64.

I'd give them a little more grace. It sounds like the M1 requires a different approach than other ARMV7 cpus, and that fact wasn't documented. Mimalloc had to trudge through the same thing: https://github.com/microsoft/mimalloc/issues/343

Well, in theory, Zig doesn't need to care about the specific approach. In the LLVM IR that Zig produces, thread-local variables are still handled as an abstract "thread_local" flag on global variables. The platform-specific parts are handled by a combination of the IR-to-native-object-file translation done by LLVM, and the linking step. If both of those worked correctly, thread locals would "just work" on M1. The problem is that (a) Zig uses LLD for linking and (b) LLD is buggy.

I'm not surprised that Zig is using LLD. Zig wants to be fully self-contained, able to cross-compile for any supported platform without requiring the user to install a toolchain for that platform. And they already use LLVM for code generation, so LLD for linking is the natural choice.

It's a beautiful vision - really. Toolchain installation sucks. And the stuff they're doing with processing and bundling OS C headers [1] is quite innovative. It's just that using LLVM for everything is not a reality for Apple platforms yet. Hopefully it will be soon, once Apple whips LLD into shape.

Edit: mimalloc is different; it reimplements thread-local storage by hand, using `asm` statements, rather than using native `thread_local` variables, presumably because the latter can be slow.

[1] https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...

Re: Initial M1 support merged into Linux SoC tree

#304

Post by heavyset_go »

redm wrote: post #211

After reading articles last year on Linus insinuating it would be "unlikely" that Linux would appear on the M1 [1] [2], I drank the cool-aid and took that at face value. I guess I should have known better, just like nature, open source "finds a way". [1] https://www.realworldtech.com/forum/?threadid=196533&curpost... [2] https://news.ycombinator.com/item?id=25216680 etc..

There are dozens of ARM SoCs that have support merged into the kernel, but that does not mean that a barebones kernel will run well or with full hardware support, or that you can just boot a generic ARM ISO, either.

There's mainline support for ODROID boards, for example, but you're still dependent on the manufacturer for making sure new kernels actually work with the hardware and for new images. Once that manufacturer stops maintaining the kernel and images for their old hardware, either the community has to step up or you'll be running an increasingly out of date kernel and distro until you buy new hardware.

Re: Initial M1 support merged into Linux SoC tree

#305

Post by fcantournet »

dhekir wrote: post #35
strange_things wrote: post #20

This is very anecdotal but every single laptop I have bought in the last 10 years (4) worked perfectly out-of-the box with either Linux Mint or Ubuntu (which are the same on the inside). I only vaguely remember once I had to change some conf file for my trackpad to work after a dist update but that was it. Not sure why everyone in this thread is so hesitant about Linux on a laptop? It literally just works (tm) for me…

Every single laptop my company bought me in the last 10 years (3+) had kernel/driver issues, especially with Ubuntu, since the kernel version was usually lower than that from other distros, like Fedora. This includes mostly graphics driver issues (either simply Nvidia, or hybrids, or some exotic protocols such as DisplayLink), but also touchpad, power/suspend issues (e.g. wake-up failure), lack of fingerprint or smar…

Pro tip: Canonical provides recent kernels for all LTS releases. it's a meta package with rolling updates. 1 apt command and you're set. Full support.

On ubuntu 18.04 or before you could/should do this : sudo apt-get install --install-recommends linux-generic-hwe-18.04 xserver-xorg-hwe-18.04

Starting with 20.04 it's by default so you don't even need it IIRC.

Re: Initial M1 support merged into Linux SoC tree

#306

Post by shawnz »

comex wrote: post #303
tyingq wrote: post #302

Earlier quoted context omitted.

I'd give them a little more grace. It sounds like the M1 requires a different approach than other ARMV7 cpus, and that fact wasn't documented. Mimalloc had to trudge through the same thing: https://github.com/microsoft/mimalloc/issues/343

Well, in theory , Zig doesn't need to care about the specific approach. In the LLVM IR that Zig produces, thread-local variables are still handled as an abstract "thread_local" flag on global variables. The platform-specific parts are handled by a combination of the IR-to-native-object-file translation done by LLVM, and the linking step. If both of those worked correctly, thread locals would "just work" on M1. The pr…

I think the parent poster is saying that LLD needs to take a different approach, not Zig. But it wasn't previously known what approach that would need to be, since M1 does it differently than other ARM CPUs. Therefore there's no expectation that LLD could have gotten it right.

Re: Initial M1 support merged into Linux SoC tree

#307

Post by ndesaulniers »

comex wrote: post #303
tyingq wrote: post #302

Earlier quoted context omitted.

I'd give them a little more grace. It sounds like the M1 requires a different approach than other ARMV7 cpus, and that fact wasn't documented. Mimalloc had to trudge through the same thing: https://github.com/microsoft/mimalloc/issues/343

Well, in theory , Zig doesn't need to care about the specific approach. In the LLVM IR that Zig produces, thread-local variables are still handled as an abstract "thread_local" flag on global variables. The platform-specific parts are handled by a combination of the IR-to-native-object-file translation done by LLVM, and the linking step. If both of those worked correctly, thread locals would "just work" on M1. The pr…

> LLD is buggy.

While certainly not bug free, you may be overstating things.

> once Apple whips LLD into shape

Pretty sure it's engineers at Facebook contributing mach-o fixes to LLD, not Apple. Apple is happy with their linker ld64.

Re: Initial M1 support merged into Linux SoC tree

#308

Post by refulgentis »

shawnz wrote: post #306
comex wrote: post #303

Earlier quoted context omitted.

Well, in theory , Zig doesn't need to care about the specific approach. In the LLVM IR that Zig produces, thread-local variables are still handled as an abstract "thread_local" flag on global variables. The platform-specific parts are handled by a combination of the IR-to-native-object-file translation done by LLVM, and the linking step. If both of those worked correctly, thread locals would "just work" on M1. The pr…

I think the parent poster is saying that LLD needs to take a different approach, not Zig. But it wasn't previously known what approach that would need to be, since M1 does it differently than other ARM CPUs. Therefore there's no expectation that LLD could have gotten it right.

LLVM/Clang were essentially born and stewarded by Apple, it's somewhat odd, to say the least, that they didn't patch LLD on day 1 with the Xcode release that supports M1.

Re: Initial M1 support merged into Linux SoC tree

#309

Post by ndesaulniers »

marcan_42 wrote: post #117

Hi HN! I wrote an article about this initial support series and what it took to make things work properly on this machine: https://asahilinux.org/2021/03/progress-report-january-febru... It still applies to what got merged; the past month was spent on clean-ups, fixes, and review feedback, but there are no major changes to the approach. This initial merge was quite complex as it has to touch a number of subsystems an…

Thank you so much for the work put in to documentation; written in kernel or blogged, and streamed. I've watched hours of your streams. I've been working on a bootloader and porting Linux to the Nintendo 3DS; I don't really know what I'm doing, but your streams clarified many questions I had about porting Linux to a new device.

Re: Initial M1 support merged into Linux SoC tree

#310

Post by ndesaulniers »

Ericson2314 wrote: post #265

It would be wonderful if someday some Pine64 device can take advantage of some of the stuff here. They will never get Apple chips of course, but some of general purpose cleanups I mean. (Thinking back to the stuff in https://asahilinux.org/2021/03/progress-report-january-febru... )

Probably irrelevant, since the kernel already has support for aarch64 for a long time already, and Apple is unlikely to license or sell their SoC to other OEMs.
Post reply on HN