Opened 11 years ago

Closed 11 years ago

#2073 closed bug (invalid)

User add-on driver does not have precedence over system add-on driver

Reported by: gerald zajac Owned by: axeld
Priority: normal Milestone: R1
Component: Drivers Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

If two drivers support the same device, the one installed as a user add-on should take precedence over the one installed as a system add-on. For example, if there is a video card with a Savage chipset, it will normally cause the s3savage driver which is installed as a system add-on to be loaded and used. However, if another driver named S3 supports the same chip and is installed as a user add-on, it should take precedence and be loaded and used instead of the system add-on driver, but this does not happen. The following lines from the syslog shows both driver are loaded, and the one installed as a system add-on is opened.

KERN: savage: init_hardware - device supported KERN: savage: probe_devices: match found; name: graphics/5333_8A22_010000 KERN: savage: probe_devices: 1 supported devices KERN: loaded driver /boot/beos/system/add-ons/kernel/drivers/dev/graphics/s3savage KERN: vesa: init_hardware() KERN: vesa: init_driver() KERN: vesa: publish_devices() KERN: vesa: find_device() KERN: loaded driver /boot/beos/system/add-ons/kernel/drivers/dev/graphics/vesa KERN: S3: init_hardware() - device supported KERN: S3: probe_devices(): match found; name: graphics/5333_8A22_010000 KERN: S3: probe_devices(): 1 supported devices KERN: loaded driver /boot/home/config/add-ons/kernel/drivers/dev/graphics/s3 KERN: savage: open_hook(graphics/5333_8A22_010000, 0x90d59e70)

Attachments (1)

syslog.txt (49.5 KB) - added by gerald zajac 11 years ago.
syslog with system & user add-on drivers with same link name

Download all attachments as: .zip

Change History (6)

comment:1 Changed 11 years ago by axeld

Sorry, I misunderstood you before: to have one driver take precedence over the other, they need to have the same name. Currently, there is no way for the system to know which hardware device is supported by a driver.

This will change with the new driver architecture. Is your problem still reproducible if both drivers are called the same?

comment:2 in reply to:  1 Changed 11 years ago by gerald zajac

Replying to axeld:

Sorry, I misunderstood you before: to have one driver take precedence over the other, they need to have the same name. Currently, there is no way for the system to know which hardware device is supported by a driver.

This will change with the new driver architecture. Is your problem still reproducible if both drivers are called the same?

I can use the same set up on BeOS and Zeta, and the user add-on S3 driver will be the driver which is used. Under BeOS I installed the s3savage driver as a system add-on; whereas, Zeta comes with a Savage driver name "savage" installed as a system add-on. In both cases, the user add-on S3 driver is used. The file name of the driver makes no difference; however, the name assigned to the device will determine which driver is used. If both drivers assign the same device name graphics/5333_8A22_010000, the user add-on driver is used; whereas, when I modified the S3 driver to assign a different name to the device by changing a character in the name, the system add-on driver was used under both BeOS and Zeta.

Changed 11 years ago by gerald zajac

Attachment: syslog.txt added

syslog with system & user add-on drivers with same link name

comment:3 in reply to:  1 ; Changed 11 years ago by gerald zajac

Replying to axeld:

Sorry, I misunderstood you before: to have one driver take precedence over the other, they need to have the same name. Currently, there is no way for the system to know which hardware device is supported by a driver.

This will change with the new driver architecture. Is your problem still reproducible if both drivers are called the same?

If I add a user add-on driver/accelerant which has the same file names as a system add-on, the user add-on driver/accelerant will be loaded and used.

However, if the file names are different but the link in /boot/home/config/add-ons/kernel/drivers/dev/graphics/ has the same name as the link in /boot/beos/system/add-ons/kernel/drivers/dev/graphics/, it uses the system add-on driver and the user add-on accelerant. See the attached syslog where the prefix for text from the driver & accelerant are different. The prefix for the system add-on is "savage"; whereas, the prefix for the user add-on is "savageX".

comment:4 in reply to:  3 Changed 11 years ago by gerald zajac

Replying to gerald zajac:

Replying to axeld:

Sorry, I misunderstood you before: to have one driver take precedence over the other, they need to have the same name. Currently, there is no way for the system to know which hardware device is supported by a driver.

This will change with the new driver architecture. Is your problem still reproducible if both drivers are called the same?

If I add a user add-on driver/accelerant which has the same file names as a system add-on, the user add-on driver/accelerant will be loaded and used.

However, if the file names are different but the link in /boot/home/config/add-ons/kernel/drivers/dev/graphics/ has the same name as the link in /boot/beos/system/add-ons/kernel/drivers/dev/graphics/, it uses the system add-on driver and the user add-on accelerant. See the attached syslog where the prefix for text from the driver & accelerant are different. The prefix for the system add-on is "savage"; whereas, the prefix for the user add-on is "savageX".

The first paragraph of my reply above to Axel's question is wrong. I ran the tests again, and found that the info in the second paragraph of my reply above applies if the file names are the same. The probable reason that I originally thought that the first paragraph was correct is that I had deleted the link in /boot/beos/system/add-ons/kernel/drivers/dev/graphics/ and had forgotten that I had deleted it. I apologize for my screw-up.

comment:5 Changed 11 years ago by axeld

Resolution: invalid
Status: newclosed
Note: See TracTickets for help on using tickets.