Re: Device Drivers and HAL
- From: "Paul Baker [MVP, Windows - SDK]" <paulrichardbaker@xxxxxxxxxxxxxxxx>
- Date: Thu, 16 Aug 2007 13:49:44 -0400
You mention the TEST UNIT READY command and LUN. Aren't these SCSI concepts?
What happens if it's an IDE drive? Or whatever other types of drive there
are these days that I don't know about ;)
Paul
"Maxim S. Shatskih" <maxim@xxxxxxxxxxxxxxxx> wrote in message
news:uPJoItC4HHA.3684@xxxxxxxxxxxxxxxxxxxxxxx
Suppose toaster controls CD-ROM device, I have no idea how
Samsung makes their CD-ROM drive and how Sony makes theirs.
All CD/DVD drives obey (with the tolerance of 95%) to MMC-5/6 spec.
Some (Pioneer and Asus) do obey the Mount Fuji spec, which has IIRC only 1
main
difference with MMC - the use of TEST UNIT READY pinging during CLOSE
TRACK/SESSION is not supported in MtFuji and is supported in MMC.
Some do have some firmware bugs - requiring a larger output buffer for
some
commands then prescribed by MMC, for instance - Panasonic with IIRC GET
CONFIGURATION command.
But most of this is related to CD/DVD burning, not to the CD/DVD reading
which
is nearly the same for all drives on the market (and, if some drive's
firmware
is buggy, then CdRom.sys has a workaround).
CdRom.sys only supports reading and audio control and not burning. Burning
is
done by handicrafting the SCSI requests without CdRom.sys (sometimes with
a
kernel mode helper, sometimes in user mode alone as Nero does) and then
sending
them to the storage LUN stack.
What made me write this post is right now I am studying HAL layer of
Windows OS. It seems drivers don't access devices directly, they go
through HAL.
Think of HAL as of platform-dependent part of the kernel.
The NTOSKRNL binary has only 4 flavours - SMP/UP and PAE/noPAE. NTOSKRNL
thus
cannot contain any code working with any system-level chipset hardware
except
the CPU itself. It cannot contain the code to work with interrupt
controllers
or timers.
HAL is mainly the second part of the kernel which provides the following:
a) all work with interrupt controller hardware
b) all work with timer hardware - I think that Windows kernel
architecturally
has 2 timers - main and performance - and their implementation is up to
HAL.
c) SMP CPU enumeration and startup (HalStartNextProcessor)
d) SMP interprocessor interrupts
e) final reboot/powerdown/shutdown code (HalReturnToFirmware)
f) WRITE_xxx_UCHAR and similar functions.
g) non-standard partition table layout support
In open-source OSes, the analog of HAL is just a build subtree of the
kernel
project, chosen at config time before building the kernel. Since Windows
ships
ready binaries, they have choses to only have 4 kernel binaries and
several
HALs - APIC/noAPIC, ACPI/noACPI and so on.
What is interesting for the drivers is item f) - WRITE_xxx_UCHAR
functions.
They do the hardware register access _in a way safe with the
hardware-platform-specific memory barriers_. Yes, in this sense "drivers
talk
to the hardware via HAL".
a device that, say, I make. How would HAL know how to begin to
interact with the device?
It only knows how to ensure that your driver's device accesses will be
executed
properly by the platform with proper memory barriers - i.e. by CPU+bus
bridges.
What are these accesses - is not the HAL's job.
made and adheres to all the PC and PCI hardware standards. How would
HAL know how to control and utilize this device if a device driver can
not directly access it?
It only knows how to execute your driver's register accesses properly. It
is
the driver which calls WRITE_xxx_USHORT or so, the HAL is a passive player
here.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@xxxxxxxxxxxxxxxx
http://www.storagecraft.com
.
- Follow-Ups:
- Re: Device Drivers and HAL
- From: Maxim S. Shatskih
- Re: Device Drivers and HAL
- References:
- Device Drivers and HAL
- From: one-trick-pony
- Re: Device Drivers and HAL
- From: Maxim S. Shatskih
- Device Drivers and HAL
- Prev by Date: Re: Device Drivers and HAL
- Next by Date: Re: Device Drivers and HAL
- Previous by thread: Re: Device Drivers and HAL
- Next by thread: Re: Device Drivers and HAL
- Index(es):
Relevant Pages
|