![]() | |||||||||||||
Messages in this thread |
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. > Don't say this can't happen, it is a current source of conflict > between X and fbdev. Not a PCI kernel issue :) > Should we just remove the ability to disable hardware? Huh? Why? > How would that interact with hotplug? What does hotplug have to do at all with this? thanks, greg "not all the world is video cards" k-h - 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/ | ||||||||||||
| Last update: 2006-05-05 21:11 [from the cache] ©2003-2008 | |||||||||||||