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

[Bjorn Helgaas <bjorn.helgaas@hp.com>]

On Saturday 29 April 2006 03:04, Dave Airlie wrote:
> > This patch adds an "enable" sysfs attribute to each PCI device. When read it
> > shows the "enabled-ness" of the device, but you can write a "0" into it to
> > disable a device, and a "1" to enable it.
> >
> > This later is needed for X and other cases where userspace wants to enable
> > the BARs on a device (typical example: to run the video bios on a secundary
> > head). Right now X does all this "by hand" via bitbanging, that's just evil.
> > This allows X to no longer do that but to just let the kernel do this.

I'm all in favor of cleaning up X.  But making the X code prettier without
changing the underlying issues of claiming and sharing resources doesn't
help much.  In fact, I suspect the ultimate plan for X does not involve
an "enable" attribute in sysfs, so this may just introduce ABI cruft that
will be difficult to remove later.

> This would allow me to remove the issue in X where loading the DRM at X 
> startup acts differently than loading the DRM before X runs, due to Xs PCI 
> probe running in-between... with this I can just enable all VGA devices 
> and no worry whether they have a DRM or not..

This seems to be the main justification for the patch.  But I don't know
enough about X and DRM to understand it, or why this patch is the best
way to solve it.

I think Jon has a pretty convincing argument, which I *do* understand.
Can you expand on this justification?  Do you envision long-term usage
of the sysfs "enable" attribute?

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