Re: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access

[Jon Smirl]

On 5/2/06, Arjan van de Ven <arjan@xxxxxxxxxxxxxxx> wrote:
> you're very selective in what you read and only think about X.
> There's many other reasons to enable/disable devices post boot.
> Having a driver just to call pci_enable_device() is silly; and
> there are various scenarios you may want. Userland suspend/resume is
> only one of those, posting video cards is one, chip health monitoring is
> one, etc etc etc. Don't let your lack of imagination ruin things.

Allowing user space control of a device without a mechanism to assign
ownership of the device is a very bad idea. There is no way for one
user space program to tell if another is messing with the device.
There has to be a mechanism like opening the device to indicate which
process owns the device and is allowed to set their state into it (for
states that can conflict, enabling the device is definitely a state
that can conflict).

This attribute will also cause problem with existing drivers. Almost
every driver in the kernel will GPF if you disable the hardware on it
while the driver is loaded and active.  This problem has been the
result of numerous OOPses when X decides to disable hardware that
fbdev is using. I also can not see how user space suspend/resume can
disable PCI hardware without coordinating with an active device
driver.

The rule needs to be that if you want to use a device it has to have a
driver. Anything else results in chaos. It doesn't matter if these
drivers have a tiny API, their purpose is to control ownership of the
hardware.

You may call this silly but it is a real pain to spend hours debugging
code only to discover that it failed because some other app unknown to
you altered the state of the hardware while you were using it.

--
Jon Smirl
jonsmirl@xxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/