 Okay, so topic is fairly simple one. So as the LibATM maintainer, every time we add new features, so SCSI and then ATL layer, we often these days get in trouble with old stuff which is parallel ATL drives. So question is, how long are we going to keep that given that these are not hardware that you can buy anymore? So recently for example, I've been building a test rig for parallel ITA for to be able to test stuff. And the only drives I could find out there are like 16 years old new drive. They've been packaged for more than 15 years. This is pretty much the only thing you can find these days. So how long we keep that stuff? So I've been asking people around and I know for example, Christophe Helwig is currently opposed to removing parallel ITA saying that there's a lot of hobbyists that are still interested in keeping that around. My question is, yeah, sure. It's fun to be able to run the latest and greatest kernel on all hardware but do you really need to do that? So removing all of that would simplify a lot of things in LibATM, would make my life easier as a maintainer and would avoid a lot of breakage seeing recently with new feature being added that suddenly breaks these old drives. So you're asking something that basically is being debated about old hardware. Arm is doing a lot of this. Sorry, can you speak up please? Apparently not, thank you. So there's a lot of debate about what we should be doing with old hardware. But while we support old hardware, things like peer risk and all of the other weird and wonderful stuff, we have to support the devices and drivers that came with them at the point they stopped being produced. And the rule for old hardware seems to be that as long as it has an enthusiast community, we still have to support it. And that means that unfortunately, if there's an intersection between enthusiast community, old hardware, and P-AT-A, we have to support that as well. We can't pull the rug from under them because they'll get really annoyed. Yes, but I don't think so there is. Because most of the old hardware is meaning. Most of the old hardware, well, those I know of happily, are using different things. To either a parallel SCSI, that's for the more enter-classy things, or some other, whatever, some Amiga stuff, whatever they do. Just a random question though. Are we constrained with which architecture is actually, you know, we're talking about here, they would use this. Is there some funky architecture other than x86 No, no, that doesn't depend on the architecture. I understand that. I'm trying to ask whether or not this is a problem only for x86, because if it is, then you can actually just use some sort of ACPI flag to basically create a legacy type of flag to clear a platform and ensure that it's not there. So at least at runtime, then it becomes deprecated, but you still have the code present. Exactly, but the problem is the code that P-AT-A support is quite a lot of code. I would guess it's about what, three quarters of the entire P-AT-A source code. Just for... Yeah, and everything is supported through the same interface, which makes every function. The first thing essentially every function is doing is starting looking at, is it a master sleigh thing for parallel ITA, or is it SATA queuing? Everything is complicated because of that. Yeah, and you have a ton of drivers that, personally, I cannot test. So what you're telling us is we shouldn't have unified lib-AT-A and P-AT-A. We should have just kept them separate as they originally were. Yeah. That's even probably harder to do now that definitely something I don't want to touch about. But there are definitely a set of machines that still need the P-AT-A interface. So what happened is, can you name one? All of the really, really early machines were SCSI. So some of the 8-bit SCSI interfaces are still in the older ones. And then the enterprise still kept with SCSI and never adopted ATA. But there are some hobbyist machines like Commodore machines and some of the other weird and wonderful sort of older platforms that actually are P-AT-A. And as long as we have a hobbyist community around those, we're still gonna need to support them somehow. I, and that is the problem, because the real problem here is not so much the HBAs or the adapters. You've got plenty of those, yeah, right, granted. But you need to connect something to it. And that's their old drives. Sorry? They all have their old drives and accidentally some of the old drives haven't gone pop. I mean, yes they do. I've got 8-bit SCSI drives that are still rotating. Okay. Okay, so. But I mean, this is something which will continue to bug us forever and ever. Right, but it sounds like the problem you're trying to solve is you want this to be a lot less as a maintenance problem and an ongoing evolution of the subsystem problem. Well, ATA and evolution is kind of, I'm not sure I want to use those words in the same sentence, but. That's the point. The interface is now fixed. Nobody will have a drive that supports more commands or more anything else. It's all off in the legacy bucket. So all you want to do is stop the, stop impacting the evolution of SATA. Yes. Right, so what we probably will do. Well, no, so the parallel ATA being there is not actually stopping any evolution of the SATA side of the serial side. We can still add new features and we are doing that. The problem is every time we add a new feature, so ATA as it is designed, you will normally discover the features when you read some log page to discover if the new feature is supported or not and the drive will tell you. But by doing that, you create this new access, for example, to the log page that is fine with modern SATA drives because if the feature or the page is not supported, you get back in there and that's the end of it. But all the drive just break. They are certainly not going to work or hang or the adapter is going to completely hang and I've been hit by with such problems several times in the last two, three cycles. But you just, unfortunately, you just contradicted yourself. Well, no, it's because if you, if you, your one argument point is that there is no hardware out there which is doing P-A-T-A, then clearly they can't break because they don't exist anymore. No, but the point is that the new feature coming to the latest language is kernel. Those people who is all are, why do they really need to run that kernel? Which doesn't actually work anymore? We spar all right here. They call all of the active maintained communities for old hardware run new kernels. We can't tell them not to. Just call them Fintine who is running one M68K on some random hardware. Isn't there another solution to your problem? Which is you said that it's basically to do with the inquiry pages and you don't need to send the inquiry pages if you already know that you're attaching to an old driver. No, the main issue is that to know about the feature you need to send that inquiry. But you don't. You've already said that. Particularly if we put a flag in all the P-A-T-A drivers and said I'm a P-A-T-A driver, you already know by the driver that's running your system that you don't need to send the inquiry. Yeah, the issue though, it doesn't really fit how the standard is written. But the issue isn't following the standard. Because remember SATA and well, it's ATM mass, but essentially when you say parallelity we're talking about ID that's the transport layer that's not the protocol layer. Which becomes a mess because when you come to SATA you actually are now in CQ and that's actually coded in the protocol and it's not really, it is also a transport but it becomes messy. Right, but we know how to cope with this. In SCSI we've gone through the deprecation of the old read-write commands and that worked reasonably well. We use flags to say you don't do this, you do this for this drive. So there are heuristic ways of allowing the inquiry problem not to impact you. And as long as it's not holding back development of the SATA subsystem, just do some sort of flag thing, call it done, stick it off in the corner. Yeah, so some, okay, some. Yeah, so basically create essentially a class of legacy hardware and you just new stuff don't touch those devices. So essentially we would need to have the inverse of the current ATA horkage because currently we do have per device flags but they need to be actively set per device. We can't invert that mechanism. But that can be, well there is already the ATA SATA flag and if it's not set, you know it's not SATA, so. So yes, so I guess this might be an idea. How would that be? That is actually a good idea to deal with these issues because every other weekend I'm getting a bugsy about someone complaining that their old parallel ATA laptop or whatever got broken or it's not working with the latest kernel, so. Yeah, but I mean as long as people are running the stuff and have active hardware, we shouldn't really discourage them. So I'm fully with James there that as long as there are users we should continue supporting those users. They surely don't need the latest feature we do put in but they should be able to use the latest kernel. That's for sure. Only if there are no users then we can easily, then we should be going ahead and deleting that drive because that's essentially just bit rot and really should be removed. Do everything you can do to get away from maintenance burden just shovel them off in a corner somewhere but don't deliberately break them. Got it. Okay, I'll work on that then. Don't touch drivers. Is there any way that we could do something sort of the reverse of staging where we have like frozen older drivers for this kind of thing or has this been talked about in the past? Well, if you want, who was it who said the trash fire that is called staging? If you want to dabble in that, feel free. Yeah. No, it's, it's because this has also been a fairly common problem with actively maintained drivers with vendors older hardware where they don't necessarily have the cards to test the older hardware with the drivers. And so it seems like it's sort of a, it's a problem that sort of extends beyond the specific case. It's also partly, so yes, that comes into play because one of the other, so I would say reason for all the breakage I'm seeing is that it's hard to get people to review and test ATA flags, ATA patches. There are a lot of my pull requests. The patches are mine and mine only. There's not, not a review by tag on them because I don't, I can't get anybody to review and test. By ATA patches, you mean SATA patches or just? Yes. Well, that's a separate problem. It's related because in the end I'm pushing stuff that I tested myself in my limited hardware environment and that leads to breakage, yes. Just to go back to the staging point. Staging is a problem. It's a trash fire because lots of people don't compile it. So we won't find out about any breakage we accidentally did until months and months and months down the road. That makes it a bigger problem to fix and a more difficult one because once people start squawking, Lena starts hearing and it suddenly becomes a massive emergency. If it's not in staging and it's in P-A-T-A, we have at least the compile failures we can pick up and hopefully people who are closer to this tree will also pick up other failures. Well, that one I worked a lot on it, the compile failures and that's been cleaned up and fixed recently. But the testing for new features are being added to make sure there's no regression on all hardware. That's not something I'm seeing a lot of tested by or reviewed by tags from people. And I know people out there are still using ATA again because I'm getting reports of regressions. Well, so and also moving things to staging doesn't really help because you still would need to update or fix drivers if you do any whatever interface changes to the library itself, meaning to live ATA. The drivers still will be affected. They will be just in a different place but it doesn't change anything really. Yeah, so James, I think what you're saying is the current way that things are done is sort of, it's working as designed in that, you know, if Damian goes and makes a change and it breaks something with PTA for some of the, it's got one of these platforms, they're gonna complain. Yeah, and I'm gonna find out. Once no one complains, you can leave it broken, mark it broken and move it from the tree but if someone's gonna notice, you have to fix it because. Right, so you're saying this is the only way that we're gonna find out is because the codes enabled and people that are dependent on it will use it. And regarding the testing, there's always QMU and you can always emulate devices in QMU. It's a pain, but that doesn't get done though. QMU has one type of parallel IT adapter, CH9 or whatever it is. There are plenty more out there. And the problem with parallel ITA, you have the adapter but you have the drives too and you get a ton of buggy drives connected so whoever has those drives and you are not careful when you add a new feature and you hit, I don't know, read log, no DMA or whatever problem with that drive, you get a system hang and it's not booting anymore. But he actually has a point. It should be possible to have a very simple P-88 drive emulated in QMU including all pages and including all. It's not gonna find these issues because the reason why inquiry ends up failing is because it's like a non-standards thing, right? And drivers never saw that. I think no amount of proactive testing in QMU will ever find your issues. I think the only sane course of action here is to make Lib ATA more resilient towards having this happen, right? So James said, have a pat-a-flag, right, that's fine. So you deal with that on the inquiry and probe side of things and then you just sort of split the issue path a little bit, right? So when you do make changes, like for new hardware, it doesn't really impact the old stuff. I think you just need to make Lib AT more resilient so that whatever you do new stuff, right, will not touch any of the legacy things. Because you can't, I mean, we can't move things to staging or you're gonna have two different Lib ATAs, right? That's not gonna work. Close-plus adaptive side is just a little thing. You just need to have it so that you can make code changes and test it on new stuff and know it's never gonna affect any of the old things. It'll just keep working the way it has because that's the only, otherwise you're always just gonna be playing whack-a-mole with somebody saying, oh, I'm running on a 2164 alpha, you know, with this drive and that fails now because you made this change and whatnot. If you just ensure that all the old stuff keeps doing the same thing it's always been doing, then you won't have any issues with it. And also, I think that's the best approach. There is a community somewhere. If you just sent them copies of patches, they might actually look at them and test them out. So, what's here? That'll take months, I think. I wasn't saying you wait for the answer. I was just saying you send the patches to them. If they don't reply, tough. So, right, but then they apply three months later and then you're like, oh, get great. And now you're dealing with like three revisions of table patches of things. Yeah, yeah, but is there a reply three months later worse than a bug or something? So, I do, I do. You just need to make it harder to happen. I think that's the only sane solution. So, there are a lot of cases I see on Bugzilla. I do look at all regression and I try to fix them. I do send patches to people and tell them, can you try apply this build kernel and then try it? We are dealing, most of the time, with regular users who don't know how to do that. Or the only way for them to do it is to actually compile kernel on the hardware that is failing. And it's all hardware. It takes them one day to compile kernel. So, it is hard to ask people to do that. But, yes, so what you discussed James and Jens, that isolating parallel ATA drive, all hardware, to not be touched by a new feature, I think is, yeah, the best approach. And please review ATA patches. That's all I had, so, thanks. I missed that as well, but thanks everyone.