From sacadmin Tue May 9 12:53:42 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.226.31]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k49JrfAg024627 for ; Tue, 9 May 2006 12:53:41 -0700 (PDT) Received: from [129.146.226.100] (chaz.SFBay.Sun.COM [129.146.226.100]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k49JrfMe661690; Tue, 9 May 2006 12:53:41 -0700 (PDT) Message-ID: <4460F334.3010101@eng.sun.com> Date: Tue, 09 May 2006 12:53:24 -0700 From: Rod Evans Reply-To: Rod.Evans@sun.com Organization: Sun Microsystems, Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060221 X-Accept-Language: en-us, en MIME-Version: 1.0 To: psarc@sac.sfbay.sun.com, Ali Bahrami Subject: 2006/309: crle(1) configuration file format change Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 4184 I'm sponsoring the following case for Ali Bahrami. This case qualifies for Architectural self-review, but we wish to record the following information. ----------------------------------------------------------------------- This is a request to change the format of linker configuration files in a backward compatible manner. The CR in question is: 6174390 crle configuration files are inconsistent across platforms The crle(1) command creates linking configuration files. These files contain platform specific binary data. Ideally, the runtime linker would be able to determine the platform that created a given configuration file, compare it to the current system, and refuse to use a file that is not compatible. However, the pre-existing linker configuration file format does not include the necessary system identification data (ELFCLASS, byte ordering, machine type) necessary to do this. We have gotten away with this so far, because 32 and 64-bit sparc happen to align structures in an identical fashion, and because people have not tended to copy configuration files between systems with opposite byte ordering. However, 32 and 64-bit X86 do not use the same structure alignment rules. Plus, as our X86 installed base grows, the odds of copying configuration files between sparc and X86 grows with it. Good luck not withstanding, we are not exerting the necessary level of control and validation on these files. Finally, I note that the file(1) command is currently unable to identify linking configuration files, reporting them as "data". Ideally, it should tell you that it is a linking config file, and it should tell you what platform it applies to, in the same manner that it can identify ELF objects and executables. My solution to CR 6174390 sets out to resolve these issues. crle adds the necessary information to new configuration files, in a header block containing platform (ELFCLASS, byteorder, machine type) information. The approach is the same used with ELF objects: A magic number, followed by the necessary information, in a format readable on any system. The header block is guaranteed to always be exactly 16 bytes in size, and the remainder of the file is identical to the output produced by previous versions of crle. This makes it easy to provide backward compatible behavior when a file in the old format is copied to a new Solaris system. If a configuration file has the header, the runtime linker will use it to validate the file. If the header is not present, the file is used in the usual way. Eventually, the old format will die away, as the new one supersedes it. The modified file(1) command uses this new information to provide helpful information, much as it does with ELF objects: % file ld.config.1 ld.config.1: Runtime Linker Configuration 64-bit LSB AMD64 instead of the current behavior: % file ld.config.1 ld.config.1: data To summarize: - Backwards compatible: Old files continue to work on new releases of Solaris. - Prevents incorrect behavior caused by attempts to use a configuration file generated by an incompatible platform. - Allows better user level information. There is one incompatible aspect to this scheme. It does not allow for "downrev" operation. A file generated by a new version of crle, and then copied to a Solaris system running an old version that does not understand the new identification header block, will not have the desired effect: - The runtime linker will not recognize it as a valid file, and will quietly ignore it. - The crle(1) command will misinterpret it, and will in all likelyhood crash trying to update it. (This is in fact, a bug in crle, that I have fixed as part of this putback. Crle should refuse to process a file it can't understand). We do not support downrev operation of binary components in Solaris, so this incompatibility should be OK. However, it is easy enough to convert a new format file into the old format, as it suffices to strip 16 bytes from the start of the file: % dd ibs=16 skip=1 if=ld.config.new of=ld.config.old ----------------------------------------------------------------------- -- Rod. From sacadmin Tue May 9 13:09:17 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.226.31]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k49K9HdJ025877 for ; Tue, 9 May 2006 13:09:17 -0700 (PDT) Received: from [129.146.226.100] (chaz.SFBay.Sun.COM [129.146.226.100]) by jurassic.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k49K9H1h686387; Tue, 9 May 2006 13:09:17 -0700 (PDT) Message-ID: <4460F6DC.9050801@eng.sun.com> Date: Tue, 09 May 2006 13:09:00 -0700 From: Rod Evans Reply-To: Rod.Evans@sun.com Organization: Sun Microsystems, Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060221 X-Accept-Language: en-us, en MIME-Version: 1.0 To: psarc@sac.sfbay.sun.com, ali.bahrami@sun.com Subject: 2006/309: crle(1) configuration file format change Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 205 Opps, forgot: ----------------------------------------------------------------------- Configuration file change release binding: micro Configuration file contents stability: private -- Rod.