On Wed, Apr 21, 2010 at 12:31:50PM +0200, Hans J. Koch wrote:
quoted text
> On Wed, Apr 21, 2010 at 12:38:49PM +0300, Michael S. Tsirkin wrote:
> > 
> > > +			j++;
> > > +		}
> > > +	}
> > > +	for (i = 0, j = 0; i < PCI_STD_RESOURCE_END &&
> > > +			   j < MAX_UIO_PORT_REGIONS; i++) {
> > > +		if (pci_resource_flags(pdev, i) & IORESOURCE_IO) {
> > > +			name = kmalloc(8, GFP_KERNEL);
> > > +			if (name == NULL)
> > > +				break;
> > > +			sprintf(name, "iobar%d", i);
> > > +			info->port[j].name = name;
> > > +			info->port[j].start = pci_resource_start(pdev, i);
> > > +			info->port[j].size = pci_resource_len(pdev, i);
> > > +			info->port[j].porttype = UIO_PORT_X86;
> > > +			j++;
> > 
> > At least on x86, I think io bar can not be mmapped.
> 
> That's right. porttype == UIO_PORT_X86 is only there for information
> purposes. Userspace then knows that it cannot map this but has to use
> things like inb(), outb() and friends after getting access rights with
> ioperm()/iopl(). "start" and "size" gives userspace the information
> needed to do this.
> 
> Thanks,
> Hans

So that fails in the declared purpose of allowing an unpriveledged
userspace driver, as inb/outb are priveledged operations.

-- 
MST
--
unsubscribe notice
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/