Re: Sound translator / PCI device handling

[Antti Kantee]

On 19/09/15 08:52, Robert Millan wrote:
> [Adding rumpkernel-users]
>
> El 19/09/15 a les 01:21, Olaf Buddenhagen ha escrit:
> > Is there no way to limit the probing to a particular device, though? In
> > the long run, it really seems cleaner to tell the driver, "please try to
> > serve this device", rather than "go out and see whether you can find any
> > devices to your liking..."

There's a way to limit which drivers attach to which devices in the "if 
you find a suitable device, only attach if it's at this bus/dev/fun" 
sense.  However, that's not the same as limiting the pci probe. 
Besides, there's currently no easy way for the user to configure the 
attachment limits (involves going into the tree, editing ioconf files 
all around, and recompiling things).

IMO the right way to do device drivers in a hosted environment is to 
have one entity which decides which servers see which devices and just 
let the servers attach to all devices they see.  That way you have the 
configuration in one format in one place.

> See the Linux version of rumpcomp_pci_map() in pci-userspace [1]. IIRC
> this is
> used by librumpdev_pci to enumerate available PCI devices. Or if not
> that function,
> certainly something in that file ;-)

I admittedly haven't done anything with PCI for a while, so I may have 
forgotten how PCI works, but IIRC probing is done by reading 
configuration space registers.  pci_map() is called only when a driver 
attaches to a device and needs to map the device registers.

> On Linux, this is ultimately determined by UIO module settings (admin
> tells Linux
> which devices are available to user-space code, see [2] for UIO setup
> instructions).
>
> When I implemented the GNU/Hurd backend, I observed there's no such
> thing as Linux'
> UIO restricting access to PCI devices, so I simply made it use
> libpciaccess for
> scanning and blindly accepting anything it finds (not the Linux backend
> doesn't
> use libpciaccess at all, it just uses UIO for equivalent functionality).
>
> So AFAIK there's no framework to manage which devices are available to
> Rump, but
> if one wanted to implement it pci-userspace/src-gnu/ seems the place to
> do it.

Config space access is implemented via hypercalls, so you could just 
redirect the requests to some central authority which decides if the 
server in question should be allowed to access the config space of 
bus/dev(/fun) or just see -1.  I'm not quite sure how you'd translate 
the central authority configuration into something human-manageable or 
automated.  But then again, I sell only drivers, so that's not my problem ;)