[lkml]   [2006]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access
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?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-05-04 21:12    [W:0.094 / U:17.712 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site