Linux Looks To Finally Remove Its Legacy IDE Driver Support

[NateHubbard]

Actually in some cases attached hardware may represent your income... and now you are faced with the choice of secure software or $$.

If there are legit shortfalls of the surviving driver, this is likely a good time to create clear bug reports and offer your time for diagnostic testing and validation of fixes.

I'm betting this kind of hardware ( >10 years old) is being used by enthusiasts mostly. Especially if they are running Linux.

[ix900]

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.)

Don't know. Seen some rather important businesses using old SW with old HW.

I definitely don't understand people who want to use eg 20 year old hardware and have the latest SW. Just buy new HW lol. Its 20 years old. That's a whole different world. I have a 20+ year old computer sitting here and do not attempt to put stuff from today on it. 10 years I will simply because its 4 core, etc and many computers are still sold with less performance but there's a point where it doesn't make sense.

[Etherman]

Goodbye hda, hdb, hdc and hdd :-(

[AlDunsmuir]

Yeah, that's what I say about once a month on here. Nobody is forcing you to run ancient hardware. Nobody is forcing you to not run it because the software is old.

Actually in some cases attached hardware may represent your income... and now you are faced with the choice of secure software or $$.

If there are legit shortfalls of the surviving driver, this is likely a good time to create clear bug reports and offer your time for diagnostic testing and validation of fixes.

[NateHubbard]

Well, this is what people usually tend to say. "Yeah, come on, just use some old SW for your old HW".

Yeah, that's what I say about once a month on here. Nobody is forcing you to run ancient hardware. Nobody is forcing you to not run it because the software is old.

[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.

[rene]

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

[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.

[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.)

[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.