GNU C Library Lands Year 2038 Handling For Legacy ABIs

[oiaohm]

The big electronics vendors -- Mouser, Digikey, etc -- have a ton of new stock of oldschool CPUs, like 8086s, etc. In the embedded world, nothing ever really dies, so there's a consistent, albeit small, demand for processors made decades ago. While they themselves don't run Linux, my example of 8086/8088 was more towards the "what design still gets used after 18 years" remark. The fancy embedded Linux designs of today are almost certainly going to become someone's legacy headache decades from now, given a lot of more recent elevators, like Kone's DX line, do have embedded Linux running various bits and pieces of electronics.

The reality is Mouser, Digikey.... don't really have large stocks of oldschool CPUs this comes clear if you attempt to order like 1000 to make a new product using them. There was a percentage of the production of lot of those old processor that was ear marked from new from repair usage what we are currently eating our way though and you find this out when you attempt todo a big order of them and the question is do you really have that many old devices to fix and if say you will be making something new you get a polite answer say sorry we will not sell those chips to you as they are ear marked for repair usage only.

We don't have the same government supply contracts any more like why we had so many early 8086 clones was that to supply back in time to the USA and UK armed forces you use have required 3 totally independent production of parts and a stockpile of parts put aside for repairs this is what has created a lot of the oldschool CPUs you can still buy new and they are really under contract to be supplied to those doing repairs not making new products. The right to repair back then was part of doing business and resulted is the cause of the existing stock pile that is currently be consumed.

Please note ELKS( The Embeddable Linux Kernel System) only supports "Intel IA16 architecture (16-bit processors: 8086, 8088, 80188, 80186, 80286, NEC V20, V30 and compatibles)." There are still new embedded systems being made using ELKS most are using FPGA implementations of 8086 not the historic asic chips. Please note ELKS is not the only OS that is being used embedded today on 8 and 16 bit only CPUs that are FPGA implemented.

Really there are a lot of embedded systems that have current date and time that I am not looking for to the year 2038. Quite a few in the year 2038 will still be 8 and 16 bit systems. Of course the Linux 32 bit systems will still be around by then as well. We are not going to be 100% 64 bit by 2038.

[torsionbar28]

This is also another case where if their controller goes stupid the result could be dead people. The stuff exceeding 18 years is mostly the more dangerous stuff.

That's why these things are designed to fail in a safe manner. For example, when traffic light controllers fail, the signals all show flashing red (or red in one direction, amber in the other). There is never a case where a traffic light controller will fail dangerously e.g. showing green in all directions. The testing and validation required for public safety systems is extensive, and represents a significant part of the system cost. This is true for anything safety related e.g. aircraft, power generation, etc.

Satellites in orbit are similar, they are designed to "fail dumb" i.e. they fail into a state where they are ready to accept fresh code, so that they can be reprogrammed from Earth. As expensive as it is to launch a satellite, it is *far* more expensive to put a man on it for hands-on repair.

[oiaohm]

That's why these things are designed to fail in a safe manner. For example, when traffic light controllers fail, the signals all show flashing red (or red in one direction, amber in the other). There is never a case where a traffic light controller will fail dangerously e.g. showing green in all directions. The testing and validation required for public safety systems is extensive, and represents a significant part of the system cost. This is true for anything safety related e.g. aircraft, power generation, etc.

Sorry to break you bubble that depends on the countries regulation how they should fail . Australia where I am traffic light controller are meant to fail to amber in all directions to start off with. So we don't have universal global standard on how traffic light controllers should fail yes there are countries that laws say red in one direction and amber in the other then others that say failure should be flashing red there are others that say all black if failed. Good start would be a global standard on traffic lights how they should fail.

Please note a multifunctional functional traffic light controller fail all green https://www.embedded.com/how-can-tra...ail-all-green/ has happened in the real world with these new micro controller controlled traffic lights as are not using hard logic. Yes this failure is failure with solid green on yes has caused deaths from car and a truck driving in and hitting each other. The problem here is the validation of traffic lights the validation in most countries does not demand that electrically that all green is impossible. Yes this goes back to the days when we moved from hardware to programmed EPROM but people configuring the EPROM were way more careful not to make this stupidity and the EPROM was simple to validate than C code running in a micro controller for all the possible states of the lights.

There have also been examples in power generation were fail safe has been missing and the system been able to pass government regulations please note this is the same path as what has created dangerous traffic lights where systems have not been regulated to be hard wire design any more for moved to eprom then latter move micro-controller leading to something quite dangerous in fact due to how hard to totally audit all the states a micro-controller can end up in is. Aircraft and Satellites there have been some that are missing correct fail safe but all of these are in fact against regulations and traces to some party bypassing the legal requirement to have their work validated.

torsionbar28 you are not alone in thinking that traffic lights and other systems cannot fail dangerously because there is no way that governments would allow it problem is this is not true. There are many other civil embedded systems that can be life threatening as well that when you look closer at the validation are really not up to safety standard that we should tolerate and those systems do pass validation even that they have a fail unsafe mode.

[torsionbar28]

Sorry to break you bubble that depends on the countries regulation how they should fail . Australia where I am traffic light controller are meant to fail to amber in all directions to start off with. So we don't have universal global standard on how traffic light controllers should fail yes there are countries that laws say red in one direction and amber in the other then others that say failure should be flashing red there are others that say all black if failed. Good start would be a global standard on traffic lights how they should fail.

The fail-safe mode is irrelevant, of course it will be different depending on jurisdiction, as it should be. The point is, these devices have been designed to account for the possibility of failure, and have been designed to fail into a mode that is acceptable. There are no doubt some odd corner cases where it doesn't work as intended, but lots of effort has been expended to try and ensure a sane failure mode.

torsionbar28 you are not alone in thinking that traffic lights and other systems cannot fail dangerously because there is no way that governments would allow it problem is this is not true.

I said they were designed not to. Anything designed and built by humans has the possibility of error. There is a saying, "man makes plans, and God laughs". It means that despite the best intentions, and the most careful planning, things do not always go according to plan.

[oiaohm]

The fail-safe mode is irrelevant, of course it will be different depending on jurisdiction, as it should be. The point is, these devices have been designed to account for the possibility of failure, and have been designed to fail into a mode that is acceptable. There are no doubt some odd corner cases where it doesn't work as intended, but lots of effort has been expended to try and ensure a sane failure mode.

The reality this is no. There is a vendor that inside the traffic controller box is nothing more than a off the shelf androno board with a off the shelf relay board. There is another group for advance traffic control looking at use basically off the shelf raspberry pi. There are other that are just other standardish industrial controllers.

The reality here with lot of these devices we are purely depending on the software to-do the right thing. This software is user reconfigurable without a easy sure fire way to check that its right.

I said they were designed not to. Anything designed and built by humans has the possibility of error. There is a saying, "man makes plans, and God laughs". It means that despite the best intentions, and the most careful planning, things do not always go according to plan.

This is true but humans can take short cuts and human does not have to design something to properly safe they can skip out on it. The reality like it or not there is a lot of cases where generic hardware is being used instead of custom designed hardware to save on cost but this also comes at the cost of lower safety features and being harder for the end user to audit that they have it configured right leading to fatalities.

Careful planning you would have eeprom/s or eprom/s with all the mode the lights can enter in it with this is the old school method. Another method that costs a bit of hardware its to put a hard logic system on all the green outputs that if over a particular number go green the complete box fails. The reason why modern day traffic light systems can go all green is that you are depending 100 percent on software and controller recycled from some other market not designed at all to be a traffic light controller. These are not really designed at all to take correct account for the possibility of failure causing life endangering events but are a cost saving short cut.