My prediction of last week that MS if forgoing the VMWare type technology
and moving towards EFI seems to have some validity:
http://news.com.com/2100-7337_3-5131787.html?tag=nefd_lede
Regards,
Jamey Kirby, Windows DDK MVP
StorageCraft Inc.
xxxxx@storagecraft.com
http://www.storagecraft.com
How are the two exclusive? They seem to address completely different
needs.
– arlie
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jamey Kirby
Sent: Tuesday, December 30, 2003 12:54 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] An interesting artibcle on EFI
My prediction of last week that MS if forgoing the VMWare type
technology and moving towards EFI seems to have some validity:
http://news.com.com/2100-7337_3-5131787.html?tag=nefd_lede
Regards,
Jamey Kirby, Windows DDK MVP
StorageCraft Inc.
xxxxx@storagecraft.com
http://www.storagecraft.com
Well, EFI will provide the hardware abstraction layer that is currently
provided by products like VMWare.
Jamey Kirby, Windows DDK MVP
StorageCraft Inc.
xxxxx@storagecraft.com
http://www.storagecraft.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Arlie Davis
Sent: Tuesday, December 30, 2003 10:35 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] An interesting artibcle on EFI
How are the two exclusive? They seem to address completely different
needs.
– arlie
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jamey Kirby
Sent: Tuesday, December 30, 2003 12:54 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] An interesting artibcle on EFI
My prediction of last week that MS if forgoing the VMWare type
technology and moving towards EFI seems to have some validity:
http://news.com.com/2100-7337_3-5131787.html?tag=nefd_lede
Regards,
Jamey Kirby, Windows DDK MVP
StorageCraft Inc.
xxxxx@storagecraft.com
http://www.storagecraft.com
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
>
Well, EFI will provide the hardware abstraction layer that is
currently provided by products like VMWare.
I must be as dense as Arlie 
EFI is a bios replacement and does little if anything after booting to a
real OS. VmWare is a minimal but real OS that provides sets of ‘virtual
machines’ that in turn run various flavors of operating systems. Microsoft
is busy rolling out their Virtual PC competition for VmWare. Are you sure
there is much of any connection between EFI and virtual machine technology?
I think things like encryption of the boot disk will be possible. You
can put anything in EFI from diagnostics to solitaire if you want. You
probably need access to the Intel examples and maybe how Microsoft plans
to interface with EFI during boot to know what it can or will do for
[to] you. Blow the EFI and you may have a good brick until you can
restore it.
“Mark Roddy” wrote in message news:xxxxx@ntdev…
> >
> > Well, EFI will provide the hardware abstraction layer that is
> > currently provided by products like VMWare.
> >
>
> I must be as dense as Arlie
>
> EFI is a bios replacement and does little if anything after booting to
a
> real OS. VmWare is a minimal but real OS that provides sets of
‘virtual
> machines’ that in turn run various flavors of operating systems.
Microsoft
> is busy rolling out their Virtual PC competition for VmWare. Are you
sure
> there is much of any connection between EFI and virtual machine
technology?
>
>
>
>
The connection has to do with drivers and hardware abstraction done in the
BIOS and not in the OS. This makes the OS more portable and achieves some of
the functionality that is achieved with VMWare via its hardware
virtualization/abstraction layer. VMWare uses OS drivers on the HOST (which
are machine dependent) and it has is own proxy interfaces to communicate
with these drivers via their own VGA, SCSI, etc… driver.
EFI is not going to provide CPU and machine virtualization (as-is), but goes
a long way to making the OS hardware independent. This will be a god-send
for backup and restore applications. There are tons of opportunities in the
world of EFI. As I said in my first posting from last week, EFI will help
virtualization products like VMWare.
Jamey Kirby, Windows DDK MVP
StorageCraft Inc.
xxxxx@storagecraft.com
http://www.storagecraft.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David J. Craig
Sent: Tuesday, December 30, 2003 3:07 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] An interesting artibcle on EFI
I think things like encryption of the boot disk will be possible. You
can put anything in EFI from diagnostics to solitaire if you want. You
probably need access to the Intel examples and maybe how Microsoft plans
to interface with EFI during boot to know what it can or will do for
[to] you. Blow the EFI and you may have a good brick until you can
restore it.
“Mark Roddy” wrote in message news:xxxxx@ntdev…
> >
> > Well, EFI will provide the hardware abstraction layer that is
> > currently provided by products like VMWare.
> >
>
> I must be as dense as Arlie
>
> EFI is a bios replacement and does little if anything after booting to
a
> real OS. VmWare is a minimal but real OS that provides sets of
‘virtual
> machines’ that in turn run various flavors of operating systems.
Microsoft
> is busy rolling out their Virtual PC competition for VmWare. Are you
sure
> there is much of any connection between EFI and virtual machine
technology?
>
>
>
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Arlie and Mark are closer to the truth. EFI is mostly about boot firmware.
The EFI runtime services are largely equivalent to what you would find in a
typical server BIOS, except that they are far less tied to traditional PC
architecture.
I imagine that some of the people on this list have writen BIOS option ROMs
for PCI or (E)ISA adapters. If so, you’ve experienced the pain that that
involves, what with trying to cram your ROM into the PC-legacy memory,
discovering your adapter on secondary PCI root busses, figuring out the
machine’s memory map, etc. EFI rationalizes those.
Now, with that said, BIOS companies, including Intel, are always looking to
expand what the BIOS does, simply because it’s way easier for them to
deliver services within a medium that they control completely. This is the
same market force that will continue to cause my employer to try to deliver
services that are purely a part of the OS.
Full disclosure: No Microsoft lawyer has read this post. So it may come to
pass that these views are regarded as something other than the company party
line. It is true, however, that I’m involved in many of the decisions that
Microsoft makes with regard to BIOS, EFI, ACPI and firmware in general. I
wrote significant sections of the NT boot loader, both for x86 and for the
now-dead PowerPC port of NT, where I actually made NT boot from Open
Firmware, an EFI competitor. The guy who currently does all of the boot
code, including all the EFI stuff, sits directly across the hall from me.
–
Jake Oshins
Windows Base Kernel Team
This posting is provided “AS IS” with no warranties, and confers no rights.
“Jamey Kirby” wrote in message news:xxxxx@ntdev…
> The connection has to do with drivers and hardware abstraction done in the
> BIOS and not in the OS. This makes the OS more portable and achieves some
of
> the functionality that is achieved with VMWare via its hardware
> virtualization/abstraction layer. VMWare uses OS drivers on the HOST
(which
> are machine dependent) and it has is own proxy interfaces to communicate
> with these drivers via their own VGA, SCSI, etc… driver.
>
> EFI is not going to provide CPU and machine virtualization (as-is), but
goes
> a long way to making the OS hardware independent. This will be a god-send
> for backup and restore applications. There are tons of opportunities in
the
> world of EFI. As I said in my first posting from last week, EFI will help
> virtualization products like VMWare.
>
> Jamey Kirby, Windows DDK MVP
> StorageCraft Inc.
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of David J. Craig
> Sent: Tuesday, December 30, 2003 3:07 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] An interesting artibcle on EFI
>
> I think things like encryption of the boot disk will be possible. You
> can put anything in EFI from diagnostics to solitaire if you want. You
> probably need access to the Intel examples and maybe how Microsoft plans
> to interface with EFI during boot to know what it can or will do for
> [to] you. Blow the EFI and you may have a good brick until you can
> restore it.
>
> “Mark Roddy” wrote in message news:xxxxx@ntdev…
> > >
> > > Well, EFI will provide the hardware abstraction layer that is
> > > currently provided by products like VMWare.
> > >
> >
> > I must be as dense as Arlie
> >
> > EFI is a bios replacement and does little if anything after booting to
> a
> > real OS. VmWare is a minimal but real OS that provides sets of
> ‘virtual
> > machines’ that in turn run various flavors of operating systems.
> Microsoft
> > is busy rolling out their Virtual PC competition for VmWare. Are you
> sure
> > there is much of any connection between EFI and virtual machine
> technology?
> >
> >
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
Thanks for the posting. Maybe my impression of EFI is something different. I
was under the impression that hardware developers would write EFI drivers
for the hardware; like video and SCIS. EFI then provides an interface to
these devices through a common mechanism. I was also under the impression
that this would eliminate the need for many hardware specific drivers in the
OS; making the OS more portable.
From what I have read, EFI drivers are a new form of a PE executable.
I will be very disappointed if my assessment of EFI and its future is wrong.
One project I was going to consider working on was a mechanism to allow
Windows SCSI miniport drivers to be ported to EFI drivers. I though that an
EFI iSCSI client driver would be useful thing to have as well.
Regards,
Jamey Kirby, Windows DDK MVP
StorageCraft Inc.
xxxxx@storagecraft.com
http://www.storagecraft.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jake Oshins
Sent: Tuesday, December 30, 2003 10:24 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] An interesting artibcle on EFI
Arlie and Mark are closer to the truth. EFI is mostly about boot firmware.
The EFI runtime services are largely equivalent to what you would find in a
typical server BIOS, except that they are far less tied to traditional PC
architecture.
I imagine that some of the people on this list have writen BIOS option ROMs
for PCI or (E)ISA adapters. If so, you’ve experienced the pain that that
involves, what with trying to cram your ROM into the PC-legacy memory,
discovering your adapter on secondary PCI root busses, figuring out the
machine’s memory map, etc. EFI rationalizes those.
Now, with that said, BIOS companies, including Intel, are always looking to
expand what the BIOS does, simply because it’s way easier for them to
deliver services within a medium that they control completely. This is the
same market force that will continue to cause my employer to try to deliver
services that are purely a part of the OS.
Full disclosure: No Microsoft lawyer has read this post. So it may come to
pass that these views are regarded as something other than the company party
line. It is true, however, that I’m involved in many of the decisions that
Microsoft makes with regard to BIOS, EFI, ACPI and firmware in general. I
wrote significant sections of the NT boot loader, both for x86 and for the
now-dead PowerPC port of NT, where I actually made NT boot from Open
Firmware, an EFI competitor. The guy who currently does all of the boot
code, including all the EFI stuff, sits directly across the hall from me.
–
Jake Oshins
Windows Base Kernel Team
This posting is provided “AS IS” with no warranties, and confers no rights.
“Jamey Kirby” wrote in message news:xxxxx@ntdev…
> The connection has to do with drivers and hardware abstraction done in the
> BIOS and not in the OS. This makes the OS more portable and achieves some
of
> the functionality that is achieved with VMWare via its hardware
> virtualization/abstraction layer. VMWare uses OS drivers on the HOST
(which
> are machine dependent) and it has is own proxy interfaces to communicate
> with these drivers via their own VGA, SCSI, etc… driver.
>
> EFI is not going to provide CPU and machine virtualization (as-is), but
goes
> a long way to making the OS hardware independent. This will be a god-send
> for backup and restore applications. There are tons of opportunities in
the
> world of EFI. As I said in my first posting from last week, EFI will help
> virtualization products like VMWare.
>
> Jamey Kirby, Windows DDK MVP
> StorageCraft Inc.
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of David J. Craig
> Sent: Tuesday, December 30, 2003 3:07 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] An interesting artibcle on EFI
>
> I think things like encryption of the boot disk will be possible. You
> can put anything in EFI from diagnostics to solitaire if you want. You
> probably need access to the Intel examples and maybe how Microsoft plans
> to interface with EFI during boot to know what it can or will do for
> [to] you. Blow the EFI and you may have a good brick until you can
> restore it.
>
> “Mark Roddy” wrote in message news:xxxxx@ntdev…
> > >
> > > Well, EFI will provide the hardware abstraction layer that is
> > > currently provided by products like VMWare.
> > >
> >
> > I must be as dense as Arlie
> >
> > EFI is a bios replacement and does little if anything after booting to
> a
> > real OS. VmWare is a minimal but real OS that provides sets of
> ‘virtual
> > machines’ that in turn run various flavors of operating systems.
> Microsoft
> > is busy rolling out their Virtual PC competition for VmWare. Are you
> sure
> > there is much of any connection between EFI and virtual machine
> technology?
> >
> >
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
All of it is true up until the statement “… this would eliminate the
need for many hardware specific drivers in the OS.” The EFI drivers are
merely there to bootstrap the OS. You can’t boot unless you can read
the disk, or the net, or the fabric, etc.
Please remember the experience of the people who invented I2O. They
were trying to make disk (and other) subsystems more independent,
offloading all the work onto dedicated processors. In the process, they
were moving most of the storage driver into firmware, making the OS more
portable, etc. Some of their ideas were very good, and the average
throughput of disk subsystems (if my memory serves) went up when the
companies involved incorportated some of the constraints of I20 (like
avoiding most interrupts, etc.) But in the end, no company ended up
investing in the firmware interfaces, simply because they leveled the
playing field. This wasn’t solely a Microsoft phenomenon. All of the
RAID vendors realized that they could squeeze more performance out of
their devices when the OS-native drivers talked directly to the
hardware, simply because they got to plug into the OS in a way that was
suited to them. When they used the I2O firmware, they had yet another
layer to conform to, restricting design flexibility. In the end, all of
these “I2O-ready” hardware designs shipped without actual I2O
compliance, since it didn’t serve their market.
All of this applies even more strongly when you’re trying to use system
firmware, rather than firmware in a RAID subsystem, since you have to
use the main processor to run system firmware. This tends to have to
happen with interrupts either disabled or deferred, as no firmware
system is easily re-entrant. (Even if it is designed to be re-entrant,
the people developing it can rarely test it with all imaginable OS
behaviors.) The consequence of this would be running the
firmware-driven devices at what amounts to IRQL = HIGH_LEVEL, which
strongly restricts how the OS can use it. All of the people interested
in performance would reject it. And even for devices which are
low-bandwidth, the real-time world would reject it because the RT
scheduler wouldn’t be able to work.
–
Jake Oshins
Windows Base Kernel Team
This posting is provided “AS IS” with no warranties, and confers no
rights.
-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Tuesday, December 30, 2003 11:09 PM
To: ‘Windows System Software Devs Interest List’
Cc: Jake Oshins
Subject: RE: [ntdev] An interesting artibcle on EFI
Thanks for the posting. Maybe my impression of EFI is something
different. I
was under the impression that hardware developers would write EFI
drivers
for the hardware; like video and SCIS. EFI then provides an interface to
these devices through a common mechanism. I was also under the
impression
that this would eliminate the need for many hardware specific drivers in
the
OS; making the OS more portable.
From what I have read, EFI drivers are a new form of a PE executable.
I will be very disappointed if my assessment of EFI and its future is
wrong.
One project I was going to consider working on was a mechanism to allow
Windows SCSI miniport drivers to be ported to EFI drivers. I though that
an
EFI iSCSI client driver would be useful thing to have as well.
Regards,
Jamey Kirby, Windows DDK MVP
StorageCraft Inc.
xxxxx@storagecraft.com
http://www.storagecraft.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jake Oshins
Sent: Tuesday, December 30, 2003 10:24 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] An interesting artibcle on EFI
Arlie and Mark are closer to the truth. EFI is mostly about boot
firmware.
The EFI runtime services are largely equivalent to what you would find
in a
typical server BIOS, except that they are far less tied to traditional
PC
architecture.
I imagine that some of the people on this list have writen BIOS option
ROMs
for PCI or (E)ISA adapters. If so, you’ve experienced the pain that
that
involves, what with trying to cram your ROM into the PC-legacy memory,
discovering your adapter on secondary PCI root busses, figuring out the
machine’s memory map, etc. EFI rationalizes those.
Now, with that said, BIOS companies, including Intel, are always looking
to
expand what the BIOS does, simply because it’s way easier for them to
deliver services within a medium that they control completely. This is
the
same market force that will continue to cause my employer to try to
deliver
services that are purely a part of the OS.
Full disclosure: No Microsoft lawyer has read this post. So it may
come to
pass that these views are regarded as something other than the company
party
line. It is true, however, that I’m involved in many of the decisions
that
Microsoft makes with regard to BIOS, EFI, ACPI and firmware in general.
I
wrote significant sections of the NT boot loader, both for x86 and for
the
now-dead PowerPC port of NT, where I actually made NT boot from Open
Firmware, an EFI competitor. The guy who currently does all of the boot
code, including all the EFI stuff, sits directly across the hall from
me.
–
Jake Oshins
Windows Base Kernel Team
This posting is provided “AS IS” with no warranties, and confers no
rights.
“Jamey Kirby” wrote in message
news:xxxxx@ntdev…
> The connection has to do with drivers and hardware abstraction done in
the
> BIOS and not in the OS. This makes the OS more portable and achieves
some
of
> the functionality that is achieved with VMWare via its hardware
> virtualization/abstraction layer. VMWare uses OS drivers on the HOST
(which
> are machine dependent) and it has is own proxy interfaces to
communicate
> with these drivers via their own VGA, SCSI, etc… driver.
>
> EFI is not going to provide CPU and machine virtualization (as-is),
but
goes
> a long way to making the OS hardware independent. This will be a
god-send
> for backup and restore applications. There are tons of opportunities
in
the
> world of EFI. As I said in my first posting from last week, EFI will
help
> virtualization products like VMWare.
>
> Jamey Kirby, Windows DDK MVP
> StorageCraft Inc.
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of David J. Craig
> Sent: Tuesday, December 30, 2003 3:07 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] An interesting artibcle on EFI
>
> I think things like encryption of the boot disk will be possible. You
> can put anything in EFI from diagnostics to solitaire if you want.
You
> probably need access to the Intel examples and maybe how Microsoft
plans
> to interface with EFI during boot to know what it can or will do for
> [to] you. Blow the EFI and you may have a good brick until you can
> restore it.
>
> “Mark Roddy” wrote in message
news:xxxxx@ntdev…
> > >
> > > Well, EFI will provide the hardware abstraction layer that is
> > > currently provided by products like VMWare.
> > >
> >
> > I must be as dense as Arlie
> >
> > EFI is a bios replacement and does little if anything after booting
to
> a
> > real OS. VmWare is a minimal but real OS that provides sets of
> ‘virtual
> > machines’ that in turn run various flavors of operating systems.
> Microsoft
> > is busy rolling out their Virtual PC competition for VmWare. Are you
> sure
> > there is much of any connection between EFI and virtual machine
> technology?
> >
> >
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
With the current Flash memory sizes, you don’t need to boot from
an I/O device any longer. Just burn a microkernel into the Flash.
That microkernel could include a dispatcher, a basic messaging
system, and an embrio of a directory capability, and it would of
course include all the boot drivers, at least their lowest level: the
rest of the drivers can sit on upper layers in the driver stack.
A natural extension of this way of thinking is, the microkernel could
come pre-burned into the processor module from the processor
manufacturer. Anything that runs in Ring 0 would be required to be
in that module - updates would use the flash programmability and
could be done automatically without user intervention.
A further thought would be, well, let’s make an ANSI standard for a
flash-resident microkernel, so that any hardware manufacturer can
implement their own, no more massive involutions hogging ring 0
functionality. That would become a common engine spec for all
processor manufacturers, and it would move the rest of the OS to
where it belongs: outside ring 0 and into a collection of processes
interacting with each other through the microkernel message
passing subsystem.
I don’t know, it may be that I’m getting old, but I have the distinct
feeling that OS technology has frozen in the year 1970 or so. Just
about everything I see today in our contemporary OS’s I remember
having seeing it in Multics or in some vintage 1970’s mainframe.
It’s about time we move forward !
Alberto.
===============
On 30 Dec 2003 at 23:26, Jake Oshins wrote:
All of it is true up until the statement “… this would eliminate the
need for many hardware specific drivers in the OS.” The EFI drivers
are merely there to bootstrap the OS. You can’t boot unless you can
read the disk, or the net, or the fabric, etc.Please remember the experience of the people who invented I2O. They
were trying to make disk (and other) subsystems more independent,
offloading all the work onto dedicated processors. In the process,
they were moving most of the storage driver into firmware, making the
OS more portable, etc. Some of their ideas were very good, and the
average throughput of disk subsystems (if my memory serves) went up
when the companies involved incorportated some of the constraints of
I20 (like avoiding most interrupts, etc.) But in the end, no company
ended up investing in the firmware interfaces, simply because they
leveled the playing field. This wasn’t solely a Microsoft phenomenon.
All of the RAID vendors realized that they could squeeze more
performance out of their devices when the OS-native drivers talked
directly to the hardware, simply because they got to plug into the OS
in a way that was suited to them. When they used the I2O firmware,
they had yet another layer to conform to, restricting design
flexibility. In the end, all of these “I2O-ready” hardware designs
shipped without actual I2O compliance, since it didn’t serve their
market.All of this applies even more strongly when you’re trying to use
system firmware, rather than firmware in a RAID subsystem, since you
have to use the main processor to run system firmware. This tends to
have to happen with interrupts either disabled or deferred, as no
firmware system is easily re-entrant. (Even if it is designed to be
re-entrant, the people developing it can rarely test it with all
imaginable OS behaviors.) The consequence of this would be running
the firmware-driven devices at what amounts to IRQL = HIGH_LEVEL,
which strongly restricts how the OS can use it. All of the people
interested in performance would reject it. And even for devices which
are low-bandwidth, the real-time world would reject it because the RT
scheduler wouldn’t be able to work.–
Jake Oshins
Windows Base Kernel TeamThis posting is provided “AS IS” with no warranties, and confers no
rights.-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Tuesday, December 30, 2003 11:09 PM
To: ‘Windows System Software Devs Interest List’
Cc: Jake Oshins
Subject: RE: [ntdev] An interesting artibcle on EFIThanks for the posting. Maybe my impression of EFI is something
different. I
was under the impression that hardware developers would write EFI
drivers for the hardware; like video and SCIS. EFI then provides an
interface to these devices through a common mechanism. I was also
under the impression that this would eliminate the need for many
hardware specific drivers in the OS; making the OS more portable.From what I have read, EFI drivers are a new form of a PE executable.
I will be very disappointed if my assessment of EFI and its future is
wrong. One project I was going to consider working on was a mechanism
to allow Windows SCSI miniport drivers to be ported to EFI drivers. I
though that an EFI iSCSI client driver would be useful thing to have
as well.Regards,
Jamey Kirby, Windows DDK MVP
StorageCraft Inc.
xxxxx@storagecraft.com
http://www.storagecraft.com-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jake Oshins
Sent: Tuesday, December 30, 2003 10:24 PM To: Windows System Software
Devs Interest List Subject: Re:[ntdev] An interesting artibcle on EFIArlie and Mark are closer to the truth. EFI is mostly about boot
firmware. The EFI runtime services are largely equivalent to what you
would find in a typical server BIOS, except that they are far less
tied to traditional PC architecture.I imagine that some of the people on this list have writen BIOS option
ROMs for PCI or (E)ISA adapters. If so, you’ve experienced the pain
that that involves, what with trying to cram your ROM into the
PC-legacy memory, discovering your adapter on secondary PCI root
busses, figuring out the machine’s memory map, etc. EFI rationalizes
those.Now, with that said, BIOS companies, including Intel, are always
looking to expand what the BIOS does, simply because it’s way easier
for them to deliver services within a medium that they control
completely. This is the same market force that will continue to cause
my employer to try to deliver services that are purely a part of the
OS.Full disclosure: No Microsoft lawyer has read this post. So it may
come to pass that these views are regarded as something other than the
company party line. It is true, however, that I’m involved in many of
the decisions that Microsoft makes with regard to BIOS, EFI, ACPI and
firmware in general. I wrote significant sections of the NT boot
loader, both for x86 and for the now-dead PowerPC port of NT, where I
actually made NT boot from Open Firmware, an EFI competitor. The guy
who currently does all of the boot code, including all the EFI stuff,
sits directly across the hall from me.–
Jake Oshins
Windows Base Kernel TeamThis posting is provided “AS IS” with no warranties, and confers no
rights.“Jamey Kirby” wrote in message
> news:xxxxx@ntdev…
> > The connection has to do with drivers and hardware abstraction done
> > in
> the
> > BIOS and not in the OS. This makes the OS more portable and achieves
> some
> of
> > the functionality that is achieved with VMWare via its hardware
> > virtualization/abstraction layer. VMWare uses OS drivers on the HOST
> (which
> > are machine dependent) and it has is own proxy interfaces to
> communicate
> > with these drivers via their own VGA, SCSI, etc… driver.
> >
> > EFI is not going to provide CPU and machine virtualization (as-is),
> but
> goes
> > a long way to making the OS hardware independent. This will be a
> god-send
> > for backup and restore applications. There are tons of opportunities
> in
> the
> > world of EFI. As I said in my first posting from last week, EFI will
> help
> > virtualization products like VMWare.
> >
> > Jamey Kirby, Windows DDK MVP
> > StorageCraft Inc.
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of David J.
> > Craig Sent: Tuesday, December 30, 2003 3:07 PM To: Windows System
> > Software Devs Interest List Subject: Re:[ntdev] An interesting
> > artibcle on EFI
> >
> > I think things like encryption of the boot disk will be possible.
> > You can put anything in EFI from diagnostics to solitaire if you
> > want.
> You
> > probably need access to the Intel examples and maybe how Microsoft
> plans
> > to interface with EFI during boot to know what it can or will do for
> > [to] you. Blow the EFI and you may have a good brick until you can
> > restore it.
> >
> > “Mark Roddy” wrote in message
> news:xxxxx@ntdev…
> > > >
> > > > Well, EFI will provide the hardware abstraction layer that is
> > > > currently provided by products like VMWare.
> > > >
> > >
> > > I must be as dense as Arlie
> > >
> > > EFI is a bios replacement and does little if anything after
> > > booting
> to
> > a
> > > real OS. VmWare is a minimal but real OS that provides sets of
> > ‘virtual
> > > machines’ that in turn run various flavors of operating systems.
> > Microsoft
> > > is busy rolling out their Virtual PC competition for VmWare. Are
> > > you
> > sure
> > > there is much of any connection between EFI and virtual machine
> > technology?
> > >
> > >
> > >
> > >
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to xxxxx@lists.osr.com
Well, I dare to comment on this, since my own flash is very dated :)…
— There were some OS changes went in after 1970s, the native VM of IBM
mainframe, so CMS, CICS for example could run simultaniously, if I could
recall !!!
— Total microkernel did not get to its sucess during early eighties, due
to layering and performance hit. Back in 1987/8 time frame, OS/2 was hit by
this. In the 90s NT pumped down quite a bit of its GDI to kernel service in
4.0 version to speed up the user experience, and
NEXT os still fighting a chance to get into Mac as I heard around here…
BUT TIME HAS CHANGED DUE TO IC PERFORMANCE, BUT THEN DEMAND ALSO CHANGED,
for example high quality A/V streaming, multicasting etc…
— There are os for small devices, that are following the ROM/RAM type
stuff you mentioned here. The Rom updates, and OS configurability ( what
goes and what not …) is very much in places for these type of embedded OS,
be it symbian or Palm or CE or embedded linux or C-PEN. But one can say they
are toy OS, and sure they are compare to todays PC server, but still the
idea started, and might someday find the road to enterprise class os like NT
…
Happy new year to all you folks !
–prokash
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of xxxxx@ieee.org
Sent: Wednesday, December 31, 2003 6:10 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] An interesting artibcle on EFI
With the current Flash memory sizes, you don’t need to boot from
an I/O device any longer. Just burn a microkernel into the Flash.
That microkernel could include a dispatcher, a basic messaging
system, and an embrio of a directory capability, and it would of
course include all the boot drivers, at least their lowest level: the
rest of the drivers can sit on upper layers in the driver stack.
A natural extension of this way of thinking is, the microkernel could
come pre-burned into the processor module from the processor
manufacturer. Anything that runs in Ring 0 would be required to be
in that module - updates would use the flash programmability and
could be done automatically without user intervention.
A further thought would be, well, let’s make an ANSI standard for a
flash-resident microkernel, so that any hardware manufacturer can
implement their own, no more massive involutions hogging ring 0
functionality. That would become a common engine spec for all
processor manufacturers, and it would move the rest of the OS to
where it belongs: outside ring 0 and into a collection of processes
interacting with each other through the microkernel message
passing subsystem.
I don’t know, it may be that I’m getting old, but I have the distinct
feeling that OS technology has frozen in the year 1970 or so. Just
about everything I see today in our contemporary OS’s I remember
having seeing it in Multics or in some vintage 1970’s mainframe.
It’s about time we move forward !
Alberto.
===============
On 30 Dec 2003 at 23:26, Jake Oshins wrote:
All of it is true up until the statement “… this would eliminate the
need for many hardware specific drivers in the OS.” The EFI drivers
are merely there to bootstrap the OS. You can’t boot unless you can
read the disk, or the net, or the fabric, etc.Please remember the experience of the people who invented I2O. They
were trying to make disk (and other) subsystems more independent,
offloading all the work onto dedicated processors. In the process,
they were moving most of the storage driver into firmware, making the
OS more portable, etc. Some of their ideas were very good, and the
average throughput of disk subsystems (if my memory serves) went up
when the companies involved incorportated some of the constraints of
I20 (like avoiding most interrupts, etc.) But in the end, no company
ended up investing in the firmware interfaces, simply because they
leveled the playing field. This wasn’t solely a Microsoft phenomenon.
All of the RAID vendors realized that they could squeeze more
performance out of their devices when the OS-native drivers talked
directly to the hardware, simply because they got to plug into the OS
in a way that was suited to them. When they used the I2O firmware,
they had yet another layer to conform to, restricting design
flexibility. In the end, all of these “I2O-ready” hardware designs
shipped without actual I2O compliance, since it didn’t serve their
market.All of this applies even more strongly when you’re trying to use
system firmware, rather than firmware in a RAID subsystem, since you
have to use the main processor to run system firmware. This tends to
have to happen with interrupts either disabled or deferred, as no
firmware system is easily re-entrant. (Even if it is designed to be
re-entrant, the people developing it can rarely test it with all
imaginable OS behaviors.) The consequence of this would be running
the firmware-driven devices at what amounts to IRQL = HIGH_LEVEL,
which strongly restricts how the OS can use it. All of the people
interested in performance would reject it. And even for devices which
are low-bandwidth, the real-time world would reject it because the RT
scheduler wouldn’t be able to work.–
Jake Oshins
Windows Base Kernel TeamThis posting is provided “AS IS” with no warranties, and confers no
rights.-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Tuesday, December 30, 2003 11:09 PM
To: ‘Windows System Software Devs Interest List’
Cc: Jake Oshins
Subject: RE: [ntdev] An interesting artibcle on EFIThanks for the posting. Maybe my impression of EFI is something
different. I
was under the impression that hardware developers would write EFI
drivers for the hardware; like video and SCIS. EFI then provides an
interface to these devices through a common mechanism. I was also
under the impression that this would eliminate the need for many
hardware specific drivers in the OS; making the OS more portable.From what I have read, EFI drivers are a new form of a PE executable.
I will be very disappointed if my assessment of EFI and its future is
wrong. One project I was going to consider working on was a mechanism
to allow Windows SCSI miniport drivers to be ported to EFI drivers. I
though that an EFI iSCSI client driver would be useful thing to have
as well.Regards,
Jamey Kirby, Windows DDK MVP
StorageCraft Inc.
xxxxx@storagecraft.com
http://www.storagecraft.com-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jake Oshins
Sent: Tuesday, December 30, 2003 10:24 PM To: Windows System Software
Devs Interest List Subject: Re:[ntdev] An interesting artibcle on EFIArlie and Mark are closer to the truth. EFI is mostly about boot
firmware. The EFI runtime services are largely equivalent to what you
would find in a typical server BIOS, except that they are far less
tied to traditional PC architecture.I imagine that some of the people on this list have writen BIOS option
ROMs for PCI or (E)ISA adapters. If so, you’ve experienced the pain
that that involves, what with trying to cram your ROM into the
PC-legacy memory, discovering your adapter on secondary PCI root
busses, figuring out the machine’s memory map, etc. EFI rationalizes
those.Now, with that said, BIOS companies, including Intel, are always
looking to expand what the BIOS does, simply because it’s way easier
for them to deliver services within a medium that they control
completely. This is the same market force that will continue to cause
my employer to try to deliver services that are purely a part of the
OS.Full disclosure: No Microsoft lawyer has read this post. So it may
come to pass that these views are regarded as something other than the
company party line. It is true, however, that I’m involved in many of
the decisions that Microsoft makes with regard to BIOS, EFI, ACPI and
firmware in general. I wrote significant sections of the NT boot
loader, both for x86 and for the now-dead PowerPC port of NT, where I
actually made NT boot from Open Firmware, an EFI competitor. The guy
who currently does all of the boot code, including all the EFI stuff,
sits directly across the hall from me.–
Jake Oshins
Windows Base Kernel TeamThis posting is provided “AS IS” with no warranties, and confers no
rights.“Jamey Kirby” wrote in message
> news:xxxxx@ntdev…
> > The connection has to do with drivers and hardware abstraction done
> > in
> the
> > BIOS and not in the OS. This makes the OS more portable and achieves
> some
> of
> > the functionality that is achieved with VMWare via its hardware
> > virtualization/abstraction layer. VMWare uses OS drivers on the HOST
> (which
> > are machine dependent) and it has is own proxy interfaces to
> communicate
> > with these drivers via their own VGA, SCSI, etc… driver.
> >
> > EFI is not going to provide CPU and machine virtualization (as-is),
> but
> goes
> > a long way to making the OS hardware independent. This will be a
> god-send
> > for backup and restore applications. There are tons of opportunities
> in
> the
> > world of EFI. As I said in my first posting from last week, EFI will
> help
> > virtualization products like VMWare.
> >
> > Jamey Kirby, Windows DDK MVP
> > StorageCraft Inc.
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of David J.
> > Craig Sent: Tuesday, December 30, 2003 3:07 PM To: Windows System
> > Software Devs Interest List Subject: Re:[ntdev] An interesting
> > artibcle on EFI
> >
> > I think things like encryption of the boot disk will be possible.
> > You can put anything in EFI from diagnostics to solitaire if you
> > want.
> You
> > probably need access to the Intel examples and maybe how Microsoft
> plans
> > to interface with EFI during boot to know what it can or will do for
> > [to] you. Blow the EFI and you may have a good brick until you can
> > restore it.
> >
> > “Mark Roddy” wrote in message
> news:xxxxx@ntdev…
> > > >
> > > > Well, EFI will provide the hardware abstraction layer that is
> > > > currently provided by products like VMWare.
> > > >
> > >
> > > I must be as dense as Arlie
> > >
> > > EFI is a bios replacement and does little if anything after
> > > booting
> to
> > a
> > > real OS. VmWare is a minimal but real OS that provides sets of
> > ‘virtual
> > > machines’ that in turn run various flavors of operating systems.
> > Microsoft
> > > is busy rolling out their Virtual PC competition for VmWare. Are
> > > you
> > sure
> > > there is much of any connection between EFI and virtual machine
> > technology?
> > >
> > >
> > >
> > >
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@garlic.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
I like parts of this idea, but it unnecessarily ties together too many
things.
EFI & BIOS address system boot-strapping. They have nothing to do with
what happens after an OS is up and running. Design issues like
micro-kernel vs. monolithic are NOT something that EFI should be dealing
with. A bootstrap system should not mandate any specific kernel design.
Flash memory is now big enough to contain an entire boot loader and
nearly everything it needs. Personally, I would like to see “boot
sectors” on hard drives go away. We should have a flash memory module
soldered to the motherboard, and it should contain the equivalent of
NTLDR, NTDETECT.COM, BOOT.INI, and even NTBOOTDD.SYS if necessary. It
should also contain a simple read-only implementation of whatever
filesystem the OS is stored on, be it FAT, NTFS, whatever.
This would solve all sorts of problems, like which drive/partition is
the system disk (it’s stored in BOOT.INI in flash memory), boot device
drivers, etc. The boot code could also allow you to try to boot
arbitrary partitions, or boot from removable media, etc. It’s also an
ideal place for diagnostics code, such as the “recovery console” (which
kicks ass!) in recent versions.
The Linux people are already doing this. They simply write an entire
compressed Linux kernel into existing 2M flash modules, including
default command-line arguments. Boot-times are astonishingly low.
There are lots of problems with this, of course – since you’ve blown
away the system BIOS, you don’t have any control over chipset-specific
features. But it’s still a good idea.
– arlie
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@ieee.org
Sent: Wednesday, December 31, 2003 9:10 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] An interesting artibcle on EFI
With the current Flash memory sizes, you don’t need to boot from
an I/O device any longer. Just burn a microkernel into the Flash.
That microkernel could include a dispatcher, a basic messaging
system, and an embrio of a directory capability, and it would of
course include all the boot drivers, at least their lowest level: the
rest of the drivers can sit on upper layers in the driver stack.
A natural extension of this way of thinking is, the microkernel could
come pre-burned into the processor module from the processor
manufacturer. Anything that runs in Ring 0 would be required to be
in that module - updates would use the flash programmability and
could be done automatically without user intervention.
A further thought would be, well, let’s make an ANSI standard for a
flash-resident microkernel, so that any hardware manufacturer can
implement their own, no more massive involutions hogging ring 0
functionality. That would become a common engine spec for all
processor manufacturers, and it would move the rest of the OS to
where it belongs: outside ring 0 and into a collection of processes
interacting with each other through the microkernel message
passing subsystem.
I don’t know, it may be that I’m getting old, but I have the distinct
feeling that OS technology has frozen in the year 1970 or so. Just
about everything I see today in our contemporary OS’s I remember
having seeing it in Multics or in some vintage 1970’s mainframe.
It’s about time we move forward !
Alberto.
===============
On 30 Dec 2003 at 23:26, Jake Oshins wrote:
All of it is true up until the statement "… this would eliminate the
need for many hardware specific drivers in the OS." The EFI drivers
are merely there to bootstrap the OS. You can’t boot unless you can
read the disk, or the net, or the fabric, etc.Please remember the experience of the people who invented I2O. They
were trying to make disk (and other) subsystems more independent,
offloading all the work onto dedicated processors. In the process,
they were moving most of the storage driver into firmware, making the
OS more portable, etc. Some of their ideas were very good, and the
average throughput of disk subsystems (if my memory serves) went up
when the companies involved incorportated some of the constraints of
I20 (like avoiding most interrupts, etc.) But in the end, no company
ended up investing in the firmware interfaces, simply because they
leveled the playing field. This wasn’t solely a Microsoft phenomenon.
All of the RAID vendors realized that they could squeeze more
performance out of their devices when the OS-native drivers talked
directly to the hardware, simply because they got to plug into the OS
in a way that was suited to them. When they used the I2O firmware,
they had yet another layer to conform to, restricting design
flexibility. In the end, all of these “I2O-ready” hardware designs
shipped without actual I2O compliance, since it didn’t serve their
market.All of this applies even more strongly when you’re trying to use
system firmware, rather than firmware in a RAID subsystem, since you
have to use the main processor to run system firmware. This tends to
have to happen with interrupts either disabled or deferred, as no
firmware system is easily re-entrant. (Even if it is designed to be
re-entrant, the people developing it can rarely test it with all
imaginable OS behaviors.) The consequence of this would be running
the firmware-driven devices at what amounts to IRQL = HIGH_LEVEL,
which strongly restricts how the OS can use it. All of the people
interested in performance would reject it. And even for devices which
are low-bandwidth, the real-time world would reject it because the RT
scheduler wouldn’t be able to work.–
Jake Oshins
Windows Base Kernel TeamThis posting is provided “AS IS” with no warranties, and confers no
rights.-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Tuesday, December 30, 2003 11:09 PM
To: ‘Windows System Software Devs Interest List’
Cc: Jake Oshins
Subject: RE: [ntdev] An interesting artibcle on EFIThanks for the posting. Maybe my impression of EFI is something
different. I was under the impression that hardware developers would
write EFI drivers for the hardware; like video and SCIS. EFI then
provides an interface to these devices through a common mechanism. I
was also under the impression that this would eliminate the need for
many hardware specific drivers in the OS; making the OS more portable.From what I have read, EFI drivers are a new form of a PE executable.
I will be very disappointed if my assessment of EFI and its future is
wrong. One project I was going to consider working on was a mechanism
to allow Windows SCSI miniport drivers to be ported to EFI drivers. I
though that an EFI iSCSI client driver would be useful thing to have
as well.Regards,
Jamey Kirby, Windows DDK MVP
StorageCraft Inc.
xxxxx@storagecraft.com
http://www.storagecraft.com-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jake Oshins
Sent: Tuesday, December 30, 2003 10:24 PM To: Windows System Software
Devs Interest List Subject: Re:[ntdev] An interesting artibcle on EFIArlie and Mark are closer to the truth. EFI is mostly about boot
firmware. The EFI runtime services are largely equivalent to what you
would find in a typical server BIOS, except that they are far less
tied to traditional PC architecture.I imagine that some of the people on this list have writen BIOS option
ROMs for PCI or (E)ISA adapters. If so, you’ve experienced the pain
that that involves, what with trying to cram your ROM into the
PC-legacy memory, discovering your adapter on secondary PCI root
busses, figuring out the machine’s memory map, etc. EFI rationalizes
those.Now, with that said, BIOS companies, including Intel, are always
looking to expand what the BIOS does, simply because it’s way easier
for them to deliver services within a medium that they control
completely. This is the same market force that will continue to cause
my employer to try to deliver services that are purely a part of the
OS.Full disclosure: No Microsoft lawyer has read this post. So it may
come to pass that these views are regarded as something other than the
company party line. It is true, however, that I’m involved in many of
the decisions that Microsoft makes with regard to BIOS, EFI, ACPI and
firmware in general. I wrote significant sections of the NT boot
loader, both for x86 and for the now-dead PowerPC port of NT, where I
actually made NT boot from Open Firmware, an EFI competitor. The guy
who currently does all of the boot code, including all the EFI stuff,
sits directly across the hall from me.–
Jake Oshins
Windows Base Kernel TeamThis posting is provided “AS IS” with no warranties, and confers no
rights.“Jamey Kirby” wrote in message
> news:xxxxx@ntdev…
> > The connection has to do with drivers and hardware abstraction done
> > in
> the
> > BIOS and not in the OS. This makes the OS more portable and achieves
> some
> of
> > the functionality that is achieved with VMWare via its hardware
> > virtualization/abstraction layer. VMWare uses OS drivers on the HOST
> (which
> > are machine dependent) and it has is own proxy interfaces to
> communicate
> > with these drivers via their own VGA, SCSI, etc… driver.
> >
> > EFI is not going to provide CPU and machine virtualization (as-is),
> but
> goes
> > a long way to making the OS hardware independent. This will be a
> god-send
> > for backup and restore applications. There are tons of opportunities
> in
> the
> > world of EFI. As I said in my first posting from last week, EFI will
> help
> > virtualization products like VMWare.
> >
> > Jamey Kirby, Windows DDK MVP
> > StorageCraft Inc.
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of David J.
> > Craig Sent: Tuesday, December 30, 2003 3:07 PM To: Windows System
> > Software Devs Interest List Subject: Re:[ntdev] An interesting
> > artibcle on EFI
> >
> > I think things like encryption of the boot disk will be possible.
> > You can put anything in EFI from diagnostics to solitaire if you
> > want.
> You
> > probably need access to the Intel examples and maybe how Microsoft
> plans
> > to interface with EFI during boot to know what it can or will do for
> > [to] you. Blow the EFI and you may have a good brick until you can
> > restore it.
> >
> > “Mark Roddy” wrote in message
> news:xxxxx@ntdev…
> > > >
> > > > Well, EFI will provide the hardware abstraction layer that is
> > > > currently provided by products like VMWare.
> > > >
> > >
> > > I must be as dense as Arlie
> > >
> > > EFI is a bios replacement and does little if anything after
> > > booting
> to
> > a
> > > real OS. VmWare is a minimal but real OS that provides sets of
> > ‘virtual
> > > machines’ that in turn run various flavors of operating systems.
> > Microsoft
> > > is busy rolling out their Virtual PC competition for VmWare. Are
> > > you
> > sure
> > > there is much of any connection between EFI and virtual machine
> > technology?
> > >
> > >
> > >
> > >
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org To
> unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@sublinear.org To
unsubscribe send a blank email to xxxxx@lists.osr.com
Wish it could be that simple. However, dynamic memory cannot be used
until it has been written to at least several times. If the memory is
parity or ECC memory, with MB support for it, the parity interrupts must
be disabled via a special command until the memory can be stabilized.
That is because memory parity uses NMI for the parity error interrupt.
You may also need chipset support in where various PCI slots are
located. I think each PCI bus can only have four or so slots, therefore
additional PCI slots are on secondary busses. How to number those slots
is very chipset specific and many people don’t allow the OS to configure
the devices by setting the OS as ‘non-PnP’ via the BIOS setup program.
I still do it that way, though I think most of the old problems may have
been solved, but how does Windows know about the chipset if you are
installing and haven’t had a chance to load the specific chipset driver?
I think the EFI and the GUID partition table are a start in solving your
requirements. It makes sense, but may make moving the hard drive to
another machine more difficult. Identical machines can swap hard
drives, but if the GUID is randomly generated when the drive is
formatted and EFI knows about that GUID, can it be moved? I am still
looking at EFI when time presents itself - which is not very often since
I don’t have a EFI compatible computer. Some good ideas coming, but the
largest vendor, Phoenix, still hasn’t jumped on the EFI bandwagon so
far. I have to admit that the BIOS code has have become an interesting
plate of spaghetti unless the vendors have allowed the time and
resources to do some complete redesign and rewrite in the last few
years. I still refer to the old IBM source listings that were published
for the XT & AT. Intel tells you how the chipsets can be programmed,
but seldom indicate how they are actually programmed in the PC world. I
remember trying to understand the 8259a PIC many years ago and the IBM
listings were invaluable.
“Arlie Davis” wrote in message news:xxxxx@ntdev…
> I like parts of this idea, but it unnecessarily ties together too many
> things.
>
> EFI & BIOS address system boot-strapping. They have nothing to do
with
> what happens after an OS is up and running. Design issues like
> micro-kernel vs. monolithic are NOT something that EFI should be
dealing
> with. A bootstrap system should not mandate any specific kernel
design.
>
> Flash memory is now big enough to contain an entire boot loader and
> nearly everything it needs. Personally, I would like to see “boot
> sectors” on hard drives go away. We should have a flash memory module
> soldered to the motherboard, and it should contain the equivalent of
> NTLDR, NTDETECT.COM, BOOT.INI, and even NTBOOTDD.SYS if necessary. It
> should also contain a simple read-only implementation of whatever
> filesystem the OS is stored on, be it FAT, NTFS, whatever.
>
> This would solve all sorts of problems, like which drive/partition is
> the system disk (it’s stored in BOOT.INI in flash memory), boot device
> drivers, etc. The boot code could also allow you to try to boot
> arbitrary partitions, or boot from removable media, etc. It’s also an
> ideal place for diagnostics code, such as the “recovery console”
(which
> kicks ass!) in recent versions.
>
> The Linux people are already doing this. They simply write an entire
> compressed Linux kernel into existing 2M flash modules, including
> default command-line arguments. Boot-times are astonishingly low.
> There are lots of problems with this, of course – since you’ve blown
> away the system BIOS, you don’t have any control over chipset-specific
> features. But it’s still a good idea.
>
> – arlie
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@ieee.org
> Sent: Wednesday, December 31, 2003 9:10 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] An interesting artibcle on EFI
>
>
> With the current Flash memory sizes, you don’t need to boot from
> an I/O device any longer. Just burn a microkernel into the Flash.
> That microkernel could include a dispatcher, a basic messaging
> system, and an embrio of a directory capability, and it would of
> course include all the boot drivers, at least their lowest level: the
> rest of the drivers can sit on upper layers in the driver stack.
>
> A natural extension of this way of thinking is, the microkernel could
> come pre-burned into the processor module from the processor
> manufacturer. Anything that runs in Ring 0 would be required to be
> in that module - updates would use the flash programmability and
> could be done automatically without user intervention.
>
> A further thought would be, well, let’s make an ANSI standard for a
> flash-resident microkernel, so that any hardware manufacturer can
> implement their own, no more massive involutions hogging ring 0
> functionality. That would become a common engine spec for all
> processor manufacturers, and it would move the rest of the OS to
> where it belongs: outside ring 0 and into a collection of processes
> interacting with each other through the microkernel message
> passing subsystem.
>
> I don’t know, it may be that I’m getting old, but I have the distinct
> feeling that OS technology has frozen in the year 1970 or so. Just
> about everything I see today in our contemporary OS’s I remember
> having seeing it in Multics or in some vintage 1970’s mainframe.
> It’s about time we move forward !
>
> Alberto.
>
> ===============
>
>
> On 30 Dec 2003 at 23:26, Jake Oshins wrote:
>
> > All of it is true up until the statement “… this would eliminate
the
>
> > need for many hardware specific drivers in the OS.” The EFI drivers
> > are merely there to bootstrap the OS. You can’t boot unless you can
> > read the disk, or the net, or the fabric, etc.
> >
> > Please remember the experience of the people who invented I2O. They
> > were trying to make disk (and other) subsystems more independent,
> > offloading all the work onto dedicated processors. In the process,
> > they were moving most of the storage driver into firmware, making
the
> > OS more portable, etc. Some of their ideas were very good, and the
> > average throughput of disk subsystems (if my memory serves) went up
> > when the companies involved incorportated some of the constraints of
> > I20 (like avoiding most interrupts, etc.) But in the end, no
company
> > ended up investing in the firmware interfaces, simply because they
> > leveled the playing field. This wasn’t solely a Microsoft
phenomenon.
>
> > All of the RAID vendors realized that they could squeeze more
> > performance out of their devices when the OS-native drivers talked
> > directly to the hardware, simply because they got to plug into the
OS
> > in a way that was suited to them. When they used the I2O firmware,
> > they had yet another layer to conform to, restricting design
> > flexibility. In the end, all of these “I2O-ready” hardware designs
> > shipped without actual I2O compliance, since it didn’t serve their
> > market.
> >
> > All of this applies even more strongly when you’re trying to use
> > system firmware, rather than firmware in a RAID subsystem, since you
> > have to use the main processor to run system firmware. This tends
to
> > have to happen with interrupts either disabled or deferred, as no
> > firmware system is easily re-entrant. (Even if it is designed to be
> > re-entrant, the people developing it can rarely test it with all
> > imaginable OS behaviors.) The consequence of this would be running
> > the firmware-driven devices at what amounts to IRQL = HIGH_LEVEL,
> > which strongly restricts how the OS can use it. All of the people
> > interested in performance would reject it. And even for devices
which
>
> > are low-bandwidth, the real-time world would reject it because the
RT
> > scheduler wouldn’t be able to work.
> >
> > –
> > Jake Oshins
> > Windows Base Kernel Team
> >
> > This posting is provided “AS IS” with no warranties, and confers no
> > rights.
> >
> >
> > -----Original Message-----
> > From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
> > Sent: Tuesday, December 30, 2003 11:09 PM
> > To: ‘Windows System Software Devs Interest List’
> > Cc: Jake Oshins
> > Subject: RE: [ntdev] An interesting artibcle on EFI
> >
> > Thanks for the posting. Maybe my impression of EFI is something
> > different. I was under the impression that hardware developers would
> > write EFI drivers for the hardware; like video and SCIS. EFI then
> > provides an interface to these devices through a common mechanism. I
> > was also under the impression that this would eliminate the need for
> > many hardware specific drivers in the OS; making the OS more
portable.
> >
> > From what I have read, EFI drivers are a new form of a PE
executable.
> >
> > I will be very disappointed if my assessment of EFI and its future
is
> > wrong. One project I was going to consider working on was a
mechanism
> > to allow Windows SCSI miniport drivers to be ported to EFI drivers.
I
> > though that an EFI iSCSI client driver would be useful thing to have
> > as well.
> >
> > Regards,
> >
> > Jamey Kirby, Windows DDK MVP
> > StorageCraft Inc.
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Jake Oshins
> > Sent: Tuesday, December 30, 2003 10:24 PM To: Windows System
Software
> > Devs Interest List Subject: Re:[ntdev] An interesting artibcle on
EFI
> >
> > Arlie and Mark are closer to the truth. EFI is mostly about boot
> > firmware. The EFI runtime services are largely equivalent to what
you
> > would find in a typical server BIOS, except that they are far less
> > tied to traditional PC architecture.
> >
> > I imagine that some of the people on this list have writen BIOS
option
>
> > ROMs for PCI or (E)ISA adapters. If so, you’ve experienced the pain
> > that that involves, what with trying to cram your ROM into the
> > PC-legacy memory, discovering your adapter on secondary PCI root
> > busses, figuring out the machine’s memory map, etc. EFI
rationalizes
> > those.
> >
> > Now, with that said, BIOS companies, including Intel, are always
> > looking to expand what the BIOS does, simply because it’s way easier
> > for them to deliver services within a medium that they control
> > completely. This is the same market force that will continue to
cause
>
> > my employer to try to deliver services that are purely a part of the
> > OS.
> >
> > Full disclosure: No Microsoft lawyer has read this post. So it may
> > come to pass that these views are regarded as something other than
the
>
> > company party line. It is true, however, that I’m involved in many
of
>
> > the decisions that Microsoft makes with regard to BIOS, EFI, ACPI
and
> > firmware in general. I wrote significant sections of the NT boot
> > loader, both for x86 and for the now-dead PowerPC port of NT, where
I
> > actually made NT boot from Open Firmware, an EFI competitor. The
guy
> > who currently does all of the boot code, including all the EFI
stuff,
> > sits directly across the hall from me.
> >
> > –
> > Jake Oshins
> > Windows Base Kernel Team
> >
> > This posting is provided “AS IS” with no warranties, and confers no
> > rights.
> >
> > “Jamey Kirby” wrote in message
> > news:xxxxx@ntdev…
> > > The connection has to do with drivers and hardware abstraction
done
> > > in
> > the
> > > BIOS and not in the OS. This makes the OS more portable and
achieves
> > some
> > of
> > > the functionality that is achieved with VMWare via its hardware
> > > virtualization/abstraction layer. VMWare uses OS drivers on the
HOST
> > (which
> > > are machine dependent) and it has is own proxy interfaces to
> > communicate
> > > with these drivers via their own VGA, SCSI, etc… driver.
> > >
> > > EFI is not going to provide CPU and machine virtualization
(as-is),
> > but
> > goes
> > > a long way to making the OS hardware independent. This will be a
> > god-send
> > > for backup and restore applications. There are tons of
opportunities
> > in
> > the
> > > world of EFI. As I said in my first posting from last week, EFI
will
> > help
> > > virtualization products like VMWare.
> > >
> > > Jamey Kirby, Windows DDK MVP
> > > StorageCraft Inc.
> > > xxxxx@storagecraft.com
> > > http://www.storagecraft.com
> > >
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of David J.
> > > Craig Sent: Tuesday, December 30, 2003 3:07 PM To: Windows System
> > > Software Devs Interest List Subject: Re:[ntdev] An interesting
> > > artibcle on EFI
> > >
> > > I think things like encryption of the boot disk will be possible.
> > > You can put anything in EFI from diagnostics to solitaire if you
> > > want.
> > You
> > > probably need access to the Intel examples and maybe how Microsoft
> > plans
> > > to interface with EFI during boot to know what it can or will do
for
>
> > > [to] you. Blow the EFI and you may have a good brick until you
can
> > > restore it.
> > >
> > > “Mark Roddy” wrote in message
> > news:xxxxx@ntdev…
> > > > >
> > > > > Well, EFI will provide the hardware abstraction layer that is
> > > > > currently provided by products like VMWare.
> > > > >
> > > >
> > > > I must be as dense as Arlie
> > > >
> > > > EFI is a bios replacement and does little if anything after
> > > > booting
> > to
> > > a
> > > > real OS. VmWare is a minimal but real OS that provides sets of
> > > ‘virtual
> > > > machines’ that in turn run various flavors of operating systems.
> > > Microsoft
> > > > is busy rolling out their Virtual PC competition for VmWare. Are
> > > > you
> > > sure
> > > > there is much of any connection between EFI and virtual machine
> > > technology?
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To
>
> > > unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> > >
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@ieee.org To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@sublinear.org To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> for example high quality A/V streaming, multicasting etc…
DirectShow solves both.
be it symbian or Palm or CE or embedded linux or C-PEN.
C-PEN is abysmal. They still use the serial port instead of USB.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
From horse’s mouth I heard there are some performance problem ( or potential
performance enhancement needed) in the area of conferencing recently
introduced in windows xp server family …
Hay C-PEN uses infra-red :). Actually my point was the booting from flash
has been around for a while. Most of the embedded system(s) under
construction these days like to have it as options. And as we know, fat is
very much in demand, may be that is why there is 25 cents charge per device
or something, and imagine billions of embedded devices …
-prokash
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
Sent: Wednesday, December 31, 2003 3:34 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] An interesting artibcle on EFI
for example high quality A/V streaming, multicasting etc…
DirectShow solves both.
be it symbian or Palm or CE or embedded linux or C-PEN.
C-PEN is abysmal. They still use the serial port instead of USB.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@garlic.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
> located. I think each PCI bus can only have four or so slots, therefore
The “good old” Asus CUSL2 (i815 chipset) has 6 slots off the single PCI bus 2.
The bus 0 in the internal bus going to south bridge only, and the bus 1 is AGP.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> Hay C-PEN uses infra-red :).
Yes, but why not USB? Not all notebooks have IrDA, but every one has USB.
Actually my point was the booting from flash
Having a special flash drive inside the PC to boot the OS is possibly the good
idea.
Windows can put NTLDR there, Linux can put “initrd” there.
After this, the hard disk must only have the SystemRoot directory set up and
fine.
And now note this will add the manufacturing cost of the PC without any real
“hand-sensible” value
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> Hay C-PEN uses infra-red :).
Yes, but why not USB? Not all notebooks have IrDA, but every one has USB.
Yep, they should have either USB or Firewire …
Actually my point was the booting from flash
Having a special flash drive inside the PC to boot the OS is possibly the
good
idea.
Windows can put NTLDR there, Linux can put “initrd” there.
After this, the hard disk must only have the SystemRoot directory set up and
fine.
And now note this will add the manufacturing cost of the PC without any real
“hand-sensible” value
Well, it depends on howmuch convenience it gets using it, then couple bucks
might not be a factor. But again, agreed…
-prokash
> Yes, but why not USB? Not all notebooks have IrDA, but every one has USB.
Yep, they should have either USB or Firewire …
I saw notebooks without IrDA, but never without USB and/or 1394. I mean modern
notebooks (Pentium 3+) for sure.
Well, it depends on howmuch convenience it gets using it, then couple bucks
might not be a factor. But again, agreed…
Most users use 1 OS. The one most usable. For now - and for foreseeable
future - it is Windows.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
You wouldn’t need to have the OS on a hard drive, so, partition would no longer
need to exist. All the flash system needs to know is the disk geometry. The OS
could be distributed in compact flash or similar. Also, the chipset would belong to
the flash and it shouldn’t be visible from the outside except via a compact API. Only
the hardware manufacturer would need to know the hardware detail of the
motherboard.
Alberto.
On 31 Dec 2003 at 17:38, David J. Craig wrote:
Wish it could be that simple. However, dynamic memory cannot be used
until it has been written to at least several times. If the memory is
parity or ECC memory, with MB support for it, the parity interrupts
must be disabled via a special command until the memory can be
stabilized. That is because memory parity uses NMI for the parity
error interrupt.You may also need chipset support in where various PCI slots are
located. I think each PCI bus can only have four or so slots,
therefore additional PCI slots are on secondary busses. How to number
those slots is very chipset specific and many people don’t allow the
OS to configure the devices by setting the OS as ‘non-PnP’ via the
BIOS setup program. I still do it that way, though I think most of the
old problems may have been solved, but how does Windows know about the
chipset if you are installing and haven’t had a chance to load the
specific chipset driver?I think the EFI and the GUID partition table are a start in solving
your requirements. It makes sense, but may make moving the hard drive
to another machine more difficult. Identical machines can swap hard
drives, but if the GUID is randomly generated when the drive is
formatted and EFI knows about that GUID, can it be moved? I am still
looking at EFI when time presents itself - which is not very often
since I don’t have a EFI compatible computer. Some good ideas coming,
but the largest vendor, Phoenix, still hasn’t jumped on the EFI
bandwagon so far. I have to admit that the BIOS code has have become
an interesting plate of spaghetti unless the vendors have allowed the
time and resources to do some complete redesign and rewrite in the
last few years. I still refer to the old IBM source listings that
were published for the XT & AT. Intel tells you how the chipsets can
be programmed, but seldom indicate how they are actually programmed in
the PC world. I remember trying to understand the 8259a PIC many
years ago and the IBM listings were invaluable.“Arlie Davis” wrote in message
> news:xxxxx@ntdev… > I like parts of this idea, but it unnecessarily
> ties together too many > things. > > EFI & BIOS address system
> boot-strapping. They have nothing to do with > what happens after an
> OS is up and running. Design issues like > micro-kernel vs.
> monolithic are NOT something that EFI should be dealing > with. A
> bootstrap system should not mandate any specific kernel design. > >
> Flash memory is now big enough to contain an entire boot loader and >
> nearly everything it needs. Personally, I would like to see “boot >
> sectors” on hard drives go away. We should have a flash memory module
> > soldered to the motherboard, and it should contain the equivalent of
> > NTLDR, NTDETECT.COM, BOOT.INI, and even NTBOOTDD.SYS if necessary.
> It > should also contain a simple read-only implementation of whatever
> > filesystem the OS is stored on, be it FAT, NTFS, whatever. > > This
> would solve all sorts of problems, like which drive/partition is > the
> system disk (it’s stored in BOOT.INI in flash memory), boot device >
> drivers, etc. The boot code could also allow you to try to boot >
> arbitrary partitions, or boot from removable media, etc. It’s also an
> > ideal place for diagnostics code, such as the “recovery console”
> (which > kicks ass!) in recent versions. > > The Linux people are
> already doing this. They simply write an entire > compressed Linux
> kernel into existing 2M flash modules, including > default
> command-line arguments. Boot-times are astonishingly low. > There are
> lots of problems with this, of course – since you’ve blown > away the
> system BIOS, you don’t have any control over chipset-specific >
> features. But it’s still a good idea. > > – arlie > > > >
> -----Original Message----- > From: xxxxx@lists.osr.com >
> [mailto:xxxxx@lists.osr.com] On Behalf Of >
> xxxxx@ieee.org > Sent: Wednesday, December 31, 2003 9:10 AM > To:
> Windows System Software Devs Interest List > Subject: RE: [ntdev] An
> interesting artibcle on EFI > > > With the current Flash memory sizes,
> you don’t need to boot from > an I/O device any longer. Just burn a
> microkernel into the Flash. > That microkernel could include a
> dispatcher, a basic messaging > system, and an embrio of a directory
> capability, and it would of > course include all the boot drivers, at
> least their lowest level: the > rest of the drivers can sit on upper
> layers in the driver stack. > > A natural extension of this way of
> thinking is, the microkernel could > come pre-burned into the
> processor module from the processor > manufacturer. Anything that runs
> in Ring 0 would be required to be > in that module - updates would use
> the flash programmability and > could be done automatically without
> user intervention. > > A further thought would be, well, let’s make an
> ANSI standard for a > flash-resident microkernel, so that any hardware
> manufacturer can > implement their own, no more massive involutions
> hogging ring 0 > functionality. That would become a common engine spec
> for all > processor manufacturers, and it would move the rest of the
> OS to > where it belongs: outside ring 0 and into a collection of
> processes > interacting with each other through the microkernel
> message > passing subsystem. > > I don’t know, it may be that I’m
> getting old, but I have the distinct > feeling that OS technology has
> frozen in the year 1970 or so. Just > about everything I see today in
> our contemporary OS’s I remember > having seeing it in Multics or in
> some vintage 1970’s mainframe. > It’s about time we move forward ! > >
> Alberto. > > =============== > > > On 30 Dec 2003 at 23:26, Jake
> Oshins wrote: > > > All of it is true up until the statement “… this
> would eliminate the > > > need for many hardware specific drivers in
> the OS.” The EFI drivers > > are merely there to bootstrap the OS.
> You can’t boot unless you can > > read the disk, or the net, or the
> fabric, etc. > > > > Please remember the experience of the people who
> invented I2O. They > > were trying to make disk (and other)
> subsystems more independent, > > offloading all the work onto
> dedicated processors. In the process, > > they were moving most of
> the storage driver into firmware, making the > > OS more portable,
> etc. Some of their ideas were very good, and the > > average
> throughput of disk subsystems (if my memory serves) went up > > when
> the companies involved incorportated some of the constraints of > >
> I20 (like avoiding most interrupts, etc.) But in the end, no company
> > > ended up investing in the firmware interfaces, simply because they
> > > leveled the playing field. This wasn’t solely a Microsoft
> phenomenon. > > > All of the RAID vendors realized that they could
> squeeze more > > performance out of their devices when the OS-native
> drivers talked > > directly to the hardware, simply because they got
> to plug into the OS > > in a way that was suited to them. When they
> used the I2O firmware, > > they had yet another layer to conform to,
> restricting design > > flexibility. In the end, all of these
> “I2O-ready” hardware designs > > shipped without actual I2O
> compliance, since it didn’t serve their > > market. > > > > All of
> this applies even more strongly when you’re trying to use > > system
> firmware, rather than firmware in a RAID subsystem, since you > > have
> to use the main processor to run system firmware. This tends to > >
> have to happen with interrupts either disabled or deferred, as no > >
> firmware system is easily re-entrant. (Even if it is designed to be >
> > re-entrant, the people developing it can rarely test it with all > >
> imaginable OS behaviors.) The consequence of this would be running >
> > the firmware-driven devices at what amounts to IRQL = HIGH_LEVEL, >
> > which strongly restricts how the OS can use it. All of the people >
> > interested in performance would reject it. And even for devices
> which > > > are low-bandwidth, the real-time world would reject it
> because the RT > > scheduler wouldn’t be able to work. > > > > – > >
> Jake Oshins > > Windows Base Kernel Team > > > > This posting is
> provided “AS IS” with no warranties, and confers no > > rights. > > >
> > > > -----Original Message----- > > From: Jamey Kirby
> [mailto:xxxxx@storagecraft.com] > > Sent: Tuesday, December 30, 2003
> 11:09 PM > > To: ‘Windows System Software Devs Interest List’ > > Cc:
> Jake Oshins > > Subject: RE: [ntdev] An interesting artibcle on EFI >
> > > > Thanks for the posting. Maybe my impression of EFI is something
> > > different. I was under the impression that hardware developers
> would > > write EFI drivers for the hardware; like video and SCIS. EFI
> then > > provides an interface to these devices through a common
> mechanism. I > > was also under the impression that this would
> eliminate the need for > > many hardware specific drivers in the OS;
> making the OS more portable. > > > > From what I have read, EFI
> drivers are a new form of a PE executable. > > > > I will be very
> disappointed if my assessment of EFI and its future is > > wrong. One
> project I was going to consider working on was a mechanism > > to
> allow Windows SCSI miniport drivers to be ported to EFI drivers. I > >
> though that an EFI iSCSI client driver would be useful thing to have >
> > as well. > > > > Regards, > > > > Jamey Kirby, Windows DDK MVP > >
> StorageCraft Inc. > > xxxxx@storagecraft.com > >
> http://www.storagecraft.com > > > > > > > > > > > > -----Original
> Message----- > > From: xxxxx@lists.osr.com > >
> [mailto:xxxxx@lists.osr.com] On Behalf Of Jake Oshins >
> > Sent: Tuesday, December 30, 2003 10:24 PM To: Windows System
> Software > > Devs Interest List Subject: Re:[ntdev] An interesting
> artibcle on EFI > > > > Arlie and Mark are closer to the truth. EFI
> is mostly about boot > > firmware. The EFI runtime services are
> largely equivalent to what you > > would find in a typical server
> BIOS, except that they are far less > > tied to traditional PC
> architecture. > > > > I imagine that some of the people on this list
> have writen BIOS option > > > ROMs for PCI or (E)ISA adapters. If so,
> you’ve experienced the pain > > that that involves, what with trying
> to cram your ROM into the > > PC-legacy memory, discovering your
> adapter on secondary PCI root > > busses, figuring out the machine’s
> memory map, etc. EFI rationalizes > > those. > > > > Now, with that
> said, BIOS companies, including Intel, are always > > looking to
> expand what the BIOS does, simply because it’s way easier > > for them
> to deliver services within a medium that they control > > completely.
> This is the same market force that will continue to cause > > > my
> employer to try to deliver services that are purely a part of the > >
> OS. > > > > Full disclosure: No Microsoft lawyer has read this post.
> So it may > > come to pass that these views are regarded as something
> other than the > > > company party line. It is true, however, that
> I’m involved in many of > > > the decisions that Microsoft makes with
> regard to BIOS, EFI, ACPI and > > firmware in general. I wrote
> significant sections of the NT boot > > loader, both for x86 and for
> the now-dead PowerPC port of NT, where I > > actually made NT boot
> from Open Firmware, an EFI competitor. The guy > > who currently does
> all of the boot code, including all the EFI stuff, > > sits directly
> across the hall from me. > > > > – > > Jake Oshins > > Windows Base
> Kernel Team > > > > This posting is provided “AS IS” with no
> warranties, and confers no > > rights. > > > > “Jamey Kirby”
> wrote in message > > news:xxxxx@ntdev… > >
> > The connection has to do with drivers and hardware abstraction done
> > > > in > > the > > > BIOS and not in the OS. This makes the OS more
> portable and achieves > > some > > of > > > the functionality that is
> achieved with VMWare via its hardware > > > virtualization/abstraction
> layer. VMWare uses OS drivers on the HOST > > (which > > > are machine
> dependent) and it has is own proxy interfaces to > > communicate > > >
> with these drivers via their own VGA, SCSI, etc… driver. > > > > > >
> EFI is not going to provide CPU and machine virtualization (as-is), >
> > but > > goes > > > a long way to making the OS hardware independent.
> This will be a > > god-send > > > for backup and restore applications.
> There are tons of opportunities > > in > > the > > > world of EFI. As
> I said in my first posting from last week, EFI will > > help > > >
> virtualization products like VMWare. > > > > > > Jamey Kirby, Windows
> DDK MVP > > > StorageCraft Inc. > > > xxxxx@storagecraft.com > > >
> http://www.storagecraft.com > > > > > > > > > > > > > > > > > >
> -----Original Message----- > > > From:
> xxxxx@lists.osr.com > > >
> [mailto:xxxxx@lists.osr.com] On Behalf Of David J. > > >
> Craig Sent: Tuesday, December 30, 2003 3:07 PM To: Windows System > >
> > Software Devs Interest List Subject: Re:[ntdev] An interesting > > >
> artibcle on EFI > > > > > > I think things like encryption of the boot
> disk will be possible. > > > You can put anything in EFI from
> diagnostics to solitaire if you > > > want. > > You > > > probably
> need access to the Intel examples and maybe how Microsoft > > plans >
> > > to interface with EFI during boot to know what it can or will do
> for > > > > [to] you. Blow the EFI and you may have a good brick
> until you can > > > restore it. > > > > > > “Mark Roddy”
> wrote in message > > news:xxxxx@ntdev… > > >
> > > > > > > > Well, EFI will provide the hardware abstraction layer
> that is > > > > > currently provided by products like VMWare. > > > >
> > > > > > > > > > I must be as dense as Arlie
> is a bios replacement and does little if anything after > > > >
> booting > > to > > > a > > > > real OS. VmWare is a minimal but real
> OS that provides sets of > > > ‘virtual > > > > machines’ that in turn
> run various flavors of operating systems. > > > Microsoft > > > > is
> busy rolling out their Virtual PC competition for VmWare. Are > > > >
> you > > > sure > > > > there is much of any connection between EFI and
> virtual machine > > > technology? > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > — > > > Questions? First check the Kernel Driver
> FAQ at > > > http://www.osronline.com/article.cfm?id=256 > > > > > >
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com To >
> > > > unsubscribe send a blank email to
> xxxxx@lists.osr.com > > > > > > > > > > > > > > — > >
> Questions? First check the Kernel Driver FAQ at > >
> http://www.osronline.com/article.cfm?id=256 > > > > You are currently
> subscribed to ntdev as: xxxxx@storagecraft.com To > > unsubscribe
> send a blank email to xxxxx@lists.osr.com > > > > > > —
> > > Questions? First check the Kernel Driver FAQ at > >
> http://www.osronline.com/article.cfm?id=256 > > > > You are currently
> subscribed to ntdev as: xxxxx@ieee.org To > > unsubscribe send a
> blank email to xxxxx@lists.osr.com > > > > > — >
> Questions? First check the Kernel Driver FAQ at >
> http://www.osronline.com/article.cfm?id=256 > > You are currently
> subscribed to ntdev as: xxxxx@sublinear.org To > unsubscribe send a
> blank email to xxxxx@lists.osr.com > >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to xxxxx@lists.osr.com