I has been awhile since I worked with the EFI team, but it seemed as though
they were encouraging all Intel based platforms to embrace EFI. Including
desktops/embedded. Like I said it has been awhile so I could be
wrong. either change is slow… look how long those ISA slots hung around.
-Justin
At 12:41 PM 12/20/2002, you wrote:
I share the some of the view as Alberto to have a common firmware
interface. However, I believe driver architecture still needs to be OSes
dependent to differentiate (good and better) OSes . I believe EFI is
heading to this direction. Nevertheless, Jake said he (and possibly
Microsoft) has given up this dream by only supporting major chipset/bios
vendors and OEMs. It is also not cost effective for embedded system to be
built on any common firmware interface. PC is merely commodity now-a-days.
The innovation lies in smaller devices, which diversity are welcomed.Bi
-----Original Message-----
From: Moreira, Alberto
[mailto:xxxxxmailto:xxxxx@compuware.com]
>Sent: Friday, December 20, 2002 7:46 AM
>To: NT Developers Interest List
>Subject: [ntdev] RE: Sitting under the OS
>
>The answer to that is a public and relevant - meaning legacy free,
>processor-architecture free, and dirty-compatibility free - Bios spec.
>Something more or less in the direction of the ABIOS that IBM tried to get
>into place a few years ago. I am a firm believer of the onion-peel model of
>software development: there should be a Bios that deals with hardware unique
>to the machine, and that Bios should present a predictable and uniform
>lowest-level OS-independent interface to the world; that API should work the
>same for Windows, Linux, Beos or whatever else. There should be hardware
>level drivers that, as their name implies, drive the hardware - and the OS
>should sit on a higher level, leveraging on public and standard APIs offered
>by the Bios and establishing a uniform upper-edge interface to device
>drivers. The way I see it, it is not ok to have lower edge OS interfaces
>that device drivers are required to maintain, neither is it ok to absorb
>platform-specific hardware considerations away from the Bios.
>
>In my mind, I/O handling does not belong in the trusted kernel, but then,
>that requires hardware that many RISC machines don’t have today. It could be
>easily done in the PC if people took advantage of the multiple protection
>rings: I see no reason why the whole of the I/O handling in an Intel PC
>wouldn’t be better off handled at Ring 1 than at Ring 0.
>
>A problem we have today is that we do not have a lowest level
>hardware-independent public API that everybody can code to. It shouldn’t be
>like that - the line separating hardware from software handling should be
>sharper.
>
>Alberto.
>
>
>
>-----Original Message-----
>From: Jake Oshins
>[mailto:xxxxxmailto:xxxxx@windows.microsoft.com]
>Sent: Thursday, December 19, 2002 6:54 PM
>To: NT Developers Interest List
>Subject: [ntdev] Sitting under the OS
>
>To some, yes. To most of the people on this list, it just means that
>instead of just needing to test their code and their hardware against
>every processor and every chipset, they also need to test it against the
>matrix of every chipset and every BIOS codebase, too, since the BIOS can
>(and often does) modify the behavior of the underlying chipset. This
>exponential increase in variation of the behavior of the platform mostly
>means that an IHV can’t guarantee you that their hardware works with
>every machine in the world. Take, for example, the guy who was asking
>about how you guarantee isochronicity on the USB with a BIOS that is
>doing 100ms delays.
>
>- Jake
>
>-----Original Message-----
>Subject: Re: UART Handling - was interrupt handshaking
>From: “Moreira, Alberto”
>Date: Wed, 18 Dec 2002 13:22:01 -0500
>X-Message-Number: 21
>
>Well, it’s nice to have some hardware in the machine that one can use to
>sit
>under the OS, no ?
>
>Alberto.
>
>-----Original Message-----
>From: Bi Chen [mailto:xxxxxmailto:xxxxx@AppStream.com]
>Sent: Wednesday, December 18, 2002 1:18 PM
>To: NT Developers Interest List
>Subject: [ntdev] Re: UART Handling - was interrupt handshaking
>
>
>SMI is used for APM, legacy keyboard/mouse emulation for USB
>keyboard/mouse,
>among other things you guys have mentioned. OS is unware of SMI at all.
>When
>SMI asserts, it puts processor into SMM and BIOS SMM code will take
>over. We
>all wish it along with other legacy go away entirely. However, in PC
>world,
>legacy die extramely hard.
>
>Bi
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@compuware.com
>To unsubscribe send a blank email to %%email.unsub%%
>
>
>The contents of this e-mail are intended for the named addressee only. It
>contains information that may be confidential. Unless you are the named
>addressee or an authorized designee, you may not copy or use it, or disclose
>it to anyone else. If you received it in error please notify us immediately
>and then destroy it.
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@appstream.com
>To unsubscribe send a blank email to %%email.unsub%%
>—
>You are currently subscribed to ntdev as: zeppelin@io.com
>To unsubscribe send a blank email to %%email.unsub%%</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>