On Fri, Jul 13, 2012 at 04:22:23PM +0300, Michael S. Tsirkin wrote: > On Fri, Jul 13, 2012 at 10:09:15AM +0200, Dominic Eschweiler wrote: > > Am Freitag, den 13.07.2012, 02:16 +0300 schrieb Michael S. Tsirkin: > > > My concern was people will ask for more and more stuff that pci > > > sysfs already has. > > > If we do add these is there a way to not duplicate code from pci? > > > > I have some concerns about the placing for the BAR mapping code inside > > the kernel. The point is, that sysfs currently makes it possible to map > > BARs of all card which are handled by any driver. This is fine in case > > of UIO, because it is intended that a user-space program maps BARs, but > > it is also possible to map BARs that are already handle by a kernel > > driver. It i therefore possible to jam the system by confusing sysfs > > entries. > > > > I don't know which implications this has, but I would move the BAR > > mapping capabilities completely to UIO. This should ensure that only > > BARs can be mapped, which are handled by UIO and no other kernel-space > > driver. > > Could you give an example of the problem? How do you bind > both UIO and another driver to the same device? You don't. If you already have a driver for your PCI device, why would you want to write a UIO driver? The sysfs files we were talking about are generated by the PCI core, which is not a driver. They simply reflect what the kernel can find out about the device. If somebody maps the card's memory through the UIO driver and somebody else also maps it using sysfs, that is possible. What happens if both write to the same hardware registers is a different topic. Writing a driver implies some responsibility, even if it's done in userspace. Thanks, Hans -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
