Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

Sitting under the OS

Jake_OshinsJake_Oshins Member Posts: 1,058
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" <xxxxx@compuware.com>
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: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

Comments

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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: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" <xxxxx@compuware.com>
    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: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.
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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: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: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: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%%
  • David_J._CraigDavid_J._Craig Member Posts: 1,885
    There are a couple of problems with this. You have AMI, Award, Phoenix,
    IBM, Dell, Intel, etc. writing BIOS code or buying a basic BIOS development
    package from one of the BIOS vendors, but adding their changes,
    modifications, and other non-standard features. ABIOS was an idea whose
    time never came.

    CP/M had a software BIOS that each port of the OS required it to be
    rewritten to support the actual hardware. Of course, every vendor had major
    variations in their hardware and it wasn't until the IBM PC that the
    hardware became more standardized. Today the change seems to be for more
    variations with APICs, and chipsets that support supersets of various
    standard chips.

    The BIOS as we know it occupies the F000h and sometimes the E000h blocks of
    memory. Adding a protected mode version of the BIOS will require some
    window where the BIOS can be accessed. It would be possible for Microsoft
    to force standardization, but I haven't heard of any attempt to do so.
    Maybe Microsoft doesn't want to be known for revitalizing the ABIOS.

    Also, most BIOS today require much more than the 64KB of old. I remember
    the Compaq 386 that had such a small BIOS that they duplicated it in two
    32KB blocks within the F000h address block. They seemed to pick random
    interrupts to vector into each half even though it could all be handled in
    one.

    Most chipsets can run in a common mode, but each motherboard vendor usually
    releases chipset drivers to provide the full capabilities of their
    chipset/motherboard implementation. This fun might be why Jake moved from
    the HAL group, because it has to be a real bear to get even the standard
    stuff working with all the variations that exist. MS-DOS can run using the
    BIOS and usually doesn't get the full power features the system provides,
    but a real protected mode OS needs to be able to do things that are not
    simple and common to all chipsets. Intel has had several major problems
    with some of their chipsets over the last ten years or so. Intel also has a
    vested interest in keeping CPUs and chipsets from running any faster than
    documented, but several of the other motherboard vendors want their
    motherboards to be the fastest and to support overclocking as much as
    possible. Even the IBM PC/AT could be overclocked and the wait states for
    memory could be reduced successfully to increase throughput.

    Good idea, though, but can you get everyone to buy in? Microsoft would have
    to change some of the basic architecture of Windows NT to support more than
    two rings, but I guess they decided to keep it at two so more processors
    would be compatible.


    ----- Original Message -----
    From: "Moreira, Alberto" <xxxxx@compuware.com>
    To: "NT Developers Interest List" <xxxxx@lists.osr.com>
    Sent: Friday, December 20, 2002 10:46 AM
    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: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" <xxxxx@compuware.com>
    > 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: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@yoshimuni.com
    > To unsubscribe send a blank email to %%email.unsub%%
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Writing WDF Drivers 25 Feb 2019 OSR Seminar Space
Developing Minifilters 8 April 2019 OSR Seminar Space