Re: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access
From: Dave Airlie
Date: Tue May 02 2006 - 17:39:54 EST
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).
Jon stop being so dramatic, this is just like letting userspace map
the BARs, without ownership through sysfs, which is a good thing, you
can still map /dev/mem, look we have lots of ways to shoot ourselves
in the foot, if we *want* to.
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
Again we can already bypass device drivers.... so don't worry so much....
This attribute allows us to enable devices that X otherwise would hand
enable, that's all, it doesn't allow a user with vi to do it ....
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.
Again we have lots of ways for this to happen...
Now X is stupid don't get me wrong and sorry Bjorn it might still
enable/disable devices it doesn't use (unless configured with some
arcania in xorg.conf), but this at least is step 1, this should allow
me to remove all the PCI BAR modfiying code from the Linux code paths,
and to be honest that is a very good start, we still need some sort of
VGA arbitration (which is why X actually messes with cards it doesn't
know about, as it has to make sure everyone isn't decoding the VGA
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/