 Felly, amddangos wedi'u cael eich bod yn ymdw i'w'r boff. Felly efallai'n agender i'r llwysgol, ond hwnna'n mynd i'w gwbl yn ymdweud o'r gwaith ar y dda o'r Unedig i Ylwllol pan yw'r 45 mhenud. Mae'n gweithio'r boff, dyma'r fawr. Felly ydych chi'n gweithio'r gobydol, mae chi'n gweithio i'r gobydol, byddwn i'r gweithio'r gweithio'r gweithio'r gweithio. I will do my usual thing of sending out a summary of what's discussed here and what goes in that document to the mailing lists after the conference. I think that's really important for other people who can't be here and also so we get a proper record of what's been said, agreed and people blamed and all that kind of stuff. So, in order, going backwards for once, you'll see why in a moment, ARM64 is the newest of our current ARM ports. It's working quite well, we released it with Jesse, we're starting to see more devices coming available that will actually run ARM64. Debian quite well, we're starting to see we'll serve a hardware actually turning up and there is more coming. Thankfully, there are better standards available for ARM64 than for previous generations of ARM hardware that mean that we don't need to have 17 different kernels, we just have the one and it should all just work with device tree or now ACPI is becoming more of a feature, especially if you're running server hardware, ACPI is the way you should be running these things. I work with some of the guys who've worked on device tree and ACPI and the two are basically equivalent in terms of the functionality they give, but ACPI is the better choice for the future just because there are better standards for it. So, ARMHF, going back a bit, we first released with Weezy, it uses the ARMv7 hard float ABI, which depends on VFPv3D16. I will explain what that means if anyone wants me to. Good, sorry? Good, good. It is the standard across 32-bit ARM Linux distros. This is the thing that Debian, Fedora, SUSE, all of the big well-known distros agreed on as the baseline for their 32-bit ARMv7 ports now, multiple years ago. So, you actually have a fair chance of binaries from one distro actually running on another distro. For those people who are used to the x86 world, that may not seem like much, in the ARM world, this was a, oh, hallelujah, this was a major, major win for us. Again, we have a reasonable chance of all of the hardware out there now running just using one standard kernel, the ARM MP kernel, MPB multi-platform. Again, device tree makes that possible. We have a second kernel available, which is ARM MP LPAE. So, if you're fortunate enough to have a V7 device with more than four gigs of RAM, you'll want that instead. More memory is better, obviously. UEFI is now a thing on ARMv7. There are some boards that people are talking about shipping with UEFI firmware by default. Also, due to the work that's been ongoing in Uboot, there is support for enough of a UEFI interface in Uboot for some hardware that you can now boot by UEFI that way, which actually means you might get things like just working out of the box if you plug in a USB stick, that kind of thing. This is really, really good. If I remember correctly, it was Alex Graff from SUSE who did the work for this. He's an awesome guy, much kudos to him. He's continuing to work on improving this as time goes on. So, ARMvL is the oldest of our current ports. Have I suddenly just got louder? Okay, fine. Not just me having a stroke or anything. That's fine. So, ARMvL is the oldest of our current ports for ARM in Debian, using the soft float ABI targeting ARMv4T and newer. It's still supported upstream in the kernel, in the tool chain and whatever-ish. I'll expand on that slightly. While, obviously, people care that you can still build the kernel compilers and lots and lots of core libraries for ARMv4 and so on, because, hell, ARM still sell or ARM licensees still sell a huge number of v4 devices and even older, there is a problem, and it's been coming for a while, that lots and lots of the bigger applications and libraries further up the stack don't care about v4. This has been fairly obvious for quite a while. We do have problems, for example, if you want to run anything like a modern browser, if you want to get Firefox, if you want to get Chrome or almost any of the really big, large applications running, you're probably going to have problems. People don't care about this stuff anymore, which is why we've been talking about this for the last couple of years. We are planning on dropping ARMvL from testing soon and not releasing with Buster. That is not a done deal. There is still scope for people to step up and make sure it's supported, but we've been calling out for wheel commitment from developers for the last couple of years to help out with issues as they come up on ARMvL, and they have been not exactly forthcoming. I appreciate this is going to be unfair to people out there who have ARMvL installations on older hardware, but it's the same way whenever any port is dropped from Debian, there are always users, and we appreciate that, and we have to apologise to those users, but unfortunately for us to continue to keep something in Debian, we need developers too. By semi-announcing this last year and the year before, we've given people plenty of warning this was coming. As we did release with Stretch, and of course we're going to be continuing to support ARMvL for the lifetime of Stretch for security, people have at least three years worth of life left in that existing hardware, which is not bad even if you just bought it last week. There is a fair chance that when we get round to Stretch LTS, just like Jesse LTS, we will get ARMvL supported there too. You might get five years, but definitely if you're depending on ARMv4 machinery, ARMv5 machinery running ARMvL, now is the time to start thinking about moving on. You have plenty of warning. Obviously it's not going to go on fire the day we turn it off, but you're not going to get security updates forever, and that is a sad fact, but it's something people should be aware of. Any comments on that? Do we have dull acceptance? Do we have anybody awake? Do you want to grab a mic to make sure? I'm told the microphone's in here okay, but it doesn't hurt. Like you say, without the developer support, so it seems also now is the time to really step up and stand strong if you want that to be supported in cluster. I mean, dare I say, if you have that kind of device, it's possibly also worth considering do you need a full Debian port for it? We've had the discussion around this again for maybe three years now, and people have continued to suggest that we should do other things. Could we do a partial port? Could we do, as in just strip out, the larger applications that people don't use on this hardware, that kind of thing, like X and LibreOffice and the browsers and things. That sounds attractive, but again, what it comes down to is show me the code, show me the effort to make it happen. For all that, yes, it is certainly something that is technically possible, it needs actual work, and without that actual work happening and being done by actual developers, it will continue to be pie in the sky basically forever. It's not too late, but people need to be demonstrating work on it now. Do you want to grab a mic? Sorry, Bill. The builders for ARM EL, are they ARM V4, or are they bigger machines? They are ARM V7, and that's currently just what I'm about to talk about. So we have a mix of machines for our buildees. We have the main ones, this is a really bad dark photo, these little orange Marvell boxes that Marvell donated to us a few years ago, on one of XP's, we have seven of those currently building away, doing both ARM HF and ARM EL. They're really nice machines, they are quad core, they take lots of memory, they're absolutely wonderful if you'd want a V7 server box. The scale way folks actually have a number of machines in the cloud that you can rent, which are essentially this hardware but in a different form factor. They're really nice and I'm still very happy and very grateful to Marvell for giving us those. Those are awesome. The only downside is they don't have neon. So if you are running, if you're building software for example that has a test suite, if you try and run it on one of these and it depends on neon, you will get undefined instructions and exceptions, you will see problems. Specifically for that, we still have a free scale IMEX 53 port-a-box, Harris, which has been running now for seven years I think, maybe six. When we first started, previously to the Marvell boxes, we had a whole whack of these instead. They were great at the time, but they're only single core Cortex-A8. They only have one gig of RAM. Trying to build something big on them is awful. However, if you need to debug a neon issue, that's deliberately why we've kept this around. So ARM64 does give us more options. We have an AMD Seattle hosted in the data centre at ARM. We have multiple APM Mustangs. I've got one in ARM, there are a few that Lenovo are hosting. We started off the port for ARM64 with a couple of ARM Junos. We still have one of those running. The other one is on my desk because it's disk died. To be honest, we don't need it running anymore. There are more machines coming. I've been promised, I've been talking to several of the silicon vendors who are very keen to help with the ARM64 port. By the way, they might have customers who are demanding that Debian works on their hardware. The two are not entirely unrelated, we shall see. What we've been considering for quite a while is trying to move on to more and more ARM64 hardware and start building on HF2. One of the nice things about ARM64, as I said, is it's proper server boxes. Proper server boxes come with nice features like they go in a rack properly. They have proper power control. They have real ethernet. They have all of the nice features that you want, lights out management, all of that kind of stuff that you want if you're going to put these things into a data centre and not have a monkey like me going round to go push buttons to reset them when they break. It matters. The flip side of that is you can't rely on running ARMEL or building ARMEL stuff on ARM64. There are instructions from V4 that have been deprecated for a very long time and if you try running some of the ARMV4 code on ARM64 you are likely to start triggering exceptions, particularly with the old Bowyer code. I had a question kind of on that vein. We've been running some ARM64 boards but building ARMHF for the reproducible build stuff and we're encountering some issues with the builds actually working correctly. It seems like there are some ARMV6 instructions that were gently deprecated in ARMV7 and more harshly deprecated in ARMV8 so we're running into some issues there. Are they V6 instructions or are they older? I think V6 but the CP15 barrier exception is an older than ARMV6. It goes back to ARMV4 and that is the one that specifically causes issues. Over time obviously for the people who might not be aware, the ARM instruction set has evolved over the years. CP15 barriers were about the only thing available in V4 and there was very little else in terms of support for atomic code. However, once we moved forward to V6 and then on to V7 there were significantly better designed memory barriers and atomics available and that's what you'll be using now. If you're seeing CP15 in an ARMHF build you've probably got an embedded copy of LibGC that is too old. Yeah, it's in anything that calls GHC basically. Great. Which is a lot. Essentially this is where it comes from. I found, I did a scan in Lenovo again three years ago, maybe four now, looking for embedded assembly in places. I found for example there were many many copies of LibGC, the Garbage Collection Library, the Bone Garbage Collection Library, that were more than capable in a modern version of using proper V6 and V7 atomics but the upstream software that had embedded the copy had embedded one ten years ago and you never need to update, do you? So those are quite possibly where these problems are coming from. So that seems like an issue we're going to have to explore in greater detail? Oh absolutely, yes. The compatibility issues of running an ARMHF charoute on an ARM64 machine? Sure. The one that found this that showed me this was I ran W3M on the console of an ARM64 box. I think our need is to download a .dev specifically and I didn't have any other way. And yeah, it seg faulted. It faulted immediately at startup and I thought, what the hell? And that was when this one really hit home for me. We need this fixing properly so definitely file bugs, mail the ARM list and we'll go from there. So I dealt with an analogous situation on PowerPC because the E500 doesn't have a W sync instruction that is all over the archive. And the solution that is kind of a sleazy hack that worked extremely well was I emulated the instruction in an undefined exception handler and the slowdown was imperceptible. So if these instructions are not common. Sure. So we've spoken about this. There is support in the kernel for emulating CP15. Like back in the day people added support for emulating the swap instruction which was the other common way people did atomics on ancient ARM hardware. You can do it, but what we're finding now is as more and more code is built that depends on these atomics, particularly the C++11, the ARMv4 and ARMv5 cannot provide hardware assistance to match the model that is needed for C++11 atomics. So you need to have a handler, you need to have support in the exception handler in the kernel. That is painful and it's not something we should be depending on. So, Adrian. At least the thing for C++11 is that actually you've probably seen that, right? They recently added the feature that they can implement standard future without atomics and hardware. You can. They have fixed that. So this is what kept us from building LLVM on ARMrill and it's building now again. Right, but what's the performance cost? There's got to be something involved. We can come back to this again in a moment. Anyway, this is where we are with the buildees and we're looking for using more ARM64. One thing that we can do now with more of the ARM64 hardware is actually run buildees in virtual machines. This is great for better separation and better security, all of those good things. So we're going to see more of that in the future. So now, what else can we be doing and what else should we be doing? So, Adrian. Well, I'm just saying that this particular bug was fixed but I think, sorry for being late, we still have this problem with that basically we don't have fast CPUs available which can have these old instructions, right? Because ARM dropped some of the instructions. Exactly, sorry that we were talking about just before you came in the room. Yes. Using emulation is another question, I guess. Because I know they actually do that in open SUSE for ARM. Sure, it's technically possible it's not the right answer long term. Specifically with the CP15 exceptions, I think it's emulated on ARMv7 and then on ARMv8 it's still emulated but it complains very loudly into the tune of several thousand log messages per second. Yeah, sure. So exactly, if you're using now common code that is coming out of QT, for example, anything like that, which is designed around assuming the C++11 atomics, again, your code can be made to work. That doesn't mean you want it to be if it's running potentially tens of times slower. We've seen this problem coming for a while, which is why. Again, for the sake of Adrian who came in late, it's why we're looking at dropping RML from Buster. As I said, we can technically carry on with it. It will need consistent developer effort focused on keeping it in. None of the existing ARM porters have committed to doing anything about this, which is why after a couple of years of discussion, we're now at this stage. This would make history. We'd be the first port in Debian to voluntarily drop out of a release instead of being told by the release team it's happening. Does that mean we've anti-vancouvered? Does that mean we've Montrealed maybe? I don't know. That's what we're up to. Anyway, we have about 20 minutes more. I will say, please, more porters are always welcome, particularly if you care about this topic. We have a fairly active group on IRC in Hash Debian ARM. Nice imaginative titles for these channels and mailing lists. Please talk about stuff on the mailing list. Look, ARM has a new logo, by the way, in case anyone hasn't noticed. The engineers all love it. Can't you tell? That's it. We spent quite a lot of money, as I understand. I don't know the exact number on going lower case. It's special. Sure. I don't know who wins, who loses. Yes. Are there any implications? I've heard rumours of ARM being bought out or something. Yes, you might have heard last year that ARM ceased being an independent company. We were bought by Softbank, a very large Japanese technology company. The visible effects externally are basically we're not on the stock exchange anymore. That's about it. Masa san bought ARM, he told us. I am an ARM employee in case that's not obvious to anyone. Bought us essentially because he loved ARM and wanted to be part of it. Had some ideas on things ARM could do more of, but promised us faithfully. Of course, this always happens after a takeover. How big your pinch of salt is is a personal thing. He did promise at the time he didn't want to make any big changes. If you're going to spend $30 billion on something and then make major changes, you're probably doing it wrong. The only thing that has come through more is that he is clearly interested in IoT devices. It's not so much that there are less people in ARM working on everything else, but if anything, we are hiring more people to do more IoT things. We already had a lot of those. It's slightly more focus, but not less effort elsewhere, if that makes sense. So far, absolutely, it all seems to be a really good thing. I'm happy with it. Hector. Hello. Paquet.net gave us an offer of hardware. Okay. It's in the cloud, but it's not like real hardware. It's hardware. Sure. So how comfortable are we running build demons and writing things on the cloud instead of supporting our own debt boards and tickering with them? That's a good question. We have traditionally always wanted to run all of our official builds on Debian-owned or at least Debian-controlled hardware. So we do have machines, obviously, in data centres all around the world. We don't always own all of it. So, for example, Lenovo are letting us use a couple of mustangs, and those have been very useful for the ARM64 port, or IBM, where Unicamp have given us access to, but I believe not total control over I could be wrong, a few power-weight machines which are hosted there. I think that's still different to just running things in the cloud. What do people think? I think probably for porter boxes makes plenty of sense, like take them up on it. I mean, what's the worst that's going to happen there? And then, of course, with my reproducible builds had on. If we had reproducible builds as a real world need, all of a sudden, that makes... We need more hardware. Yeah, and then we could do multiple builds on multiple different providers, and we'd have greater assurance that nothing fishy is going on. Yeah, exactly. That would be great. So, as a background, the packet.net stuff, they have some Cavium Thunder X machines, which are incredibly parallel ARM64 hardware. They have, like, 48 cores, lots and lots of memory. They're designed more as network processors rather than general purpose, but, of course, they've got so much CPU horsepower, they can work very well that way. And then you split them up with KVM, so we wouldn't necessarily get a full machine, obviously. We'd be getting a two-core, four-core, eight-core, whatever virtual machine running on those. It's 96 CPU cores, 128 megs of RAM. Gigs of RAM. Yes. Yes. Yeah, it's easy mistake. So, yeah, it's 48 cores per socket, and then they've got two sockets in these boxes. I've seen one of them running in my office briefly. I don't normally get bothered by fan noise, 96 cores in a 2U box. We turned it on and it drove everybody out of the room. Almost physically just from the air movement. One question. Is it true that the Thunder X does not support ARMv7? It has only ARMv8 implemented? No, I'll explain. Because we're trying to build... Sure, yeah, yeah. ARM's naming is incredibly confusing, even for those of us who work for ARM and have access to all of the documentation. So, ARMv4, ARMv5, and V6, we are currently up to ARMv8. ARMv8 was the first ARM processor to include support for the ARCH64 execution state, which is the first ARM64-bit instruction set. We now have, and some of this was invented years after the fact, they've now renamed what previously used to be the ARM instruction set is now called A32 to make it clear it's 32-bit. What was the thumb instruction set is now described as T32 to, again, to make clear it's 32-bit. And we now have A64, which is the brand new AR64-V8 instruction set. It is possible to buy V8 CPUs that are 32-bit only. It is possible to buy V8 CPUs that are 64-bit only, and the Thunder X is one of those. Yes, it does not run A32 natively. Sorry, an apologies for being pedantic, but unfortunately the only way I can keep it straight in my head is I have to explain those things to me every time I think about this, let alone anybody else. It is confusing. So one of the potential issues with using the packet.net machines is absolutely we could not run native A32 code. We could not run RHF on those. We could run straight on 64. We could definitely run as a port-a-box. That sounds great. Personally, I am happier with the idea of us keeping our official buildies on machines controlled by us. It gives me warm fuzzies even if technically it does not necessarily give us any more wheel security. It makes me feel better. I do not know about anybody else. As we have been talking about doing things like secure boot or like Matthew Garrett who was talking yesterday about signing code and whatever, we are going to have to think more possibly in the future about actual security of our buildies if we want to actually make better security, be better security and not just a pretend. Because of course if we go and sign a load of code that has been built on machines that we do not necessarily have full control over, I think we are failing ourselves and the community. The timing of this, the first thing in the morning after the conference party is awesome, isn't it? Thomas? I am pretty new to the ARM architecture and I like to start playing around a little bit. I want to concentrate on 64-bit and I need some suggestions on which hardware to buy. I know that this 48 cores server hardware is something a bit cheaper. I think I would like to have four or eight gigs of RAM, maybe four or eight cores. Any suggestions? Grab a mic if you want to talk, please. There are lots of options, many, many options to the point I've lost track of what to recommend. Peter might tell you. I've been looking, the problem I've been finding is that they've all been out of my price range. Once you get beyond the kind of hobbyist boards with a gig or two of RAM, which are quite affordable, you get up to the... What are essentially demo boards for server hardware? They get one to the better description and they have price tags. There was a gigabyte one, for example, that had a price tag in the £700 range, which is far, far more than you pay for a comparable Intel-based board and far too rich for my taste. There's a dichotomy in the market at the moment. Most of the boards that you're going to see are mobile CPUs, because obviously that's what most of the ARM 64 things are going. Almost any mobile phone you buy now is going to have an ARM V8 processor in it, whether they advertise it that way or not. There are lots and lots of the cheaper dev boards are based, obviously, therefore, around those CPUs, which is great, it works, but it does mean that you're then going to have typically soldered on very limited memory, you're going to have not great IO, you may not have Ethernet, you may not have SATA, and again, depending on your needs, those boards are great for some people. If, however, you want to be able to have something you could run as your own home development system, you're going to want, as you said, 4GB, 8GB of RAM, a few cores, a SATA port, wired Ethernet, the kind of thing to make it usable as a computer. That's exactly what I'm looking for. I totally get that. The hard thing is, I honestly can't really recommend anything today, that's great. Thomas, maybe you want to look into the devian infrastructure and we're running, we got a donation from Gigabyte, they're running APM moustangs, you can get this hardware from Gigabyte and it's sort of kind of desktop motherboard thing, it's 100,000. Also Softiron. The Softiron 1000. There's also a nice price range, but you might have experienced some issues, but if you... The issues you're likely to experience, unfortunately, are that the CPU that they're using is end of life, so they're not going to be making those for very much longer. As I understand, I'd love to be corrected, because I would love them to carry on. The Gigabyte boards, in fact, there were two Gigabyte boards available. One was using the Mustang and we have a couple of those that we're using at Canova. No, don't we? Yes. They also did a cavium-based board, but I have no idea how available those are at the moment. Again, as Peter says, they're basically the moment they're demos of server hardware more than actual... Please give me a retail price and you can order it from your local reseller. We're not there yet. Also, only Max is building some kind of hardware-based all-winner-based, like Chinese CPUs. What I read, there are two versions of the Gigabyte board, one with U-Boat and the other with UEFI, so what would you suggest? Always UEFI. It should just work. I had to fix a couple of bootloader versions, at least in the past year, so I'm a bit inclined towards the U-Boat version, because it may sound weird to the server folks, but the impression is that a lot of these UEFI stuff is a bit locked down and then also similar broke like other bootloaders as well, and you might be lost. I will admit to some bias. I'm also part of the Debian UEFI team. If you're going to run a mobile device, if you're going on a dev board, whatever, U-Boat is perfectly fine. It's no problem. It's a sensible U-Boat. Finding a sane U-Boat for your board can be harder than it should be. If it's all upstreamed, wonderful, you should be able to replace the U-Boat with something that we know will work. I've been bitten over the years by far too many U-Boat implementations on various dev boards, which inexplicably don't support the file system I want to use, or don't support the onboard networking properly, or all kinds of stupid things which just make it more painful. If you want to use your ARM64 machine as a wheel computer, plug it in, use it just like you would with an x86 machine, I would every day recommend UEFI instead of U-Boat to get something that looks more like a computer, not a dev board. I appreciate I'm not... Other people would disagree, but I don't agree with that. Other people would disagree, but that's my personal recommendation. With my U-Boat maintainer hat on, there's a world of difference. There's this thing called mainline U-Boat, and then there's all of this other stuff that forked off of it, and most of the problems are in all of that other stuff, which is essentially unfixable. The machine I'm currently using myself, I went out and spent $500 on a machine is a Macchiato bin, which uses Marvel's next generation CPU, which is ARM64, is clearly going to be in the core world, maybe the next generation of NAS boxes, and it does networking acceleration and whatever as well. It's got a couple of 10 gigabyte ethernet ports on board, it's got, in fact, six separate ethernet connectors on board, you can't use them all at once. It supports 16 gig of RAM, it comes with U-Boat, but there's UEFI port we're actively working on. It has a PCI slot that almost works. It's a quad-cork ARM Cortex A72, which is plenty of horsepower, and it's got all of the bits you'd want. I said, unfortunately, the PCI is quite broken, and that is a limiting factor. If you don't care about the PCI, you just want a computer that basically works. It's got three SATA ports on it, and whatever, it's got USB. It's actually the machine I tested for the first time ever. I tested the Stretch 9.0 and 9.1 releases on anorm 64 box that I owned in my own home on the day of release, and it worked well. It's the Macchiato bin. It started off as a... Yes, in fact, that's a good point. I have the gobby. I hope that some nice people have been updating this as we go. Also on the U-Boat topic, some machines that we cannot upgrade to Stretch because you would want that. So that's how it's spelled, Macchiato bin. There's also the Espresso bin, which is another Marvell-based small machine. It's only dual core. It's a bit more limited. I said, the Macchiato bin, there's been a number of us who bought these. We were hoping to be able to put it into... I put mine into a little mini-ITX case. We were hoping to be able to plug in a small graphics card and actually have a proper on 64 desktop for reasonable money, but without working PCIe, that's hard. As it is, as a box I can just leave running on my home network, I actually do have something that is reliable and not bad. Of course, if you want everything to work, you will need a kernel newer than Stretch, such as life when you're running on machines that are still actively developed every week, is running a Debian stable release is hard. Other machines that I know a lot of people have, the Pine 64, is... I mentioned earlier about the mobile platform. Again, that's a mobile SOC that they've put onto a board with... are the half a gig, one gig or two gig of RAM, on the version you got. It's almost all upstream at this point. Andre, one of our kernel hackers in ARM, is doing a lot of this stuff on his own time because he wants to make it work. They now have the U-boot that pretends to be UEFI, running on that very well, to the point where he was chasing me wondering why the Debian ARM 64 net instance didn't work on it at the box. We're finding bugs and fixing them as we go. You will probably need to run a back port kernel if you want some of these machines to work well. In some cases, absolutely, if you want all of it to work, you're going to be needing to run an upstream kernel rather than anything in back ports even, but of course, that will improve over time. Yeah, I can speak. I've got a number of ARM 64 boards in the build farm. The Jetson TX1 is pretty good, but you need to patch the device tree and get a patch that hasn't yet landed in mainline for SATA, but otherwise basically runs Debian kernel. There's the Odroid C2, which I've had some troubles with, but working on it. If people can put some of these into the Gobi as well, that would be lovely so we can list them later. The fun we always have is exactly this, and I knew it was going to come, so thank you, Thomas, is always, what board should I buy? I'd want something that works. It's much harder than it should be, and I apologise for that. Steve, do you know something, what's the current status of the big endian port or ILP, is that being developed or what's going on? Sure, we have one minute remaining, so I can quickly say, forget they ever existed, please. People have a number of times done lots and lots of other ports on ARM hardware. ARM hardware is, by design, endian neutral. You can run it either way, little endian or big endian. The default has always been little endian. What we've had Army B in Debian years ago, for the sake of the slug, I won't go into details, it's years ago, we also have people, I've worked on this myself, running a big endian ARM port on V7. There is also, on ARM64, there is a port Wookie is working on right now in Lenovo, ARM64 ILP32. It is not going to go into Debian. I am quite adamant on that. It is utterly pointless as a day-to-day thing for Debian users, so let's not spend any time on it. There is a big endian version of that too. It's complicated. Imagine X32 but on ARM64 instead of X8664 is exactly what it is. The reason that X32 has claimed uses, I've never wanted myself to agree or disagree much, is that you get a significantly bigger number of registers than you do on I386. You're not register-starved, you get better performance, and you're using 32-bit pointers so you don't use as much memory in typical code. X32 should have a win on benchmarks. I've never seen any convincing numbers. Admittedly I've not looked hard. ARM64 ILP32 is exactly the same thing. It's a 32-bit pointer ABI running on 64-bit hardware, with 64-bit instructions. It is not the same as A32, which is the 32-bit ISA that is standard on ARM. They're not at all binary compatible, but they're claiming that it will make porting your 32-bit code to ARM64 easier if you don't know how to port code, essentially. That's exactly it. Run your 32-bit code in 32-bit rather than port it properly. Jolych, grab a mic. Just as a remark on X8664, there is actually a true performance gain. If you use Intel's own C++ compiler, it has this flag which does auto ILP32. It analyzes the code and it will just generate X32 code. We can see that on the build these. It is quite fast, but as you said... How much for difference do you see? Do you have a percentage? Obviously, it depends on the code you want. It can be up to 50%. I've seen people talking about maybe 5% in typical code, at which point I don't think it's worth it. ILP32 on ARM64 gives you smaller memory usage so you should get better cache life. The other thing is, it also does extend you from the 16 registers on A32 up to the 31 registers available on ARM64. To be honest, with 16, you're not registered staffed on almost any code that's sensible anyway. Unless you're doing hand-optimised assembly, you're never going to notice. We don't see the same performance improvement for ILP32 that you might on X32. I don't think it's worthwhile any of the general purpose distros caring about this in any way. ARM64 with 64-bit use it. Is my take? Other people will argue, I think they won't. Unless anybody has any last points, we have just overrun by a couple of minutes. Maybe the last one will not care about RML in this room. I want to know what specific work needs to be done to still include the RML in Buster stage. We need people to basically pick up on bug reports as they happen if they are RML specific. They tend to be quite rare because most of people running RML don't tend to file bugs. I do. We need people to get involved in the tool chain areas and make sure that things continue to work. Deal with issues as they arise. Upstream folks and the tool chain people in particular have been pushing us for quite a long time saying they don't want to support this anymore. You'll need to talk to them to find the exact details. I will admit I ceased caring a while ago, so I've stopped tracking it, I'm afraid. Mention on the... If you want to get involved and make RML continue, please announce that on the Debian Arm List. Make a point of looking for the bugs and talking to people and go from there. We haven't taken it out of Buster yet, but we will soon, unless we see that happen. Okay? Now that really is past time. Thank you for coming along. As I said, I will send us somewhere to the list later. Please, if you want to get involved, get involved. We're friendly, we don't bite much. Thank you.