home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / linux / 8129 < prev    next >
Encoding:
Text File  |  1992-08-13  |  2.8 KB  |  62 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!elroy.jpl.nasa.gov!usc!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!ira.uka.de!chx400!bernina!almesber
  3. From: almesber@nessie.cs.id.ethz.ch (Werner Almesberger)
  4. Subject: Re: loadable device drivers
  5. Message-ID: <1992Aug13.151040.284@bernina.ethz.ch>
  6. Sender: news@bernina.ethz.ch (USENET News System)
  7. Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH
  8. References: <2659@nlsun1.oracle.nl>
  9. Date: Thu, 13 Aug 1992 15:10:40 GMT
  10. Lines: 50
  11.  
  12. In article <2659@nlsun1.oracle.nl> jhelberg@nl.oracle.com (Joost Helberg) writes:
  13. > Far too long, and you have to reboot too! i.e. all users have to 
  14. > get coffee or tea!
  15.  
  16. You're developping new drivers while users are working on your machine ?
  17. Poor users ... ;-)
  18.  
  19. > The kernel must be mapped when implementing loadable device drivers (to
  20. > get page-faults) so the kernel doesn't need contiguous memory --> less
  21. > problems allocating memory.
  22.  
  23. Page-faults are deadly for most parts of the kernel. Unless the interrupt
  24. handling is changed in radical ways (see below), you don't want interrupt
  25. handlers and code that's called by them to reside in paged memory. (Besides
  26. the obvious case of device drivers that may be possibly invoked when
  27. handling a page fault.)
  28.  
  29. Using the paging hardware to map kernel pages is a good idea, though.
  30.  
  31. > - The kernel will never use more core than necessary. Only text/data really
  32. >  used will be in core (that is using LRU algorithms). 
  33.  
  34. Yes, but you need interrupt queues and an interrupt scheduler to be able
  35. to accept interrupts from devices that can send more than one interrupt
  36. per interaction (i.e. SIOs) even if you have to fault in the driver first.
  37. Might be hairy to implement, although it looks like a very elegant
  38. solution for most interrupt problems.
  39.  
  40. You also need a way to lock certain kernel areas in physical memory.
  41. (MM, at least one FS, scheduler, hd driver, some other kernel data
  42. structures, drivers for devices that expect a low interrupt latency, etc.)
  43.  
  44. > - Updating a driver can be done at runtime shortening the development time
  45. >  of driver enhancements.
  46.  
  47. Certainly a big win, especially on slow systems where a compile-reboot-
  48. test-fail-edit-...-cycle is significantly longer than 45 seconds. Even
  49. a mechanism where you'd have to compile stubs into the kernel but could
  50. load the actual code at run time would be useful.
  51.  
  52. An even more important use would be dynamic system configuration, e.g. one
  53. could use local drivers without patching them into each kernel release.
  54. (Needs probably some changes to the way existing driver are called.)
  55.  
  56. - Werner
  57. -- 
  58.    _________________________________________________________________________
  59.   / Werner Almesberger, ETH Zuerich, CH      almesber@nessie.cs.id.ethz.ch /
  60.  / IFW A44  Tel. +41 1 254 7213                 almesberger@rzvax.ethz.ch /
  61. /_BITNET:_ALMESBER@CZHETH5A__HEPNET/CHADNET:_[20579::]57414::ALMESBERGER_/
  62.