The Sinclair QL Forum

suffice it to say that during development of a new driver, using LRESPR to load it into the system would be the ideal way to get a new driver in and replace the old driver.

That should hopefully simplify things...

Pr0f wrote:suffice it to say that during development of a new driver, using LRESPR to load it into the system would be the ideal way to get a new driver in and replace the old driver.

That should hopefully simplify things...

Yes.

The old driver is not actually replaced. The new driver is placed at the end of the list of device drivers. And when the Operating System looks for a particular driver, it starts at the end of the list, and works towards the start. As your new driver is placed after the old driver, the system sees the new driver first, and abandons the search without getting to the old driver.

Martin_Head wrote:

Pr0f wrote:suffice it to say that during development of a new driver, using LRESPR to load it into the system would be the ideal way to get a new driver in and replace the old driver.

That should hopefully simplify things...

Yes.

The old driver is not actually replaced. The new driver is placed at the end of the list of device drivers. And when the Operating System looks for a particular driver, it starts at the end of the list, and works towards the start. As your new driver is placed after the old driver, the system sees the new driver first, and abandons the search without getting to the old driver.

It's actually the other way round, but that doesn't change much - The new driver is inserted at the beginning of the lists of interrupt, polling and scheduler interrupt servers and serial and directory device drivers that are pointed to by the system variables SV_I2LIST to SV_DDLIST.

When the system looks for a specific directory device driver during an OPEN call, it will search the SV_DDLIST linked list using the first characters of the name until it has a match and call this (and only this) driver's open routine.

When the system looks for a specific serial (serial not only referring to rs232, but rather anything that is character- rather than block-based) device driver during an OPEN call, it will search the SV_DRLIST linked list using the full name and call all driver's open routines in turn, until one either says "I feel responsible for the name, but it is wrong" or "open successful" (or the list is exhausted). Serial drivers thus have the option to partially override other drivers (like one driver for ser1_ and ser_2 overriden by another that handles ser3_)