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

["Jon Smirl" <jonsmirl@gmail.com>]

On 5/5/06, Greg KH <greg@kroah.com> wrote:
> On Fri, May 05, 2006 at 04:35:17PM -0400, Jon Smirl wrote:
> > On 5/5/06, Greg KH <greg@kroah.com> wrote:
> > >On Fri, May 05, 2006 at 04:14:00PM -0400, Jon Smirl wrote:
> > >> 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.
> > >
> > >Who cares who "enabled" the device.  Remember, the majority of PCI
> > >devices in the system are not video ones.  Lots of other types of
> > >devices want this ability to enable PCI devices from userspace.  I've
> > >been talking with some people about how to properly write PCI drivers in
> > >userspace, and this attribute is a needed part of it.
> >
> > User space program enables the device.
> > Next I load a device driver
> > next I rmmod the device driver and it disables the device
> > user space program trys to use the device
> > No coordination and user space program faults
>
> Gun.  Foot.  Shoot.

Why do we want to create problem like this when there is a simple
solution to preventing them. All it takes is a couple of rules:

1) To use a device it must have a device driver. It may be as simple
as a couple of lines of code. This driver will cause a device node to
be created.

2) If a user app want to use the device it opens the device node.

This builds a system where everybody knows what is going on. The
driver knows that user space is using the device. Multiple user space
users are blocked from conflicting because of the open. There is no
way to shoot yourself in the foot.

--
Jon Smirl
jonsmirl@gmail.com
-
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/