home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / bsd / 5599 < prev    next >
Encoding:
Internet Message Format  |  1992-09-12  |  4.6 KB
  1. Path: sparky!uunet!olivea!spool.mu.edu!agate!dog.ee.lbl.gov!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
  2. From: terry@cs.weber.edu (A Wizard of Earth C)
  3. Newsgroups: comp.unix.bsd
  4. Subject: 386BSD SHARED LIBRARIES
  5. Keywords: shared libraries X X11
  6. Message-ID: <1992Sep12.180450.25086@fcom.cc.utah.edu>
  7. Date: 12 Sep 92 18:04:50 GMT
  8. References: <veit.716107923@du9ds3> <7dnL02y821gh01@JUTS.ccc.amdahl.com> <veit.716291291@du9ds3>
  9. Sender: news@fcom.cc.utah.edu
  10. Organization: Weber State University  (Ogden, UT)
  11. Lines: 75
  12.  
  13. In article <veit.716291291@du9ds3> veit@du9ds3.uni-duisburg.de writes:
  14. >My actual preference is the following system:
  15. >Link an application with a special "stub library" that has undefined references
  16. >to special "shared" code and data segments outside the standard _TEXT, _DATA
  17. >and _BSS. There is a configurable shared library server that is loaded into
  18. >memory at boot time (demand paging, of course) which has a symbol table in
  19. >memory which contains the public references (Jump insn's) to the real
  20. >libraries. The library server containing the library code is built for the 
  21. >shared data/text area. The program loader (kern_execve) resolves the lib
  22. >references to the shared area, and makes the program's shared data segment 
  23. >copy-on-write so that it does not influence the memory of the library server.
  24. >This dynamic linking does rely on the existance of a symbol table at some
  25. >known location, but not on the number, the size, and the location of the
  26. >shared modules.
  27.  
  28. I don't think you want to do user-land serving of the page requests; you
  29. can probably do it just as easily by providing an object page mechanism
  30. using the stubs and a well defined symbol resoloution mechanism to get
  31. PIC offsets.  The one problem I see here is large library routines crossing
  32. page boundries and maintaining a per process page index.  I think this can
  33. be done by enforcing interdependency rules on the code and aligning it on
  34. page boundries on load.
  35.  
  36.     Obviously, this could be made faster if routines started on block
  37. boundries so they could be paged directly off the disk when needed.  I
  38. see two possible mechanisms:
  39.  
  40. 1)    The code is paged off of disk as a result of a demand-read request
  41.     from within the kernel.  This will have the effect of placing the
  42.     desired code in the buffer list hung off the locked vnode, which
  43.     is the shared library reference.  It's probably questionable whether
  44.     copy-on-write can be implemented in this setup, and with multiple
  45.     processes it's likely that there will be contention problems.  This
  46.     can be partially alleviated by copy-on-reference, but it's unlikely
  47.     that this would result in sharing of text segments without adding
  48.     another stage of support for hit-the-shared-image, hit-the-cache,
  49.     hit-the-disk.
  50.  
  51. 2)    Obtain multiple locked vnodes for a single process (one for the
  52.     executable file and one for each linked shared library), keeping
  53.     a common area and mapping the pages from the common area into each
  54.     process using the library.  This would have to be done at load time,
  55.     so kern_exec would require modification, and the exit code would
  56.     have to decrement the lock reference.  Other than the initial mapping
  57.     of pages containing PIC code and relocation of the process data as
  58.     a result of a change in offset, this could probably be handled by the
  59.     existing text sharing mechanism.  The only drawback here is managing
  60.     the distinction between code pages and data pages so that one can
  61.     do copy-on-write rather than copying the data into each process
  62.     space initially... and it probably wouldn't be done on first
  63.     revision (ie: shared libraries are shared text only).
  64. >
  65. >Unfortunately, I'm currently not so deep inside the vm code of 386bsd, to
  66. >decide whether this can be done in reasonable time, but I am willing
  67. >to discuss about this and offer my help with implementation.
  68.  
  69. I don't know what you mean by a reasonable time... are we on a schedule 8-)?
  70. I don't think it would take an unreasonable amount of time, and the vast
  71. majority of the problems are still in the PIC generation, new assembler,
  72. and linking against shared library stubs (which ar or ld would have to be
  73. hacked to produced).  Compared to the user-space work required, I still
  74. think the kernel changes are trivial.
  75.  
  76.  
  77.                     Terry Lambert
  78.                     terry_lambert@gateway.novell.com
  79.                     terry@icarus.weber.edu
  80. ---
  81. Any opinions in this posting are my own and not those of my present
  82. or previous employers.
  83. -- 
  84. -------------------------------------------------------------------------------
  85.                                         "I have an 8 user poetic license" - me
  86.  Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
  87. -------------------------------------------------------------------------------
  88.