home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / unix / bsd / 8985 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  6.5 KB
  1. Path: sparky!uunet!usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!math.fu-berlin.de!unidui!du9ds3!veit
  2. From: veit@du9ds3.fb9dv.uni-duisburg.de (Holger Veit)
  3. Newsgroups: comp.unix.bsd
  4. Subject: On patchkit and large fixes (was: XFree86...)
  5. Date: 17 Nov 92 07:54:18 GMT
  6. Organization: Uni-Duisburg FB9 Datenverarbeitung
  7. Lines: 111
  8. Message-ID: <veit.721986858@du9ds3>
  9. References: <veit.721670337@du9ds3> <STARK.92Nov14094333@sbstark.cs.sunysb.edu> <veit.721901127@du9ds3> <1992Nov16.222149.4904@fcom.cc.utah.edu>
  10. Reply-To: veit@du9ds3.uni-duisburg.de
  11. NNTP-Posting-Host: du9ds3.fb9dv.uni-duisburg.de
  12.  
  13. In <1992Nov16.222149.4904@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
  14.  
  15. >In article <veit.721901127@du9ds3> veit@du9ds3.uni-duisburg.de writes:
  16. >>In <STARK.92Nov14094333@sbstark.cs.sunysb.edu> stark@cs.sunysb.edu (Gene Stark) writes:
  17. [...on "codrv", an alternative console device with (currently) emphasis on
  18.     X11 support, integration into the patchkit, and patches pending...]
  19.  
  20. >By all means, send your 50-60 patches to Nate or myself, or put them on
  21. >ref.tfs.com, and we'll grab them!  I think the long delay in putting out
  22. >new patches has beenlargely due to Nate and I being confused
  23. >over who's going to integrate patches first.
  24.  
  25. Most of these 50-60 patches, I mentioned were already published in c.u.b.,
  26. so you should be aware of them. The essential patch that is included in
  27. the codrv package, fixes the problem that pty's are further used after
  28. closing the device, causing the console to hang after return from X. I sent
  29. this fix to Nate, but even with the enclosed explanation it seems nobody 
  30. has ever done something with it. This may be because of the "confusion"
  31. you mentioned above.
  32.  
  33. >>The idea of codrv was the avoidance of these "small, reliable patches".
  34. >>Natural growth of software was rarely a good base of software development.
  35. >>You might not need keyboard overloading, others might, you may require
  36. >>bell and keyboard fixes, others do not, but they might want to have other
  37. >>"bells and whistles". So how would you find an integration platform (I
  38. >>guess you won't, or at least haven't thought about it yet)? Codrv is
  39. >>a product for the future, not for current restricted requirements. This is
  40. >>why it has been marked "incomplete".
  41.  
  42. >This touches a sacred cow of mine, which is configuration.  There is
  43. >absolutely no reason why you should not be able to pick one of several
  44. >console drivers, several of many ethernet drivers, or one or more disk
  45. >drivers from those available.
  46.  
  47. I agree completely. I offered this driver to the community, because I think
  48. that it is an improvement over the existing one. It is quite natural to defend 
  49. one's own work, but I don't force anyone to use it. Normally, there is 
  50. "no problem" to replace one ethernet driver with another for the same board,
  51. and it is strongly recommended to take the one with the highest throughput.
  52. This holds for SCSIand other disk drivers as well. The problem with the
  53. console driver is a bit different: There may be - and there are - a number
  54. of builtin functions (ioctl's) in particular, which must be there for 
  55. some important task, but unfortunately make software that uses them very
  56. driver dependent. It is unfortunately not possible to extract some good
  57. feature, such as font loading, from codrv, without also taking part of
  58. the ESC-sequence handler (because font switching uses ESC codes). For some
  59. things this works: the "Setbell" or "keyboard LED" code fragments are 
  60. quite independent. No problem to build a patch to insert this into pccons,
  61. but this fix will be in there forever. In the long term you might get
  62. a "pccons with old X support and bells and whistles", one with VT100 emulator,
  63. one for X11, one with multiple virtual screens, etc. I would not maintain
  64. a user application which must first detect which driver it has, and then
  65. enable or disable special features.
  66.  
  67. >It should be possible to run "codrv" and still maintain the current
  68. >patch level of pccons without effecting it adversely (or even using the
  69. >pccons code at all if you don't want to.
  70.  
  71. Codrv carries the old pccons with it (with an encapsulation, that allows
  72. building a kernel with only one of codrv and pccons), the original patches
  73. (with some interleave) can still be applied to this file.
  74.  
  75. >                                SVR4 definitely has Berkeley
  76. >beat in this area; at a minimum, the files.i386 file ought to be
  77. >created from a set of specific "drop in" files to allow drop in (if not
  78. >drop out) of new driver/file system modules.  Some of this is apparently
  79. >being addressed in 0.2 from what I hear, but loadable modules don't go
  80. >sufficiently far in this direction.
  81.  
  82. I also heard of Bill's plans, but it is to early to decide now what will
  83. go and what won't. Truly loadable and unloadable modules could help
  84. (Regarding the former discussion on that topic, I am beginning to change
  85. my opinion, don't be surprised).
  86.  
  87. >It's true that good software tends to be revolutionary instead of
  88. >evolutionary (exceptions for BSD and vi 8-)), and there should be some
  89. >kind of non-conflicting drop-in mechanism for new kernel subsystems
  90. >(like codrv).  I'm not suggesting a "micro" kernel, but a layered
  91. >approach couldn't hurt.  One thing I'd like to see is a binary command
  92. >line configurator so that, unlike SVR4, we don't have to rebuild all
  93. >of our "space.c" equivalents each time.
  94.  
  95. >Another thing that would help is a packaging/versioning tool, such as is
  96. >provided by SCO, and a logical break-up into "packages" (other than etc,
  97. >bin, and src) for the software we normally see on 386BSD.
  98.  
  99. I would also consider this to be a fine extension.
  100.  
  101. >Meanwhile, keep posting/uploading/mailing/ftping patches until we (the
  102. >users of 386BSD) can get something more permanent worked out.
  103.  
  104.  
  105. >                    Terry Lambert
  106. >                    terry@icarus.weber.edu
  107. >                    terry_lambert@novell.com
  108. >---
  109. >Any opinions in this posting are my own and not those of my present
  110. >or previous employers.
  111. >-- 
  112. >-------------------------------------------------------------------------------
  113. >                                        "I have an 8 user poetic license" - me
  114. > Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
  115. >-------------------------------------------------------------------------------
  116.  
  117. Holger
  118.  
  119. -- 
  120. |  |   / Dr. Holger Veit         | INTERNET: veit@du9ds3.fb9dv.uni-duisburg.de
  121. |__|  /  University of Duisburg  | "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  122. |  | /   Dept. of Electr. Eng.   |   Sorry, the above really good fortune has
  123. |  |/    Inst. f. Dataprocessing |      been CENSORED because of obscenity"
  124.