From: smirzo@example.com   
      
   cross@spitfire.i.gajendra.net (Dan Cross) writes:   
      
   > [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.   
      
   Cross-post obeyed.   
      
   > 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.   
      
   But Scott Lurndal said it was a bad idea and, from what you say, it   
   seems like a not-so-bad idea.  It could be stored in ROM, leaving up RAM   
   for the OS and the users; it hid machine-specific details from the OS,   
   creating an abstraction.  And I believe the BIOS doesn't stop the OS   
   from talking directly to the machine, so it's not an obstacle either.   
   What am I missing?   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)