Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
ByDonaldFischer
Abstract
TheRedHatEnterpriseLinuxproductfamilyprovidesa powerful,stableplatformforthirdpartysoftwareapplication developers.Thisdocumentdescribesthedifferenttypesof compatibilityguaranteesthatareavailabletoapplication developersbuildingsoftwareforRedHatEnterpriseLinux ononeormorehardwarearchitectures.Italsoprovides guidancetodevelopersonbestpracticesthatshouldbe followedinordertoensureapplicationcompatibilitywith futurereleasesofRedHatEnterpriseLinux.Finally,it summarizesthecompatibilitypoliciesfollowedbyRedHat withinandbetweenmajorreleasesoftheRedHat EnterpriseLinuxplatform.
February2005
Copyright2005RedHat,Inc.Allrightsreserved.RedHatandtheShadowmanlogoareregisteredtrademarksofRedHat,Inc.intheUSandothercountries.Linuxisa registeredtrademarkofLinusTorvalds.Allothertrademarksreferencedhereinarethetrademarksoftheirrespectiveowners.WHP73870US02/05
TableofContents
TypesofCompatibility......................................................................................3 ApplicationCompatibility...................................................................................3 SourceApplicationCompatibility..................................................................3 BinaryApplicationCompatibility..................................................................5 HardwareArchitectureCompatibility.................................................................6 SingleArchitecturePlatforms.......................................................................6 MultipleArchitecturePlatforms....................................................................6 ConfigurationandDataFileCompatibility.........................................................8 ConfigurationFiles........................................................................................8 DataFiles......................................................................................................8 DesigningSoftwareforCompatibility...............................................................10 UseofSystemLibraries...............................................................................10 CoreLibraries...............................................................................................10 NonCoreLibraries.......................................................................................10 Packaging.....................................................................................................11 TheFileHierarchyStandard........................................................................11 SecurityEnhancedLinux.............................................................................11 RedHatEnterpriseLinuxCompatibilityPolicies...............................................11 CompatibilityWithinAMajorRelease..........................................................11 CompatibilityBetweenMajorReleases.......................................................12
RedHatEnterpriseLinux4ApplicationCompatibility
TypesofCompatibility
TherearemultipleaspectsofcompatibilityforRedHatEnterpriseLinux:
ApplicationCompatibility
Applicationcompatibilityspecifiestheportabilityofapplicationsourcecode andcompiledapplicationbinariesacrossdifferentinstancesofacomputer operatingenvironment. Applicationcompatibilitycanbebrokendownintotwobroadcategories:
RedHat's definitionofsourcecompatibilityAPIsandbinarycompatibilityABIs issuchthatthereisacontractbetweentheapplicationandRedHat EnterpriseLinuxoperatingenvironment.Thedifferencebetweensource compatibilityAPIsandbinarycompatibilityABIsiswherethecontractis enforcedatcompiletimeorruntime. SourceApplicationCompatibility Sourcecompatibilityenablesabodyofapplicationsourcecodetobe compiledandoperatecorrectlyonmultipleinstancesofanoperating environment,acrossoneormorehardwarearchitectures,aslongasthe sourcecodeiscompiledindividuallyforeachspecifichardwarearchitecture. (Notethatsomeplatformssupportmorethanonehardwarearchitecture,as discussedlaterinsectionMultipleArchitecturePlatforms). SourcecompatibilityisdefinedbyanApplicationProgrammingInterface(API), whichisasetofprogramminginterfacesanddatastructureswhichare providedtoapplicationdevelopers.ForClikelanguages,theprogramming syntaxofAPIsaredefinedinheaderfilesthatspecifydatatypesand programmaticfunctionsimplementedbytheoperatingsystemorlibrariesand madeavailabletoprogrammersforuseintheirapplications.Thesyntaxof APIsareenforcedatcompiletime,orwhentheapplicationsourcecodeis compiledtoproduceexecutablebinaryobjectcode. SourcecompatibilityAPIsareclassifiedas:
RedHatEnterpriseLinux4ApplicationCompatibility
RedHatEnterpriseLinuxprovidesbackwardscompatibilitywithdefacto standardsforcoresystemcomponentswhereverpossible.Thismeansthat anapplicationbuiltononemajorreleaseofRedHatEnterpriseLinuxwill continuetoworkthroughouttheproductlifecycleonsubsequentupdatesof thatmajorreleaseandonthenextmajorreleaseofRedHatEnterpriseLinux aswell.Forexample,applicationsthatarearecompiledwithheaderfilesand linkedtoaparticularversionofglibc,theGNUCLibrary,areintendedto continuetoworkwithlaterversionsofglibc.Forthecaseofglibc,thisis accomplishedbyprovidingversionedsymbols,whosesyntaxandsemantics arepreservedinsubsequentreleasesofthelibraryevenifanew,otherwise incompatibleimplementationisadded.Forothercoresystemcomponents, suchasall2.xreleasesoftheGTK+toolkit,backwardscompatibilityis ensuredsimplybylimitingchanges,whichpreservethesyntaxandsemantics ofthedefinedAPIs.Inmanycases,multipleversionsofaparticularlibrary maybeinstalledonasinglesystematthesametimetosupportdifferent versionsofanAPI.AnexampleistheinclusionofbothBerkeleyDatabase (db)version4.2.52andversion4.1.25inRedHatEnterpriseLinux4,each withitsownsetofheadersandlibraries. Inallcases,applicationdevelopersshouldseektoensurethatanybehavior theydependonisdescribedinformalAPIdocumentation,soastoavoid introducingdependenciesonunspecifiedimplementationspecificsemanticsor evenintroducingdependenciesonbugsinaparticularimplementationofan API.Forexample,newreleasesoftheGNUClibraryarenotguaranteedto becompatiblewitholderreleasesiftheoldbehaviorviolatedaspecification. RedHatEnterpriseLinuxbyandlargeseekstoimplementsource compatibilitywithavarietyofdejureindustrystandardsdevelopedforUnix operatingenvironments.WhileRedHatEnterpriseLinuxdoesnotfully conformtoallaspectsofthesestandards,thestandardsdocumentsdo provideadefinedsetofinterfaces,andmanycomponentsofRedHat EnterpriseLinuxtrackcompliancewiththem(particularlyglibc,theGNUC Library,andgcc,theGNUC/C++/Java/FortranCompiler).Thereareandwill becertainaspectsofthestandardswhicharenotimplementedasrequiredon Linux. AkeysetofstandardsthatRedHatseekstoconformwitharethosedefined bytheAustinCommonStandardsRevisionGroup(TheAustinGroup). TheAustinGroupisaworkinggroupformedin1998withtheaimofunifying earlierUnixstandardizationeffortsincludingISO/IEC99451and99452, IEEEStandards1003.1and1003.2(POSIX),andTheOpenGroup's Single UnixSpecification.ThegoalofTheAustinGroupistounifythePOSIX,ISO, andSUSstandardsintoasinglesetofconsistentstandards.TheAustin GroupincludesmembersfromTheOpenGroup,ISO,IEEE,majorUnix vendors,andtheopensourcecommunity. ThecombinedstandardsissuedbyTheAustinGroupcarryboththeIEEE POSIXdesignationandTheOpenGroup's TechnicalStandarddesignation, andinthefuturetheISO/IECdesignation.
RedHatEnterpriseLinux4ApplicationCompatibility 4
MoreinformationonTheAustinGroupisavailableat http://www.opengroup.com/austin. BinaryApplicationCompatibility Binarycompatibilityenablesasinglecompiledapplicationbinarytooperate correctlyonmultipleinstancesofanoperatingenvironmentthatsharea commonhardwarearchitecture(whetherthatarchitecturesupportis implementedinnativehardwareoravirtualizationlayer). BinarycompatibilityisdefinedbyanApplicationBinaryInterface(ABI).The ABIisasetofruntimeconventionsadheredtobyalltoolswhichdealwitha compiledbinaryrepresentationofaprogram.Examplesofsuchtoolsinclude compilers,linkers,runtimelibraries,andtheoperatingsystemitself.TheABI includesnotonlythebinaryfileformats,butalsothesemanticsoflibrary functionswhichareusedbyapplications. Similartothecaseofsourcecompatibility,binarycompatibilityABIscanbe classifiedintothefollowing:
ApplicationBinaryInterfacesspecifiedbytheGNUC,C++,FortanandJava Compilerincludethefollowing:
Callingconventions,whichspecifyhowargumentsarepassedtofunctions andhowresultsarereturnedfromfunctions. Registerusageconventions,whichspecifyhowprocessorregistersare allocatedandused. Objectfileformats,whichspecifytherepresentationofbinaryobjectcode. Size,layout,andalignmentofdatatypes,whichspecifieshowdataislaid outinmemory. Interfacesprovidedbytheruntimeenvironment,whichmustbeavailable usingthesamenameatalltimesandwherethedocumentedsemanticsdo notchangefromoneversiontoanother
Inaddition,theApplicationBinaryInterfacefortheGNUC++Compiler specifiesthebinaryinterfacesforthefollowingC++languagefeatures:
HardwareArchitectureCompatibility
SingleArchitecturePlatforms Forapplicationsthatconformtospecifiedinterfaces,binary(ABI)compatibility isprovidedforallapplicationswithinasinglehardwarearchitecture.This meansthatapplicationdevelopersdonotneedtomodifysoftwaretorunon systemsfromdifferentvendors,orwithdifferenthardwareconfigurations,as longastheyshareacommonhardwarearchitectureandthesoftwaredoesnot unconditionallyusefunctionalityofthearchitecturewhichisnotuniversally available(suchasspecialinstructionswhichareavailableononlysome processormodels). Forexample,applicationscompiledforRedHatEnterpriseLinuxfortheIBM iSeriesandpSeriesbrandedsystemsaresupportedonIBMPOWERbranded systemswithPOWER5processorsbecausetheysharethesamehardware architecture(ppc/ppc64). Similarly,applicationscompiledforRedHatEnterpriseLinuxfortheAMD64 architecturearesupportedonIntelEM64Tsystemsandviceversabecause theysharethesamehardwarearchitecture(x8664). Conversely,applicationbinariescompiledforonehardwarearchitecture typicallywillnotrunonotherhardwarearchitectures.Forexample,an applicationbinarycompiledfortheIntelItanium2architecturewillnotrunonan IBMPOWERsystem.TheexceptiontothisruleisthatRedHatEnterprise Linuxofferssupportforacompatibilityruntimeenvironmentonsomehardware architecturesasdiscussedinthenextsection. RedHatEnterpriseLinuxsupportsabroadrangeofhardwareplatformsfrom multiplevendorsacrossseveralhardwarearchitectures.Hardwareplatforms thathavebeencertifiedtorunonRedHatEnterpriseLinuxaredescribedon theRedHatHardwareCompatibilityList(HCL),availableat http://hardware.redhat.com/hcl. MultipleArchitecturePlatforms RedHatEnterpriseLinuxoffersnativesupportforabroadrangeofhardware architectures,including32bitand64bitarchitectures.Forsomeofthe supportedplatforms,bothanativehardwarearchitectureandacompatibility hardwarearchitectureruntimeenvironmentaresupported. ForeachnativearchitecturesupportedbyRedHatEnterpriseLinux,Table1 indicates:
RedHatEnterpriseLinux4ApplicationCompatibility 6
Table1:NativeArchitectureSupport
Architecture 32bitx86 64bitAMD64 andIntel EM64T 64bitIntel Itanium2 64bitIBM POWER 31bitIBM S/390 Mainframe 64bitIBM zSeries Mainframe
Native Userspace 32bitx86 (.i386.rpm) 64bitx8664 (.x86_64.rpm) 64bitItanium2 (.ia64.rpm) 32bitPOWER (.ppc.rpm) 31bitS/390 (.s390.rpm) 64bitzSeries (.s390x.rpm)
Kernel 32bitx86
64bitx8664
64bitItanium2
64bitzSeries
ForthetheAMD64andIntelEM64Thardwarearchitectures,eitherthe32bit nativedistributionorthe64bitnativedistributioncantypicallybeinstalledona system.Whenthe64bitnativedistributionisinstalled,32bitapplication binariesaresupportedthroughthecompatibilityuserspace.Whenthe32bit nativedistributionisinstalled,only32bitbinariesaresupportedandnot64bit binaries. FortheIntelItanium2hardwarearchitecture,32bitx86applicationsupport requirestheuseofasoftwarepackagecalledtheIA32ExecutionLayer (IA32EL).TheIA32ELissuppliedbyRedHatasanRPMpackageonthe RedHatEnterpriseLinux4ExtrasCDandviaRedHatNetworkforthe Itanium2architectureonly. FortheIBMPOWERhardwarearchitecture,thedefaultuserspaceiscompiled forthe32bitPOWERhardwarearchitecture,andacompatibilityuserspaceis providedfor64bitnativeapplications.ThekernelfortheIBMPOWER
RedHatEnterpriseLinux4ApplicationCompatibility 7
architectureis64bitnative. InallofthecasesdepictedTable1,thecompatibilityuserspacecontainsa subsetofthesystemlibrariesandasubsetofLinuxdistributionapplicationsas comparedtothenativeuserspace.Thegoalofthecompatibilityuserspaceis toprovideabinarycompatibleapplicationruntimeenvironmentforthe specifiedarchitecture.Thecompatibilityuserspacedoesnotprovidea completeapplicationdevelopmentenvironment.Forbestresults,RedHat recommendsthatapplicationsbedevelopedandcompiledininanative hardwareenvironmentwheneverpossible,ratherthaninacompatibility environment.
ConfigurationandDataFileCompatibility
TheRedHatEnterpriseLinuxdistributioncontainsoverathousandindividual softwarepackages,whichimplementavarietyofdifferentsystemservicesand capabilities.Themajorityoftheseapplicationsaredevelopedbyactiveopen sourcedevelopercommunities,whosepoliciesandpracticesdiffer substantiallyfromonetothenext.Oneareainwhichcommunityprojectstend todifferistheircommitmenttopreservingconfigurationfileanddatafile formatsbetweenreleases. ConfigurationFiles ManyofthepackagesintheRedHatEnterpriseLinuxdistributionincludethe conceptofaconfigurationfilewhichspecifiesapplicationsettings,typicallyin anapplicationdefinedtextorbinarydataformat. Whereverpossible,RedHatseekstopreservethestabilityofconfigurationfile formatswithinamajorreleaseofRedHatEnterpriseLinux.Thismeansthat forexample,whenupdatingaparticularpackagefromRedHatEnterprise Linux4Update1toRedHatEnterpriseLinux4Update2,configurationfile customizationsmadebyauserorsystemadministratorshouldcontinueto functionasintendedwithoutmanualintervention. Thesameguaranteecannotbemadeforallpackagesforupgradesfromone majorreleasetoanother(forexample,fromRedHatEnterpriseLinux3toRed HatEnterpriseLinux4).Inthecaseofanautomatedupgradebetweenmajor releases,configurationfilesfromthepreviousreleasewilltypicallybe preserved,butmayrequiremanualadministratororuseradjustmenttowork correctlywiththeversionofthepackageinthenewermajorrelease,if configurationfileformatshavechangedforthatpackage. Applicationdevelopersareadvisedingeneralnottodependontheformatof configurationfilesusedbysystempackages,unlesstheconfigurationfilesare definedbyaspecificationandthecorrespondingupstreamcommunityproject hasexpressedacommitmenttosupportingthoseconfigurationfileformatsin allfuturereleases. DataFiles Similartothesituationwithconfigurationfiles,manypackagesintheRedHat EnterpriseLinuxdistributiondependondatafileswithaspecifictextorbinary datarepresentation.
RedHatEnterpriseLinux4ApplicationCompatibility
Whereverpossible,RedHatseekstopreservethestabilityofdatafileformats withinamajorreleaseofRedHatEnterpriseLinux.Thismeansthatfor example,whenupdatingaparticularpackagefromRedHatEnterpriseLinux4 Update1toRedHatEnterpriseLinux4Update2,datafilescreatedbyearlier revisionsofpackagesshouldcontinuetofunctionasexpected. Thesameguaranteecannotbemadeforupgradesfromonemajorreleaseto another(forexample,fromRedHatEnterpriseLinux3toRedHatEnterprise Linux4).Thesupportfordatafileformatsbetweenmajorreleasesistypically dependentonthedevelopmentpoliciesoftheupstreamopensource communityproject.Forsomepackages,datafileformatswillalwaysbe maintained.Forotherpackages,acompatibilitymodeisavailableforinter operatingwitholderdatafileformats.Finally,somepackageswill automaticallyupgradedatafilesfromanoldformattoanewformat. SomespecificexamplesforupgradesfromRedHatEnterpriseLinux3toRed HatEnterpriseLinux4areasfollows:
TheEvolutionmailandgroupwareclientandtheMozillaFirefoxweb browserwillautomaticallyupgradeuserconfigurationanddatafilesfrom earlierreleasestothemostrecentformat,thefirsttimetheyarerunfor eachuser. TheOpenOffice.orgofficesuiteincludessupportforreadingandwriting datafilescreatedbyearlierreleasesoftheofficesuite. Theformatofdatafilesusedbythekernelsystemcallauditing infrastructurehaschangedbetweenRedHatEnterpriseLinux3andRed HatEnterpriseLinux4duetothemigrationtoanewauditing implementationinthekernel.Thus,auditdatafilesandanalysistoolsfrom RedHatEnterpriseLinux3arenotautomaticallyinteroperablewiththose fromRedHatEnterpriseLinux4. Theformatoffilescreatedbythekernelinthe/procfilesystemisnot guaranteedacrossreleases,unlessotherwisespecifiedbythekernel documentation.Thelocationandformatofindividualfilesinthe/proc filesystemmayhavechangedbetweenRedHatEnterpriseLinux3and RedHatEnterpriseLinux4. DatabasecontentcreatedwithearlierreleasesofPostgreSQLcanbe migratedtothenewerreleasebydumpingthecontentsofthedatabaseto atextformatandthenimportingthetextfilesintoanewerrelease.
RedHatEnterpriseLinux4ApplicationCompatibility
DesigningSoftwareforCompatibility
UseofSystemLibraries TheRedHatEnterpriseLinuxdistributioncontainsoverathousandindividual softwarepackages,manyofwhichincludelibrariesthatareavailableto developersforstaticordynamiclinkingintoapplications. RedHatrecommendsthatapplicationdevelopersavoidstaticlinking wheneverpossible.Someofthedisadvantagesofstaticlinkingincludethe following:
Ifanapplicationcannotlimititselftotheinterfacesofthesecorelibraries,then toensurecompatibilityacrossmajorreleases,theapplicationshouldbundle theadditionalrequiredlibrariesaspartoftheapplicationitself.Inthatcase, thebundledlibrariesmustthemselvesuseonlytheinterfacesprovidedbythe corelibraries. NonCoreLibraries RedHatEnterpriseLinuxalsoincludesawiderangeoflibrarieswhoseAPIs andABIsarenotguaranteedtobepreservedbetweenmajorreleases. Compatibilityoftheselibrariesis,however,providedwithinamajorreleaseof thedistribution.Applicationsarefreetousethesenoncorelibraries,butto ensurecompatibilityacrossmajorreleases,applicationvendorsshouldprovide theirowncopiesofthesenoncorelibraries,whichinturnshoulddependonly onthecorelibrarieslistedintheprevioussection.
RedHatEnterpriseLinux4ApplicationCompatibility
10
AvoidusingRPMtriggerswheneverpossible. Don't dependontheexecutionorderofpreinstallorpreuninstallscripts, whichmaychangebetweenreleases. Explicitlystateallrequiredruntimeandbuilddependenciesusingthe appropriateRPMsyntax. Donotmodify,replace,orrecompilefilesmanagedbyRedHatprovided RPMpackages. Whenconsideringdependencies,don't assumethatallpossiblepackages willbeinstalledoneveryEnterpriseLinuxsystem.Thedefaultinstalled packagesmaychangebetweenreleases.
TheFileHierarchyStandard ApplicationsshouldfollowtheFilesystemHierarchyStandard(FHS)when installingfiles.Specifically,thirdpartysoftwareshouldinstalltoasubdirectory of/opt.MoreinformationontheFileHierarchyStandardisavailableat: http://www.pathname.com/fhs/2.2/ SecurityEnhancedLinux SecurityEnhancedLinux(SELinux)isanewcapabilityinRedHatEnterprise Linux4.SELinuxprovidesaMandatoryAccessControl(MAC)systemfor Linux,whichcanbeusedtocontrolaccesstosystemresourcesatafine grainedlevel. RedHatEnterpriseLinux4includesanSELinuxpolicyknownasthetargeted policythatrunsonlyaspecificsetofsystemservicesunderSELinux protection.Thetargetedpolicyisdesignedsothatitdoesnotimpactthe runtimebehaviorofthirdpartyapplications.Applicationdevelopersmayalso wishtoinvestigatethedevelopmentofSELinuxpoliciesfortheirapplications toensureadditionalenforcementofsecurityatapplicationruntime. MoreinformationontheSELinuximplementationinRedHatEnterpriseLinux 4isavailableat:http://fedora.redhat.com/projects/selinux/
RedHatEnterpriseLinuxCompatibilityPolicies
CompatibilityWithinAMajorRelease OneofthecoregoalsoftheRedHatEnterpriseLinuxfamilyofproductsisto provideastable,consistentruntimeenvironmentforthirdpartyapplications. Tosupportthisgoal,RedHatseekstopreserveapplicationbinary compatibility,configurationfilecompatibility,anddatafilecompatibilityforall
RedHatEnterpriseLinux4ApplicationCompatibility 11
packageupdatesissuedwithinamajorrelease. Forexample,apackageupdatefromRedHatEnterpriseLinux4Update1to RedHatEnterpriseLinuxUpdate2,orapackageupdatethatfixesan identifiedsecurityvulnerability,shouldnotbreakthefunctionalityofdeployed applicationsaslongastheyadheretostandardApplicationBinaryInterfaces (ABIs)aspreviouslydiscussed. CompatibilityBetweenMajorReleases RedHatEnterpriseLinuxalsoprovidesalevelofcompatibilityacrossmajor releases,althoughitislesscomprehensivethanthatprovidedwithinamajor release.Withthequalificationsgivenbelow,RedHatEnterpriseLinux4 providesruntimecompatibilitysupportforapplicationsbuiltforRedHat EnterpriseLinux2.1andRedHatEnterpriseLinux3. Betweenmajorreleases(forexample,betweenRedHatEnterpriseLinux3 andRedHatEnterpriseLinux4),RedHatseekstoprovidebinaryapplication compatibilityforapplicationsthatadheretopublishedstandardABIsandAPIs referencedinearliersectionsofthisdocument.Thisstatementappliesbothto nativearchitecturesupportandcompatibilityarchitecturesupport. RedHatprovidescompatibilitylibrariesforasetofcorelibraries.However, RedHatdoesnotguaranteecompatibilityacrossmajorreleasesofthe distributionfordynamicallylinkedlibrariesoutsideofthecorelibrarysetunless versionsoftheDynamicSharedObjects(DSOs)theapplicationexpectsare provided(eitheraspartoftheapplicationpackageorseparatedownloads). Toensurecompatibilityacrossmajorreleases,applicationdevelopersare encouragedtolimittheirdynamicallylinkedlibrarydependenciestothosein thecorelibraryset,ortoprovideanindependentversionoftherequirednon corelibrariespackagedwiththeirapplication(whichinturndependonlyon corelibraries).Asarule,RedHatrecommendsagainststaticallylinking librariesintoapplications. RedHatalsoreservestherighttoremoveparticularpackagesbetweenmajor releases.RedHatprovidesalistofdeprecatedpackagesthatmaybe removedinfutureversionsoftheproductintheReleaseNotesforeachmajor release.Applicationdevelopersareadvisedtoavoidusinglibrariesonthe deprecatedlist.RedHatreservestherighttoreplacespecificpackage implementationsinfuturemajorreleaseswithalternativepackagesthat implementsimilarfunctionality. RedHatdoesnotguaranteecompatibilityofconfigurationfileformatsordata fileformatsbetweenmajorreleasesofthedistribution,althoughindividual softwarepackagesmayinfactprovidefilemigrationorcompatibilitysupport. Formoreinformation,visitwww.redhat.comorcontactusat1888REDHAT1 (USandCanada)/+19197543700(international).
RedHatEnterpriseLinux4ApplicationCompatibility
12