home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / sysv386 / 16353 < prev    next >
Encoding:
Text File  |  1992-11-09  |  2.3 KB  |  46 lines
  1. Newsgroups: comp.unix.sysv386
  2. Path: sparky!uunet!scorn!staceyc
  3. From: staceyc@sco.COM (Stacey Campbell)
  4. Subject: Re: Two Xfree86 questions
  5. Organization: The Santa Cruz Operation, Inc.
  6. Date: Fri, 06 Nov 1992 17:32:08 GMT
  7. Message-ID: <1992Nov06.173208.20900@sco.com>
  8. References: <1992Oct29.163200.4554@cbnewsj.cb.att.com> <1992Nov02.234155.2179@sco.COM> <1992Nov4.175056.24918@cbnewsj.cb.att.com>
  9. Sender: news@sco.com (News admin)
  10. Lines: 34
  11.  
  12.  
  13. In article <1992Nov4.175056.24918@cbnewsj.cb.att.com> dwex@cbnewsj.cb.att.com (david.e.wexelblat) writes:
  14. >I have heard that SCO's server works by dynamically loading the 
  15. >appropriate driver(s) at run time.  Is that true?
  16.  
  17. It is.  We found that keeping the core server (/usr/bin/X11/Xsco), the
  18. drawing engines for each class of video card (SVGA, XGA, 8514/A, S3, and
  19. so on), and the board specific initialization code (/usr/lib/grafinfo/*/*)
  20. independent of each other to be the most flexible way to support a bunch
  21. of cards, get reasonable performance, make it real easy to write support
  22. for a new card, and to enable us to move to X11R5 without (in theory)
  23. touching a single line of our card specific drawing code.  This turned out
  24. to be as difficult an engineering job as it sounds.  ;-)
  25.  
  26. Now we run a two day "X Server Linkkit Class" where video hardware vendors
  27. can come along and get a full-blown X server up and running in one day on
  28. a brand new class of video chip, and then get some optimizations thrown in
  29. on the second day.  Then later when they have got their software up to
  30. a good speed and got the bugs out they can ship a dynamic driver that will
  31. load into the X server already installed on the system.
  32.  
  33. >If so (and you are allowed to tell :->), how does that work?  I thought
  34. >that SVR3 didn't support dynamically loadable objects.
  35.  
  36. I'm pretty sure that the 20 pages of fine print I signed when I started
  37. here included the line "...and you will not blab trickey source code
  38. hacks to people on the net...", however, if you recall the old BSD rogue
  39. game that would save itself by writing its core to a file then restore
  40. the game by "unexecing" itself (Franz Lisp and older TeX versions also used
  41. this trick), well we do something similar though in my opinion even
  42. nastier.  So even though SVR3.2 doesn't come with dynamic loading it can
  43. be added at the user program level.
  44. -- 
  45.           Stacey Campbell - staceyc@sco.com - uunet!sco!staceyc
  46.