Drivers and linking...

Anything QL Software or Programming Related.
User avatar
Pr0f
QL Wafer Drive
Posts: 1298
Joined: Thu Oct 12, 2017 9:54 am

Re: Drivers and linking...

Post by Pr0f »

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...


Martin_Head
Aurora
Posts: 847
Joined: Tue Dec 17, 2013 1:17 pm

Re: Drivers and linking...

Post by Martin_Head »

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.


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Drivers and linking...

Post by tofro »

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_)


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Post Reply