Gecko/20110221 Thunderbird/3.1.8   
   UTC)   
   .os2.ecomstation:876 comp.os.os2.beta:32   
   From: Jonathan de Boyne Pollard    
      
   >>> Can't we learn something from it though? There will be examples of    
   >>> tapping into interfaces that our loader currently has no clue about.   
   >>>   
   >> Once again: It's not an operating system or an operating system    
   >> loader. It's replacement firmware. There won't be any "tapping into    
   >> interfaces" because it isn't a loader. It's what loaders (the    
   >> so-called "payload") run on top of and use.   
   >>   
   > "The final mainboardinit fragment is mainboard-specific, in C, called    
   > romstage.c. For non-cache-as-RAM targets, it is compiled with romcc.    
   > It includes and uses other C-code fragments for: [...]"   
   >   
   > Really?  None of that is useful?   
   >   
      
   Correct.  None of it is useful.  What part of "is mainboard-specific" is    
   unclear here?  No-one working on the OS/2 kernel loader or a clone who    
   is in their right mind would make the loader specific to a particular    
   mainboard.  Loaders are generic, that use the abstract interfaces    
   provided *by* the firmware, without regard to the details of the    
   particular mainboard at hand.   
      
   > Just because this stuff is designed to execute from ROM doesn't mean    
   > we can't make use of it.   
   >   
      
   No-one said anything about it executing from ROM being the problem.  The    
   fact that it's firmware, not an operating system loader, is what makes    
   it useless for the purposes of an operating system loader.  It's    
   firmware.  It's not an operating system loader.  It's code that does a    
   completely different job, at a different layer of abstraction.  How many    
   times does this point have to be made before it sinks in?   
      
   >> And what's this "our loader" business? I for one don't have any stake    
   >> in the IBM OS/2 kernel loader. It isn't mine. It's IBM's, last that I    
   >> looked.   
   >>   
   > The loader that we, who use OS/2, use.  If you prefer not to be    
   > included in that group, then I won't complain if you don't read    
   > yourself into my statement.   
   >   
      
   You clearly haven't thought that through.  Merely using a loader doesn't    
   make your the owner of it.  And if you aren't the person who is capable    
   of changing the loader, *even if* this replacement firmware were somehow    
   relevant to the task of doing so, then you don't belong to the relevant    
   "we", which in this case is IBM and the people who can modify OS2LDR,    
   and the other groups that I alluded to.  In other words: You're not    
   included in the relevant "we" any more than I am.  You're mistaken to    
   think that you are.   
      
   >> I know of only three groups outwith IBM that have stakes in    
   >> OS/2-clone kernel loaders. The OSFree people have their own loader,    
   >> which is (we'retold) based upon the old FreeLDR loader from David C.    
   >> Zimmerli (not to be confused with the ReactOS FreeLDR). They're the    
   >> only people with an interest in "our loader", and they'll tell you as    
   >> I do that firmware source code doesn't show how to *use* firmware APIs.   
   >>   
   > I'd be mining for data from under every rock if I were them, and    
   > hopefully they are not as close-minded as you seem to assume.   
   >   
      
   This isn't about close-mindedness.  This is about having some degree of    
   Clue as to what the task of writing an operating system loader actually    
   entails, and thus what is and isn't helpful to that task.  What is    
   helpful are things like the PCI BIOS specification, the PnP BIOS    
   specification, the EFI specification, the Phoenix/IBM/Microsoft INT 13h    
   extensions specification, the AMD and Intel CPUID specifications, the    
   AMD and Intel software developers' manuals, and so forth.  What isn't    
   helpful is the source code to one particular machine firmware.  One    
   doesn't need to know how the firmware does its job internally.  One    
   needs to know the interface contract that you and it work to.  Rare    
   indeed is the implementation source code that is useful for knowing the    
   interface contract.  Try reading the Bochs firmware source code and    
   working out the PnP BIOS or PCI BIOS specifications from it, for    
   example.  (Those in the know will be highly amused at that suggestion.)   
      
   You're getting all excited just because of a press announcement for a    
   five-year-old project, announcing some "free" stuff, and your excitement    
   is taking the fact that it's "free" to be far more important than the    
   fact of whether it's even relevant.  I'm the person with Clue telling    
   you that this sort of thing is about as relevant to the job as someone    
   announcing that they are giving away free pictures of Jamie Lynn    
   Spears.  It's an entertaing sideshow for those with an interest in it,    
   but it isn't at all useful for the task at hand.   
      
   For a fourth time:  It's replacement firmware.  It's not an operating    
   system loader, nor an operating system.  It's what loaders (the    
   so-called "payload") run on top of and use.  The fact that something is    
   "free" and recently (re-)announced doesn't automatically make it relevant.   
      
   --- Internet Rex 2.31   
    * Origin: virginmedia.com (1:261/20.999)