XPost: comp.lang.c   
   From: cross@spitfire.i.gajendra.net   
      
   [Note: Followup-To: alt.os.development]   
      
   In article <87v7ssi2ec.fsf@example.com>,   
   Salvador Mirzo   wrote:   
   >scott@slp53.sl.home (Scott Lurndal) writes:   
   >> "Paul Edwards"  writes:   
   >>>Do you consider the concept of a BIOS (as seen as the IBM PC),   
   >>>"legitimate to use"   
   >>   
   >> In the abstract, possibly.  But the last half century has   
   >> shown that BIOS as an I/O abstraction layer was a bad idea   
   >> from the start.   
   >   
   >Would you elaborate or point out an article or book that could clarify   
   >the ideas that have made you to make such remark?  Sounds interesting.   
      
   This isn't really on-topic for comp.lang.c, so I'm cross-posting   
   to alt.os.development and setting Followup-To: to redirect   
   there.   
      
   The thing about the "BIOS" is that it is the product of a   
   specific context in computer history.  Early PCs were all   
   weirdly idiosyncratic, so Kildall created it to provide an   
   abstraction layer for CP/M, isolating relatively portable parts   
   from the machine specific bits.   
      
   But this had an interesting side effect that was also related to   
   the historical context.  Early PCs were mostly built around   
   microcontroller CPUs and were seriously RAM constrained; the   
   original IBM PC shipped with something like 128KiB of RAM.  A   
   useful property of the BIOS, as an abstraction layer between   
   the OS and the hardware, was that it could be be moved into ROM,   
   thus freeing up precious RAM resources for actual programs.   
      
   But it was always sort of a lowest-common denominator   
   implementation, tailored to the needs of a specific operating   
   system (first CP/M, then the various incarnations of DOS in the   
   IBM PC), so it runs in 16-bit mode and so on.  As such makes a   
   poor basis for IO in more advanced operating systems, which   
   generally want to be in charge of how IO is handled and what   
   state an IO device is in themselves.  Such systems provide   
   drivers that are redundant with whatever services the BIOS   
   provides, but better suited to their uses, so the BIOS confers   
   no real benefit for them.   
      
   I don't know that there are many books/articles/whatever that   
   discuss this in detail, but folks who build real systems run   
   into BIOS limitations pretty quickly. In particular, once you   
   want to start doing things like multiplexing concurrent IO   
   operations across devices, the whole synchronous BIOS model   
   breaks down.   
      
   	- Dan C.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)