home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / os / linux / 6497 < prev    next >
Encoding:
Text File  |  1992-07-22  |  3.7 KB  |  93 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!munnari.oz.au!uniwa!oreillym
  3. From: oreillym@tartarus.uwa.edu.au (Michael O'Reilly)
  4. Subject: Thoughts on the kernel/mm/fs interface
  5. Message-ID: <1992Jul23.074530.8051@uniwa.uwa.edu.au>
  6. Sender: news@uniwa.uwa.edu.au (USENET News System)
  7. Nntp-Posting-Host: tartarus.uwa.edu.au
  8. Organization: University of Western Australia
  9. Date: Thu, 23 Jul 1992 07:45:30 GMT
  10. Lines: 81
  11.  
  12. Just haveing thrown out my second attempt at implementing the BSD FFS, I
  13. would like to toss a few ideas into the ring as regards the current
  14. interfaces between the mm, fs and kernel proper.
  15.  
  16. In my humble opinion, the current memory manager/file system interface
  17. seems a little clumbsy. In particular 3 things are very difficult to
  18. implement cleanly.
  19.  
  20. 1) Blocksizes other than 1K. This is due to the code in /fs all
  21. assumeing a 1K block size. :( This really does need fixing.
  22.  
  23. 2) A variable sized buffer. I.e. the buffer can use all pages not
  24. currently used by the kernel + user processes. This isn't too bad to
  25. implement, but it doesn't look clean. In particular the mm has some
  26. awkward semantics to deal with.
  27.  
  28. 3) Anything that requires a larger super block than the minix one. :(
  29.  
  30. Suggestion for improvements.
  31.  
  32. 1) The current buffer system be seperated a bit more from the fs system
  33. with one main interface;
  34.     long get_disk_page(struct inode *i, long offset);
  35.  
  36. Note that it returns the page number of the resultant page. Note also
  37. that the offset is in bytes, but should be in multiples of the page
  38. size. This cleans up two things in particular. The shared pages, and the
  39. demand pageing. It also frees the mm from dependance on the disk block
  40. size. 
  41.  
  42.     There is no reason why the page just read from the disk should
  43. be copied over to the user prossess space. (well, there is under the
  44. current modem, but we want to improve. ). SO lets just get the page
  45. number and map it directly in, without copying. This has the nice bit
  46. now that the page is still in the disk buffer (albeit locked). If
  47. another copy of the same application is run, get_disk_page() is called
  48. which maps tthe same page right into the new process's space. No copying
  49. of memory, and cleaner semantics for the memory manager. The thought
  50. just strikes me that this would probly improve mmap() as well. I
  51. haven't checked that ;)
  52.  
  53. 2) The VFS really needs to get away from it's dependance on 1K blocks.
  54. This is reasonably difficult to do. The best way I have thought of to do
  55. it, is just to change b_dev in the buffer_head structure to be a pointer
  56. to tthe super block instead of a device number. Only other way I think
  57. is to add the actually buffer size to the buffer_head structure and fix
  58. it in getblk(). Note that getblk() only gets passed the device number,
  59. not the super block, so we need to search the mount list to find tthe
  60. buffer size. This would need to be fixed.
  61.  
  62. 3) The super block and inode structures needs a lot of cleaning. The
  63. main problem is that there are a lot of elements on tthe current super
  64. block struct that are only meaningful to linux. The FFS in particular
  65. needs a far whack of info in memory which should be stored in the super
  66. block.
  67.  
  68. The easiest way of fixing this is just to make the fs-independant parts
  69. of the struct lie of the front, and let individual file systems cast it
  70. to access fs-depedant variables.
  71.  
  72. #define COMMON_SUPER \
  73.     int sb_blen; /* block length */ \
  74.     int sb_magic; /* magic number */
  75.  
  76. ie. struct super_block {
  77.     COMMON_SUPER;
  78.     char sb_dummy[2048]; /* space for fs dependant info */
  79.     };
  80.  
  81. struct ffs_super_block {
  82.     COMMON_SUPER;
  83.     int sb_cgrps; /* number of cyl groups. */
  84.     ...
  85.     };
  86.  
  87. Looks nice to me. comments?
  88.  
  89. I have got down here, and am cartain I have things I havve forgotten to
  90. say. Any comments? furthur suggestions/improvements I have missed?
  91.  
  92. Michael
  93.