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 ;)
