home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / linux / 8210 < prev    next >
Encoding:
Internet Message Format  |  1992-08-13  |  3.1 KB
  1. Path: sparky!uunet!mcsun!sun4nl!orcenl!jhelberg
  2. From: jhelberg@nl.oracle.com (Joost Helberg)
  3. Newsgroups: comp.os.linux
  4. Subject: Re: loadable device drivers
  5. Message-ID: <2671@nlsun1.oracle.nl>
  6. Date: 14 Aug 92 10:49:47 GMT
  7. References: <1992Aug13.151040.284@bernina.ethz.ch>
  8. Organization: Oracle Europe
  9. Lines: 62
  10. X-Newsreader: Tin 1.1 PL3
  11.  
  12. X-Disclaimer: This message was written by an unauthenticated user
  13.               at Oracle Corporation.  The opinions expressed are those
  14.               of the user and not necessarily those of Oracle.
  15.  
  16. almesber@nessie.cs.id.ethz.ch (Werner Almesberger) writes:
  17. : In article <2659@nlsun1.oracle.nl> jhelberg@nl.oracle.com (Joost Helberg) writes:
  18.  
  19. [deleted]
  20. : > The kernel must be mapped when implementing loadable device drivers (to
  21. : > get page-faults) so the kernel doesn't need contiguous memory --> less
  22. : > problems allocating memory.
  23. : 
  24. : Page-faults are deadly for most parts of the kernel. Unless the interrupt
  25. : handling is changed in radical ways (see below), you don't want interrupt
  26. : handlers and code that's called by them to reside in paged memory. (Besides
  27. : the obvious case of device drivers that may be possibly invoked when
  28. : handling a page fault.)
  29. : 
  30. : Using the paging hardware to map kernel pages is a good idea, though.
  31. : 
  32. : > - The kernel will never use more core than necessary. Only text/data really
  33. : >  used will be in core (that is using LRU algorithms). 
  34. : 
  35. : Yes, but you need interrupt queues and an interrupt scheduler to be able
  36. : to accept interrupts from devices that can send more than one interrupt
  37. : per interaction (i.e. SIOs) even if you have to fault in the driver first.
  38. : Might be hairy to implement, although it looks like a very elegant
  39. : solution for most interrupt problems.
  40. : 
  41. : You also need a way to lock certain kernel areas in physical memory.
  42. : (MM, at least one FS, scheduler, hd driver, some other kernel data
  43. : structures, drivers for devices that expect a low interrupt latency, etc.)
  44. :  
  45.  
  46. You're right about all this; my idea came from the time I developed
  47. streams drivers and streams drivers only. These can very easy be made
  48. pageable in the sense that streams-modules/drivers get scheduled by the
  49. scheduler as if they are user-processes. You can swap them if you want!
  50.  
  51. [deleted]
  52.  
  53. I think it is not a good idea to implement any driver as a loadable driver,
  54. but with a new driver-interface (like STREAMS is) it is easy to implement,
  55. without too much problems.
  56.  
  57. One could even implement a seperate driver-space (analog to user-space, with
  58. its own mmu-tables) for each streams-driver instance, bus-errors etc. result
  59. in core dumps in stead of terminal-dumbs!
  60.  
  61. I think (before STREAMS are implemented) that we should invest in defining
  62. a configurable driver-interface for Linux, discussion in mailing-list 
  63. 'configuration' at niksula.hut.fi or on the news.
  64.  
  65. Any comment?
  66.  
  67. --
  68.    Joost Helberg                                Rijnzathe 6
  69.    jhelberg@oracle.nl                           NL-3454 PV De Meern
  70.    jhelberg@nl.oracle.com                       The Netherlands
  71.  
  72.    Oracle Europe BV                             Product Line Development    
  73.    Phone: +31 3406 94211                        Fax:   +31 3406 65609
  74.