Porting Kernel Code to Four Bsds and Linux

Porting Kernel Code to Four Bsds and Linux

THE ADVANCED COMPUTING SYSTEMS ASSOCIATION The following paper was originally published in the Proceedings of the FREENIX Track: 1999 USENIX Annual Technical Conference Monterey, California, USA, June 6–11, 1999 Porting Kernel Code to Four BSDs and Linux Craig Metz ITT Systems and Sciences Corporation © 1999 by The USENIX Association All Rights Reserved Rights to individual papers remain with the author or the author's employer. Permission is granted for noncommercial reproduction of the work for educational or research purposes. This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein. For more information about the USENIX Association: Phone: 1 510 528 8649 FAX: 1 510 548 5738 Email: [email protected] WWW: http://www.usenix.org Porting Kernel Co de to Four BSDs and Linux Craig Metz ITT Systems and Sciences Corporation [email protected] Abstract these were virtually identical systems. Because a large p ortion of our co de resided in the netinet directory The U.S. Naval Research Lab oratory develops and and the two systems were virtually identical, we de- maintains a freely available IPv6 and IP Security dis- cided to put our mo di cations into the 4.4BSD-Lite2 tribution. All of the software builds and runs on netinet (IPv4) co de and make the needed changes to BSD/OS, FreeBSD, NetBSD, and Op enBSD, and a p ort that into BSD/386 and 4.4BSD/sparc. growing p ortion of the software builds and runs on In 1995, we made the rst jump to a radically dif- Linux. Each of the four BSDs has evolved signi cantly ferent system. Although most of the research commu- from their original 4.4BSD-Lite ancestor, and increas- nity used BSD, Linux was also an interesting system, ingly more of that evolution is along divergent paths. so we decided to attempt to p ort a comp onentofour Linux shares no signi cant ancestry with the BSDs, software to Linux. One comp onent that was some- but is still a POSIX system, which means that manyof what unique to the NRL software was our PF KEY[2] the same high-level facilities are available even though interface and implementation, which also had the im- their implementation might b e completely di erent. p ortant feature of b eing a fairly self-contained mo d- This pap er discusses many of the di erences and KEY communicates with user space as a new ule. PF many of the similarities we encountered in the inter- so ckets proto col family and with the rest of the ker- nals of these systems. It also discusses the techniques nel through function calls we de ned. We felt that it and glue softwarethatwe develop ed for isolating and would b e useful to havethePF KEY implementation abstracting the di erences so that we could build a sig- running on Linux even if the rest of our co de never did, ni cant base of system co de that is p ortable b etween and that it was a reasonable part of the software to at- all ve systems. tempt to p ort. We split our PF KEY implementation and our debugging framework into a OS-sp eci c parts 1 Intro duction (suchasthesockets interface co de) and common parts (such as the actual message pro cessing co de). With 1.1 History some help from the Linux community and Alan Cox in particular, we p orted our 4.4BSD PF KEY imple- The U.S. Naval Research Lab oratory's IPv6+IPsec mentation to to Linux in ab out three months. distribution [1] b egan its life in 1994 on BSD/386 In 1996, we added supp ort for NetBSD, another 1.1, whichwas a 4.3BSD \Net/2" system. When 4.4BSD-Lite derived system. The NetBSD team had BSD/386 2.0, whichwas based on 4.4BSD-Lite, b e- made a number of changes versus 4.4BSD-Lite that came available, wemoved the co de to that system. we had to add ifdefs to handle. NetBSD had also This was a straightforward change, as the di erences added a numb er of new IPv4 features that 4.4BSD- in the parts of the two systems that our co de inter- Lite didn't have; b ecause wewere using a common faced with were small. We then added supp ort for 4.4BSD-Lite netinet implementation, those features \real" 4.4BSD/sparc. Atthispoint, weraninto our were all removed when we replaced that co de. rst two exp eriences with maintaining the same co de in di erentkernels. First, we had to separate our co de As time wenton,we dropp ed supp ort for the \real" into parts sp eci c to each and parts shared b etween the 4.4BSD/sparc b ecause almost nob o dy actually had a two. Second, we found slight di erences in the way the copy of it and b ecause NetBSD/sparc was a freely systems did things and had to add some ifdef state- available system that worked b etter. Both BSD/386 ments to our \shared" tree to cop e with these. Still, (renamed to BSD/OS) and NetBSD continued to evolve, and we had to put more and more ifdefs OS-sp eci c co de than wewere b efore b ecause wewere into our co de to cop e with their changes from 4.4BSD. mo difying each of the BSD systems' native netinet It b ecame clear that wewere actually sp ending al- co de. We decided to do a ma jor reorganization of most as much e ort sho ehorning the original 4.4BSD- our source tree, separating it into seven mo dules: an Lite netinet co de into the newer version of these sys- OS-sp eci c piece for each of the ve systems, a BSD- temsasitwould taketomaintain our changes to the common piece shared b etween all of the BSD systems, netinet co de in each system's native implementation, and a common piece shared b etween all of the sys- and throwing away the native systems' changes was a tems. With some added scripts and to ols, wewere problem for some users. able to create an organization of \overlays" suchthat the common pieces could b e symlinked to app ear in In 1997, we built an implementation of the second the OS-sp eci c directories, and such that the more- version of our PF KEY interface. Wechose to build sp eci c pieces could override the less-sp eci c pieces. this implementation as a ground-up rewrite. Instead This new organization made it much easier for us to of building this new implementation on one system maintain our software on all of these systems while and \p orting" to the others, we actually develop ed trying to balance duplication of e ort with close inte- this co de simultaneously on BSD/OS, NetBSD, and gration into the supp orted systems. Linux. By doing this, wewere able to nd and resolve While wewere doing the p orts to Op enBSD and OS dep endencies quickly, and wewere able to takead- FreeBSD, wewere also rewriting large p ortions of our vantage of the debugging strengths of each of these IPsec implementation. Because we knew that it was systems. This was also an opp ortunitytodomany a direction wewanted to eventually moveto,we built things di erently, designing for p ortability based on a framework to allowthenewcodetobeportedto our previous exp eriences rather than adding p ortabil- Linux. After all of the BSD p orts and the rewrite of ity as an afterthought. the IPsec co de were nished and released, we b egan In late 1997, BSDI chose to integrate our co de into the task of p orting our IPsec co de to Linux, whichis their source tree for the up coming BSD/OS 4.0. BSDI currently a work in progress. actually did the work of integrating our changes into their netinet co de, whichmeant that half of the work 1.2 Observations of integrating our co de into the native netinet co de of our supp orted systems was done. We also decided to In the course of building our software and adding sup- exp end more e ort on b ecoming a go o d choice for in- p ort for all of these systems, we learned many things tegration into other systems, whichmeant adding new ab out how to build and maintain p ortable kernel co de. p orts to Op enBSD 2.3 and FreeBSD 3.0 and integrat- Many of the lessons that we learned didn't havetobe ing our changes into the native netinet implementa- learned the hard way. Large blo cks of co de are shared tions of each system. between the various BSD systems, esp ecially co de for The Op enBSD p ort was surprisingly straightforward new networking features and device drivers. There are b ecause of its shared ancestry with NetBSD; most also some cases of software that had b een p orted from of the di erences b etween 4.4BSD-Lite and NetBSD BSD to Linux (for example, the NCR SCSI driver) and could also b e found in Op enBSD. The ma jority of the from Linux to BSD (for example, the GPL x87 math work we ended up doing for this p ort was integrat- emulator). Perhaps the b est known example of p ort- ing our co de into the Op enBSD netinet co de, which ing kernel co de is the BSD network stack, which can b e then got us most of the waytoalsohaving our co de seen running in all sorts of systems that are de nitely integrated into the NetBSD netinet co de.

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    11 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us