Email or username:

Password:

Forgot your password?
Asahi Linya (朝日りにゃ〜)'s posts Post Back to profile
Top-level
Sobex

@lina @SharpLimefox Is it possible to avoid the subsystem that are a pain in the ass, when writing drivers ?

Or is this more a case of not upstreaming those drivers and upstreaming stuff that goes in Rust friendly subsystem first ?

29 August at 19:55 | Wall-to-wall | Open on social.sciences.re
7 comments
Asahi Linya (朝日りにゃ〜)

@Sobex @SharpLimefox It's possible in some cases, not others. You can't avoid the subsystems "above" you providing your services (DRM for me) and "below" you interacting with other devices, but you can avoid "helper" subsystems and parts of them.

The DRM scheduler is a helper. The other thing I'm going to RiiR is the GPU page table management, which is currently using the IOMMU page table helpers (both because the maintainer stopped replying to my emails... and because since the original submission my needs have diverged enough from the standard code that I think it stopped making sense to reuse it and try to fight to shoehorn those features in).

@Sobex @SharpLimefox It's possible in some cases, not others. You can't avoid the subsystems "above" you providing your services (DRM for me) and "below" you interacting with other devices, but you can avoid "helper" subsystems and parts of them.

The DRM scheduler is a helper. The other thing I'm going to RiiR is the GPU page table management, which is currently using the IOMMU page table helpers (both because the maintainer stopped replying to my emails... and because since the original submission...

29 August at 20:02 | Open on vt.social
Lux under a pile of leaves 🍂🦊🍂

@Sobex @lina IMO regardless of subsystem you'll have to endure the structural issues plaguing RFL, but a subsystem full of people willing and motivated to help should alleviate those significantly

And there's also the problem that if your interest is in a specific area of kernel dev (drm, net, whatever), you've only got so much wiggle room to avoid maintainers unwilling to help more.

Someone i talked about this with mentioned forking as well, but that comes with the human cost of maintaining the upstream source (mainline), people having to decide whether to leave the main project, stay, or invest twice as much energy, and the risk that nobody will really use your fork (Asahi Linux being the huge exception for that point lmao)

@Sobex @lina IMO regardless of subsystem you'll have to endure the structural issues plaguing RFL, but a subsystem full of people willing and motivated to help should alleviate those significantly

And there's also the problem that if your interest is in a specific area of kernel dev (drm, net, whatever), you've only got so much wiggle room to avoid maintainers unwilling to help more.

29 August at 20:05 | Open on eldritch.cafe
Asahi Linya (朝日りにゃ〜)

@SharpLimefox @Sobex Hard forks aren't sustainable. Asahi Linux tracks upstream and with that comes a maintenance cost proportional to how much it diverges. The plan was always to upstream almost everything... the project doesn't have a long term future if we get stuck maintaining large amounts out of tree forever (a few patches is OK and we already have a couple "upstream is never going to take this and that's fine, we can live with that" cases... but it can't grow without bound)

29 August at 20:11 | Open on vt.social
Sobex

@lina @SharpLimefox Urgh, what falls in the upstream won’t take that ever case ?

29 August at 20:14 | Open on social.sciences.re
Asahi Linya (朝日りにゃ〜) replied to Sobex

@Sobex @SharpLimefox TSO support for fast x86 emulation and the M1 cpuidle driver, both are NAKed by all the ARM employees (for politics reasons) and they own the arm64 platform subsystem.

The actual patches are pretty small and not intrusive though so it's not a big maintenance burden.

In theory the cpuidle stuff is supposed to be replaced by some PSCI transport alternative that doesn't exist, but that idea has been floated for years now and not gone anywhere...

29 August at 20:22 | Open on vt.social
Sobex replied to Asahi Linya (朝日りにゃ〜)

@lina @SharpLimefox Hmm, what are the politics reason (rather than undocumented, and not required to make the hardware run) ?

29 August at 20:24 | Open on social.sciences.re
Asahi Linya (朝日りにゃ〜) replied to Sobex

@Sobex @SharpLimefox For TSO they fear "fragmentation" as in developers using TSO to work around arm64 porting issues instead of fixing the code, even though there is no evidence of anyone ever even thinking to do that.

For cpuidle, the maintainers want PSCI (a firmware interface) to be the only cpuidle driver to avoid driver proliferation. Unfortunately the PSCI spec was written with assumptions about the platform that make it impossible to implement on Apple Silicon despite it being a conformant arm64 implementation (they require optional features).

@Sobex @SharpLimefox For TSO they fear "fragmentation" as in developers using TSO to work around arm64 porting issues instead of fixing the code, even though there is no evidence of anyone ever even thinking to do that.

For cpuidle, the maintainers want PSCI (a firmware interface) to be the only cpuidle driver to avoid driver proliferation. Unfortunately the PSCI spec was written with assumptions about the platform that make it impossible to implement on Apple Silicon despite it being a conformant...

29 August at 20:27 | Open on vt.social
Go Up