On Thu, Dec 28, 2017 at 10:08:59PM +0100, Lennart Poettering wrote: > On Do, 28.12.17 20:26, Reindl Harald (h.rei...@thelounge.net) wrote: > > > > > > > Am 28.12.2017 um 20:07 schrieb tedheadster: > > > I am doing regression testing on old hardware. systemd-233 just > > > generated the following error on startup: > > > > > > I believe it is getting an illegal instruction trap on this first > > > generation 486 because it is calling "cpuid" in detect_vm_cpuid() > > > without first checking if the hardware supports it; it doesn't in this > > > case. > > > > > > The gcc compiler provides a workaround in the cpuid.h header file. You > > > can call __get_cpuid_max() first and check the return value > 0. > > > > > > https://stackoverflow.com/questions/14266772/how-do-i-call-cpuid-in-linux#14266932 > > > > > > The Linux kernel still supports the 486 so we have to code around this > > > case, even if it is ancient hardware > > > > don't get me wrong - i am for 15 years now in the IT and my first PC in 1999 > > was a i686 > > > > i don't see how a brand new systemd and a mordern userland is supposed to > > run on 20 years or older hardware where nearly eveyr distribution these days > > is i586 or i686 only or starts to drop 32bit at all > > Well, we carry compat code for m68k, hence I figure i486 support > should be OK to have, too. I figure m68k processors are even more > legacy than i486 is, and certainly require more porting work than i486 > does, hence i486 support should be fine to have by a long shot. >
Additionally Intel was still manufacturing 386 and 486 chips as recently as 2007 [1]. Why not maintain support for such systems? It shouldn't be a substantial burden with a codebase that already supports 32-bit in general. Regards, Vito Caputo [1] https://www.theregister.co.uk/2006/05/18/intel_cans_386_486_960_cpus/ _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
