OSDev.org

Considering the fact that most kernels do not allow direct access to hardware by user programs how is it then possible to install device drivers at runtime, i.e plug 'n' play. If this is supported then that means that the HAL is modified in some way, isn't that so? so can this be a security problem in an OS?
Also how do Virtual Drivers work, I'm referring to programs such as Virtual CD, CD Ghost etc for Windows 9X/XP (btw does linux have some such programs? or do we use mknod etc to do this?)

For Plug'n'Play the kernel detects the hardware and then adds the driver. In an OS you have to rely on the fact that drivers will be well written. If they're not then the system probably won't work even if it doesn't crash.

Pete

You mean, accessing a hard drive file as if it were a CD-ROM?

The driver architecture is usually multi-leveled. For example, there was a tool for AmigaOS that allowed to virtually "write" to plain CD-ROM: On the filesystem level, it registered a new (logical) "device" (the "writeable" CD-ROM, think "drive letter" if you like). On the access level, it handled write access by writing files to hard drive, and read accesses by reading from CD-ROM unless the file in question was previously "written" to hard drive.

You see that there isn't even any real device driving involved; all that this "virtual CD driver" does is smartly delegating things.

The only real device stuff to be done is translating the generic read / write calls into whatever the hardware understands. Higher logic (like the "virtual CD" I described) can be done well inside user-land.



Check the web or other favourite source of info for "loopback device".

what about the first part of my question, anything on that?

The app doesn't access hardware

If you could explain that more it would be helpful. like how to register a new logical device (modify the partition table?) and how the access is trapped?

No, logical device, not logical partition...

Think an USB ZIP that is added at runtime.

The kernel detects the interrupt, or whatever heralds the addition of the USB ZIP to the system. It now looks up what driver is needed for the new device, loads the driver binary, and registers the new device with the driver system. "Add one read/write device, designate Sierra 4, to the array of available devices."

All the read/write device drivers translate a "device_read()" to the necessary bus action, likewise for a "device_write()". They have no idea of file systems etc. - they just take a defined interface (device_*()) and translate it to whatever device-specific magic is needed.

Now come the "layers". First, you'd like to make the drive accessible in some way - assign it a drive letter, or a mount point, or whatever your OS does with drives. Some magic that takes access to "ZIP:" and passes that to Sierra 4 in the array of read/write devices.

One level above that comes the file system. Since you usually don't do "read byte X to byte Y", but "read file Z", you need some code that keeps a catalog of the drive, and translates an fopen() / fscanf() to a series of read() calls to the ZIP: drive. (Translated by the access layer mentioned above.)

That's a rough layout. The details of this depend heavily on your OS architecture and your design of drive access.