Linux Looks To Finally Remove Its Legacy IDE Driver Support

[phoronix]

Phoronix: Linux Looks To Finally Remove Its Legacy IDE Driver Support

It's 2021 and proposed patches by upstream developers would finally remove Linux's legacy IDE driver code...

https://www.phoronix.com/scan.php?pa...egacy-IDE-2021

[cl333r]

41k is good but it barely matters since support for each new AMD card drops like 5-6 figures lines of code into the kernel.

[reavertm]

Aren't AMD code drop a drops of primarily generated code though? So no/little maintenance cost associated?

[Chewi]

Crap, I had a feeling m68k would be impacted by this. At least I can still boot my Amiga over NFS.

[TemplarGR]

Crap, I had a feeling m68k would be impacted by this. At least I can still boot my Amiga over NFS.

You can also still use an older kernel on your m68k, for example 5.12. I am sure your m68k will be fine not running 5.13 kernel.

[Adarion]

Well, I surely do hope they tested.
I'm not certain the "new" /dev/sd? driver (vs. the old /dev/hd? one) is really as good as the old one for all drivers. I remember that I have some SiS55x based Thin Client that boots quickly with its original SW (which is based on some older Linux kernel) but me booting some more recent kernel had a 50 seconds delay on boot due to the IDE driver having problems with the CF card. Seemed to negotiate for a long time about UDMA/PIO levels, until it would finally work. That kinda sucks. And I guess I already used the new stack (only /dev/sd? then).
And what about "slightly dated" MFM/RLL controllers / drives? I remember in the old days there was some option, I must check if it is still there in the new stack. I actually have one or two of these old monsters floating around.

[Adarion]

You can also still use an older kernel on your m68k, for example 5.12. I am sure your m68k will be fine not running 5.13 kernel.

Well, this is what people usually tend to say. "Yeah, come on, just use some old SW for your old HW". That will work at the moment, but you'll then never be able to participate from new kernel infrastructure, newly added drivers or other improvements that could be relevant for your HW, bug and security fixes and so on. So this is quite a mixed bag.
(However, I also understand that not all kernel devs do have time and HW access to test the big bunch of HW that is supported by the kernel.)

[Yttrium]

Aren't AMD code drop a drops of primarily generated code though? So no/little maintenance cost associated?

Dont see how this is connected to the article but yes, Chip vendors have lots of Chip/device dependent information that needs to be passed to the kernel. Think about everything from vram amounts and feature level support to versioning, microcode and other information that is inherited when you make a chip. most of it is duplicated for every device with only minor changes. Tools like glxinfo give you an overview of the monolithic amount of information in a single graphics card.

[rene]

yay, computer science innovation, sounds like the future of desktop linux is near! ;-)

[Veerappan]

Well, I surely do hope they tested.
I'm not certain the "new" /dev/sd? driver (vs. the old /dev/hd? one) is really as good as the old one for all drivers. I remember that I have some SiS55x based Thin Client that boots quickly with its original SW (which is based on some older Linux kernel) but me booting some more recent kernel had a 50 seconds delay on boot due to the IDE driver having problems with the CF card. Seemed to negotiate for a long time about UDMA/PIO levels, until it would finally work. That kinda sucks. And I guess I already used the new stack (only /dev/sd? then).
And what about "slightly dated" MFM/RLL controllers / drives? I remember in the old days there was some option, I must check if it is still there in the new stack. I actually have one or two of these old monsters floating around.

Just in case it helps, there's actually libata flags you can pass in on boot to force either PIO or DMA modes. The flags can be per drive, per controller, or system-wide. I need to use them on an old Alpha system of mine that had a DMA controller bug that corrupts transfers over a certain page size (and therefore the filesystem).

Do some searches for 'libata.force' on the kernel command line.