[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sound translator / PCI device handling

From: Antti Kantee
Subject: Re: Sound translator / PCI device handling
Date: Sat, 19 Sep 2015 13:24:17 +0000

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]