Linux kernel sheds legacy IDE support, but driver-dominated 5.14 rc1 still grows Linus Torvalds has loosed the first release candidate for version 5.14 of the Linux kernel, Torvalds’s remarks about the new release open with his hopes that this release cycle is smooth, along with an observation that the size of a release does not correlate with whether the process is calm. He then encouraged developers to …
This is the removal of a lot of ancient driver code specifically hard-coded for old PATA controller hardware. The same controllers are still supported with smaller, more modular drivers based on libata and presenting the drives as pseudo-SCSI devices.
So no, old 40-pin cables have not just been obsoleted. Just old device names in the /dev/hda style, which now become /dev/sda style.
l imagine there will be some exciting quirks to discover while moving to the new kernel on systems with the old hardware. You 'get to' discover all the places which have unwisely hard-coded hda-style names. (I also imagine that most of the affected systems will be VMs, here in the early 2020s...)
With a laptop that old (this one is ~17 years old) you hardly need a modern kernel. Any of the LTS kernels will work quite nicely, and will possibly be quicker than a more modern, "bloated" kernel. Obviously, if you compile your own kernels the modern one might not be all that bloated ... but then the LTS version will be slimmer still.
The fanbois who insist on using the most modern and up to date kernel on older hardware boggle my mind. Save some CPU cycles and HDD space and use the LTS code, knuckleheads ... That's what it's maintained for!
If you compile your own kernel you already know all this, so why are you still reading?
It is on OpenBSD at the moment (as part of The Old Computer Challenge). Reasonably snappy but as always it is the Web browser that bogs. Seamonkey with javascript off and a hosts file results in a usable system.
Slackware stable with its 4.4 series kernel next (when it goes back on the shelf)
The Slackware 14.x series has no listed EOL as I type ... Slack-stable (14.2) uses the 4.4.x SLTS[0] kernel series, which will be maintained until 2026 and possibly until 2036. If I know the Slackware maintainers & other volunteers, it'll still be maintained at least that long.
Running it in several places. Makes older hardware sing. Recommended. (I also recommend Slack 15.x for more modern hardware, now in 15.0 Beta & running kernel 5.12.16 ... it might be in Beta, but it's more stable than many other distros that I've tried.)
[0] "Super Long Term Support", also known as the Civil Infrastructure Platform. Somehow, I seriously doubt that kernel support for IDE drives will be going away any time soon.
I'm still running Slackware on my original IBM PC XT. How dare Linus remove IDE support!? What's next, dead badger support?
It's really the controller, not the drive.
I remember occasionally hooking up for example ST-225 to RLL controller. Better the drive, better the chance of it working. In fact, whilst probably an oddity, i found ST-225 more reliable with the RLL controller than the "real" ST-238R.
"Icon: Beer for anyone who does remember all those ribbon cables....."
I do. Not too far away, was I requested to recover data from a disk. I shockingly stared at the IDE interface. At the end, I pushed back because I no longer have any suitable mobo.
They're hard to find, those days ...
You can still get USB-to-IDE adaptors ...
Indeed ...
I still have the one inside a rather flaky Transcend portable HDD case.
The survivor of a pair with 2.5" 40Gb drives I purchased eons ago and which I have managed to use with a RPi 3B, albeit with added power from a second USB port.
O.
In my Big Box of Stuff, I have adapters for USB 1 to IDE and from mains power to Molex power.
The presence of those adapters in my box has ensured that I have never needed to use them. Obviously if I were to get rid of them, then I would need them the day after the bin lorry takes them away.
I remember some slimline Wang 286 PCs with drives that LOOKED like IDE. Same rear, same ribbon.
But they used a ROM and socket on the riser card for the I/O cards. No actual IDE drive would work on the PC, nor would these "IDE appearance" drives work on anything else.
Never had a problem with my SATA-IDE interfaces, or indeed the IDE-SATA (except the laptop BIOS would refuse to load if more than a 120G drive (IDE or SATA) detected in the Media Bay. Just about space to fit IDE-SATA adaptor in the media bay HDD case and add an 80G SATA drive.
SATA - IDE adaptors at about €6 work for HDDs, CD-ROMs and DVD drives.
Far more compatible and faster than a USB adaptor.
I do have one older Mobo with Linux and a floppy port. The 5.25", 3.5" and 3" drives do work and using a library, even CP/M formats including Amstrad. I compiled the Joyce Emulator too, which was a bit of work to get all the aged dependencies. But it works with real 3" drives or files emulating drives.
Warning: the 3" drives have the +5V and +12V reversed, but I knew that from using a 3.5" drive in the PCW8256 (with RAM upgraded to 512).
You can use 8" or 3" drives on a regular floppy port just with a dumb cable adaptor. But Apple II 100K 5.25" drives won't work on anything except an Apple II; proprietary.
USB Floppy adaptor/drive ONLY works for regular FAT12 MSDOS discs. No good for CP/M, Amstrad or Amiga.
I'm not sure if Amiga discs can be read on the setup and I have an idea the Hard Sectored discs (a hole per sector instead of just one) might not work. ACT 1/ Victor 9000 5.25" floppies won't work either as they are variable speed to increase capacity.
Periodically backups need transferred to new mediums. Writeable CDs, DVDs and Flash can fade. Other formats of tape, MO disc, floppy, HDD etc need interfaces and/or drives unavailable.
I THINK I've everything copied off old IDE drives lying around and I did copy the old MFM drives content on XTs and ATs to IDE on an AT clone. (5 M, 10 M and 20M byte drives).
Beer for anyone who does remember all those ribbon cables.
I still seem to have a lot, though nothing to plug them into. And some Apple SCSI cables. And BNC connectors from 10base2 days. And boxes of screws and spacers from old cases. And at least 2 PCI modems. I can't explain how they seem to resist my futile recycling attempts.
RS233 was first standardised in 1960, but that merely formalised what had been around for a long time before then (they had teleprinters using the same basic idea back in WW2). I don't know if you still can, but I remember having PCs whose RS233 ports could be configured to support 5bit Baudot code (teleprinters still being just about recently relevant when the first PCs came out).
Amusingly, SATA has more in common with RS232 than it does with IDE.
I only started working on data comms (WAN and LAN but not internal computer networks) in 1980 but I still have a collection of breakout boxes, gender changes, 25-pin-to-various-other connectors, coax ethernet terminators, etc.
All through the 80's someone would introduce a technology to speed up comms by using more wires but these were quickly obsoleted by technology just making serial comms 10-times faster (with less cost and more reliability by not needing so many connectors on backplanes and so many working wires in cables).
Eventually even internal computer comms went to serial with SATA and USB.
Perfect.
For a while the only printer we had was a teleprinter, and it was pretty slow. Printing out a long listing was something to start before lunchtime and maybe it'd be ready afterwards. I can still hear it: chugga chugga chugga chugga chugga ding chugga wham! (that was the carriage return, you could really feel it happening...) chugga etc.
We know a song about the RS232 interface lead, don't we children?
I've no knowledge of the situation in Linux, but what I have seen elsewhere is code generated automagically from documentation (thankfully, well structured documentation). If there are tables of registers accessible by some means in script-consumable documents, this is well worth it. One still has to write code to tweak registers in the right way, but at least the registers are easily accessible without relying on someone manually entering a lot of addresses by hand.
>Among the notable planned inclusions in Linux 5.14 are support for the Rust programming language,...
The registers coverage of kernel development is awful. Considering all of the articles you guys make about single sentences in emails on the LKML you'd think you could take the time to research how the kernel development process works.
5.14rc1 is out. This means the merge window is closed. Anything that wanted to go into 5.14 should have been merged by now.
If not it's probably not going in.
https://www.kernel.org/doc/html/latest/process/2.Process.html?highlight=merge%20window
Sorry but what you have written makes no sense.
If you plan for something to be in 5.14 you sent your pull request somewhere between 5.13 being tagged and 5.14rc1 being tagged. If you didn't send a pull request in the "merge window" (Which is the fancy name for the period after the last release and the next rc1) then there is no plan for it to go in.
>The fact it's a 'release candidate' was mentioned in the first candidate,
In the linux release process rc1 is when all major code changes are in. If it's not in rc1 and it's not fixing a bug that came in/got exposed with all of the stuff that got merged it's unlikely you're going to get Linus to accept your pull request. Especially for something big like adding support for a new language into the kernel build system.
You don't have to believe me. Read the linked document that comes from the kernel source code and check for yourself. Maybe once you've understood it you'll teach the guy at the register that has the job of trawling the LKML for clickbait so they can at least write nonsense that has some relation to reality.
IDE should work on that just fine (assuming it still boots, I have no idea what the situation is with really old x86 stuff) because if the register had actually known what they were writing about it would have been clear that the legacy IDE driver was removed and not IDE support.
The legacy driver was mainly used for machines that have a few people still maintaining support for the fun of it like m68k, superh etc.
I forgot it was a "new" thing, but I've glanced over it on servethehome and various other sites. The way I read it, it sounded more like TCP over NVMe, ie. issuing whatever storage commands over a meshed/fabric TCP layer. Whatever, the "I can excuse the price for my application" is so pricey I probably won't live long enough to utilize it. All the hardware requirements to desire such a thing is so high ($$$$) that it seems well off down the road for non-enterprise.
EDIT: Yep, it's undoubtedly being called "NVMe over TCP". I'm either getting too old or really out of the loop as I'm still reading it as if it should be named in reverse... :-/
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
