home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / linux / 9851 < prev    next >
Encoding:
Text File  |  1992-09-04  |  2.0 KB  |  48 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!kithrup!cygnus.com!dje
  3. From: dje@cygnus.com (Doug Evans)
  4. Subject: Re: loadable device drivers
  5. Organization: Cygnus Support
  6. Date: Fri, 04 Sep 1992 15:44:30 GMT
  7. Message-ID: <1992Sep04.154430.22507@kithrup.COM>
  8. X-Newsreader: Tin 1.1 PL5
  9. References: <1992Sep4.054335.20424@sol.UVic.CA>
  10. Sender: news@kithrup.COM (Network News)
  11. Nntp-Posting-Host: cygnus.com
  12. Lines: 34
  13.  
  14. Peter MacDonald (pmacdona@sanjuan) wrote:
  15. : If I was a betting man, I would put money on loadable device drivers under
  16. : Linux being modelled somewhat after Shared libraries with jump tables.
  17. : 
  18. :  - Device drivers would have to have no external unresolved references.
  19.  
  20. I'm not sure I understand what you mean by "external unresolved references".
  21. It's trivial to link a driver in that references whatever kernel globals/funcs
  22. you want (I showed how in the kernel mailing list).
  23.  
  24. :  - Each device would be assigned a fixed range of Virtual Memory.
  25.  
  26. Again, I'm not sure what you mean. One knows in advance how big a portion of
  27. memory the driver will need for globals/funcs. You just need the kernel to
  28. allocate the required amount, and then you can tell the linker to link the
  29. code at the address returned from whatever memory allocation routine was used.
  30.  
  31. :  - The place in kernel memory where the device jump tables would reside
  32. :    would be preinitialized to jump to an error routine, in case called
  33. :    prior to initialization/loading.
  34.  
  35. One usually makes cdevsw[]/bdevsw[] (I forget if Linux calls them something
  36. different) big enough to have as many empty slots as you need.
  37.  
  38. : This design would place constraints upon the device code, but would 
  39. : simplify the kernel code, and would not require adding a linker to
  40. : it (keep in mind Linux has survived quite nicely without it to date).
  41.  
  42. I'm not sure I understand this part - are you refering to a linker
  43. residing in the kernel?
  44.  
  45. --
  46. Doug Evans        | With views like these ...
  47. dje@cygnus.com    |                           who needs disclaimers.
  48.