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/5/06, Ian Romanick <idr@xxxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Peter Jones wrote:
> > On Thu, 2006-05-04 at 17:38 -0400, Jon Smirl wrote:
> >
> >># cd /sys/bus/pci/devices/0000:01:00.0
> >># echo 1 >rom
> >># hexdump -C rom
> >>
> >>As far as I know this works on every platform, not just the PC one.
> >
> > Yep, you're right, this works.  So we don't necessarily need it for the
> > vbetool case.  X still could use it though, instead of their scary
> > poke-at-memory way.
>
> Dave Airlie recently changed X to use sysfs for reading ROMs.  I'm also
> working on some changes to eliminate nearly all of the PCI bus poking
> that X does.  Search for "PCI rework" or "libpciaccess" in the xorg list
> archives.

What's the story with PCI VGA routing?

DaveA I were chatting about an alternative to 'enable' attribute. You
would make a VGA driver that isn't bound to any PCI IDs. After the
kernel boots a user space program uses sysfs/vga/new_id to load it
with PCI IDs for all PCI class = VGA hardware. Anything that doesn't
have a driver loaded will then get bound to this VGA driver. In
conjunction with the driver udev would make a device node appear.
Opening the new device node would enable the device and control
ownership. If you want to load a device specific driver later, set
sysfs/vga/unbind=1, load the new device specific driver, set
sysfs/vga/bind=1.

This scheme all works within existing kernel mechanisms and does not
require adding an 'enable' attribute. It also addresses the problem of
who owns the state in the hardware; the state is owned by whoever has
the device node open. If another app wants to mess with the hardware
it won't be able to open the device node.

I would like to see other design alternatives considered on this
issue. The 'enable' attribute has a clear problem in that you can't
tell which user space program is trying to control the device.
Multiple programs accessing the video hardware with poor coordination
is already the source of many problems.

--
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/