| Summary: | Fix to allow falsified cpu information in /proc/cpuinfo | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Mark Hobley <markhobley> |
| Component: | [OLD] baselayout | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | enhancement | CC: | coldwind |
| Priority: | Low | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| URL: | http://markhobley.yi.org:8000/cpufalsification | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
And exactly why should anyone want this? What specific issues does it fix? This may be a good hack for something, but I doubt we want to add this as a feature. Moreover, we will eventually migrate to openrc/baselayout-2, where /sbin/rc is not a script anymore, so you may write a patch for openrc and try to persuade Uberlord to include it. If you really want this feature officially supported in Gentoo, reopen the bug and explain how this is useful and why should it be included. Thanks for reporting. (In reply to comment #1) > And exactly why should anyone want this? What specific issues does it fix? > This patch addresses issues with backwards incompatibility with operation and compilation between machines, when files are being shared by older generation machines on a network. This patch provides "lowest common denominator" infrastructure by masking machine specific extended architecture, that is not available on other target machines. This is desirable, if a fast i686 machine is being used to compile programs for i586 or i486 machines, and prevents i686 specifics being included in the resultant executables. This is useful for use in organizations, where it is policy to use the same code across all machines, and allows newer machines with later generation processors to be implemented together as compatible with existing architecture, rather than being treated as new and separate architecture. Effectively, this patch (together with a series of other patches), allows an i686 machine to emulate a fast i486 machine, without the need for virtual machine emulation, and alleviates the need for cross compilation. Mark. (In reply to comment #3) > This patch addresses issues with backwards incompatibility with operation and > compilation between machines, when files are being shared by older generation > machines on a network. > > This patch provides "lowest common denominator" infrastructure by masking > machine specific extended architecture, that is not available on other target > machines. > > This is desirable, if a fast i686 machine is being used to compile programs for > i586 or i486 machines, and prevents i686 specifics being included in the > resultant executables. > > This is useful for use in organizations, where it is policy to use the same > code across all machines, and allows newer machines with later generation > processors to be implemented together as compatible with existing architecture, > rather than being treated as new and separate architecture. > > Effectively, this patch (together with a series of other patches), allows an > i686 machine to emulate a fast i486 machine, without the need for virtual > machine emulation, and alleviates the need for cross compilation. I see. Thanks for taking the time to explain. Still, I think that cross compilation was designed to address the very topics that you are making... Moreover, I understood things that backwards compatibility within the x86 architecture already allows 486, 586 and 686 CPUs to run a system with a lowest denominator 386 CHOST specification, meaning that all 386 machines will be able to run code generated by such systems, so why is there a palpable need to fake this? Maybe I'm dense, but isn't this a bit like re-inventing the wheel? I can see a certain amount of use in trying to see how certain packages would behave on [faked machine] when you haven't actually got one to try, but then again... I'd say that any code that bases it's optimizations on the contents of /proc/cpuinfo just by default is fundamentally broken. Yes, it should be an option to do so, (see -march=native in recent GCC versions), but the default in Gentoo should always be something suitable for all machines if CFLAGS does not specify anything more specific to the machine. (In reply to comment #4) > Still, I think that cross compilation was designed to address the very topics > that you are making... This is an added complication. If the architecture is compatible, then you are not really cross compiling. > Moreover, I understood things that backwards > compatibility within the x86 architecture already allows 486, 586 and 686 CPUs > to run a system with a lowest denominator 386 CHOST specification That is correct, as long as CHOST is set to 386. The problem arises when CHOST gets set to 686, as a result of the build machine identifying itself as an i686. > all 386 machines will be able to run code generated by such systems, so why is > there a palpable need to fake this? Build scripts may detect the host as a i686, and compile for an i686, rather than using the 386 instruction set. I think that it is really bad build tool and compiler design to assume that the target machine has the same generation processor as the build machine, and has the same processor specific extensions. It would have been better to default to a generic 386, unless switches indicate otherwise. The cpu detection tools are over-utilized IMHO, and I would like to see a kernel build option to create a falsified generic cpu related information. Relating to this bug, don't forget I have already provided a patch for the script. Also, the modification makes no changes to the scripts behaviour, unless /etc/cpuinfo is created, so the modified scripts are backwards compatible with the existing scripts. > Maybe I'm dense, but isn't this a bit like re-inventing the wheel? I can see a > certain amount of use in trying to see how certain packages would behave on > [faked machine] when you haven't actually got one to try I have implemented cpuinfo falsification locally and I will be testing that here. i dont see how what you're doing requires such early modification. put it into your local/local.start script. |
This fix allows falsified cpu information in /proc/cpuinfo, by creating an override file /etc/cpuinfo. The following changes apply to the /sbin/rc script: check_statedir /proc ebegin "Mounting proc at /proc" if [[ ${RC_USE_FSTAB} = "yes" ]] ; then mntcmd=$(get_mount_fstab /proc) else unset mntcmd fi try mount -n ${mntcmd:--t proc proc /proc -o noexec,nosuid,nodev} eend $? # Override /proc/cpuinfo with falsified information, if required if [ -e /etc/cpuinfo] ; then mount --bind /etc/cpuinfo /proc/cpuinfo fi # Start profiling init now we have /proc profiling start