Open-Source DRM Driver Sent Out For The "Good Old" Atari ST/TT/Falcon Systems

[TemplarGR]

The fact that this code has been written and sent for upstreaming NOW is proof enough people care.

We're not talking about some abandoned code for a platform nobody cares about.

No it is proof some people are delusional and waste resources because of their own pet projects. The possibility that this is going to be maintained long term is zero. Also, just because someone is willing to write and maintain code, doesn't mean there is a reason to include it into the official kernel. There is discernment, not everything gets in. How about Con Kolivas patches for example? He did write them, he did maintain them for years, did they include them? No. People had to add the patches themselves.

[TemplarGR]

Somehow people still don't understand that linux isn't *only* for mainstream hardware. If there is someone willing to support and maintain it, it gets in. There is only one mainline kernel for *everyone,* after all. If people want to run linux on emulated atari systems, let them. It has absolutely no effect on your rando x86 box.

Somehow people still don't understand that linux isn't supposed to support niche and decades old hardware in modern releases. This hardware isn't just "not popular", it is VANISHED, that is, does not exist, does not function for most people who might find it in old storehouses cause it malfunctioned, cannot find it in stores... Even the guy who wrote the driver, wrote it for an emulator for fsck sake, he didn't have the real thing!

There is no reason to inflate upstream kernel with useless code no one needs. No one is going to rush to buy ancient hopefully still functioning hardware on ebay, now that the modern kernel might have driver support. If anyone wants to run it on an emulator, he can just run a modified kernel version on his own, there is no reason to add BLOAT in the kernel in 2023 for ancient 90s hardware.

[timofonic]

Somehow people still don't understand that linux isn't supposed to support niche and decades old hardware in modern releases. This hardware isn't just "not popular", it is VANISHED, that is, does not exist, does not function for most people who might find it in old storehouses cause it malfunctioned, cannot find it in stores... Even the guy who wrote the driver, wrote it for an emulator for fsck sake, he didn't have the real thing!

There is no reason to inflate upstream kernel with useless code no one needs. No one is going to rush to buy ancient hopefully still functioning hardware on ebay, now that the modern kernel might have driver support. If anyone wants to run it on an emulator, he can just run a modified kernel version on his own, there is no reason to add BLOAT in the kernel in 2023 for ancient 90s hardware.

Hey, you and other....

Are you the owner of Linux? Are you an expert of Linux reasoning to exist? Who are you to have that decision making superiority?

I don't give a crap about this, but I consider Linux isn't supposed at something but it's a project with nearly infinite possibilities.

Are you an expert in Linux philosophy?

Seriusly, even trolls in Phoronix are deveicing.

[ayumu]

I really wonder how useful this is. About 2 years ago I took an Amiga with a Cyberstorm Mk3 68060 @66MHz, built a basic Linux 5.19 and busybox using a musl/m68k enhanced OpenADK. Booted this from a Fastlane Z3 to get about 9 MiB/s (and no, the Cyberstorms Wide-Fast-SCSI aka Ultra-SCSI - max 40 MiB/s - is not supported by Linux) and it took at least 2 minutes to get the login/prompt. Also tried that with a Blizzard 1230 with SCSI2 and 256MiB Fast-RAM, here it took ages, at least 6 minutes. It is just not usable. And no, even with a CT-60 at 133MHz this will be absolutely painful.

Netbsd boots faster than that, on my 68030@50. Maybe consider running that.

[coder]

I really wonder how useful this is. About 2 years ago I took an Amiga with a Cyberstorm Mk3 68060 @66MHz, built a basic Linux 5.19 and busybox ... It is just not usable. And no, even with a CT-60 at 133MHz this will be absolutely painful.

I think the key detail from the article is that it's being done in an emulator. We'd have to ask the author, but I'm not sure they ever intend to run it on bare hardware.

As for the possible benefits of supporting old hardware in emulation:

• stress-tests the emulator, itself
• possibly helps document or firm up understanding of some arcane details of the hardware.
• improves quality of life, for those doing development & debugging of software designed to run in the emulator.

Can't say if any of those are true motives, but if I were working with old hardware in emulation, they're reasons I might want to do something like this.

BTW, thanks for sharing your experience. I've sometimes wondered how well modern Linux would run on a machine like that!

[coder]

I don't give a crap about this, but I consider Linux isn't supposed at something but it's a project with nearly infinite possibilities.

Are you an expert in Linux philosophy?

I'm not opposed to this specific effort, but if we play devil's advocate, an argument against merging it to upstream is that it clutters up the source tree with code for a niche use case that's only going to become more niche, over time.

We see a lot of news on this site about support for old hardware being removed, as the maintenance burden of each line of kernel source is nonzero and it's of little value to keep around support for hardware that's not being maintained.

I guess my thinking is that if it's maintained and helps anyone develop & debug software for 68060 machines, then it's probably justified. But, the idea that support for any hardware, whatsoever can be upstreamed... is clearly going too far. I'm not sure exactly what the cutoff point is, but luckily it's not my decision to make.

[Akiko]

Netbsd boots faster than that, on my 68030@50. Maybe consider running that.

Oh, I also do that and it is currently the only modern OS to run on an Alpha 21264 (I got a ton of these nostalgia machines ... HP-PA 8900, POWER4+, fucking Itanium, though Amiga is most fun). NetBSD is odd, getting a properly working desktop is - uhm - also no fun, and if you end up using ports on your m68k machine, it is going to die the heat death. Actually NetBSD supports the CS Mk3/PPC (I have both) SCSI and the Fast-ATA controllers, but it is also horribly slow. I mean, comparing these several MiB big kernels to a max 24KiB Exec kernel just shows why. Hmm, Exec on AOS 3.1 is smaller, isn't it? 17-18KiB?

I'm actually a bit surprised noone questioned my post ... I mean, kernel 5.19 two years ago? My last attempt was about 2 months ago. I may give it a try again, this time Amiga, Alpha and Yocto.

[rogerx]

God I how I hate all the Microsoft coders infiltering the peaceful Linux userland!

Rust this rust that... click n' playing while whining about good ol' tinkering.

[coder]

God I how I hate all the Microsoft coders infiltering the peaceful Linux userland!

Rust this rust that...

What does Rust have to do with Microsoft? It came from the Mozilla Foundation, you know?

[toves]

For me its a matter of perspective. If this were for a recent low powered m68k embedded system perhaps not unlike the ancient Atari then I imagine there would be fewer objections.
I would look upon any such code not so much as legacy (except in the beneficial sense) but more as a collection of possibly unusual test cases for linux kernel code that would exist in any case.
As far as I understand maintainers are obliged to update their code to track any changes in kernel interfaces. Unmaintained code for this sort of hardware would be dropped fairly quickly I should think. Here the dog very much wags the tail.