Drivers and linking...

Anything QL Software or Programming Related.
User avatar
Pr0f
Gold Card
Posts: 287
Joined: Thu Oct 12, 2017 9:54 am

Re: Drivers and linking...

Postby Pr0f » Fri Jan 19, 2018 2:47 pm

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
Gold Card
Posts: 349
Joined: Tue Dec 17, 2013 1:17 pm

Re: Drivers and linking...

Postby Martin_Head » Sat Jan 20, 2018 10:53 am

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
QL Wafer Drive
Posts: 1438
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Drivers and linking...

Postby tofro » Sat Jan 20, 2018 11:40 am

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

Return to “Software & Programming”

Who is online

Users browsing this forum: No registered users and 2 guests