Re: pci_alloc_resource is broken

On Monday 30 March 2009 6:18:24 pm Barney Cordoba wrote:
> I dunno, but its pretty lame that you can't read a register on a card
> without hacking the kernel. The entire point of having a generic bus
> management system is to create a relatively transparent mechanism for
> accessing such resources, but then if you try to share a resource
> you find out that the system doesn't support shared resources and
> requires proprietary hacking of the drivers. 

Most OS's tend to assume that a single driver is all that is needed for a 
single PCI function.  Windows does allow filter drivers which you could use 
to have multiple drivers for a given PCI function.  In FreeBSD we only allow 
you to have one.  However, you are free to have your "one" driver actually be 
a virtual bus that allows for multiple leaf drivers.  You can look at 
sys/dev/pci/vga_pci.c for an example of this.  It allows drm, acpi_video, and 
agp to all attach to a VGA adapter.  It even allows sharing of the BARs so 
the different sub-drivers can each allocate the BAR and use it.  If you have 
designed your hardware such that it places multiple logical functions into a 
single PCI function (rather than having a separate PCI function for each 
logical function) then you can take the bus approach.  You can even have both 
the virtual bus driver and the NIC driver "open" and the magic frobnitz 
driver in a binary foo.ko if you want.

> We don't want to have to make the 
> ethernet functionality "proprietary" or required to be obtained from
> a static source. So if some dude in Pakistan wants to grab a bug fix
> he can do it without whining to the vendor that the code is proprietary,
> thus burdening the vendor to re-hack every iteration of code that some
> customer in some corner of the world wants to run for one reason or 
> another. The alternative is telling the customer that he can't have the 
> bug fix until the vendor gets around to releasing a version that has the 
> latest patch. It doesn't have to run on other OSes. Its a logistic issue.
> Its a matter of streamlining the work flow. Having separate drivers 
> makes upgrading easier. You don't have to hack 37 source files every time
> you decide to grab a -stable because some dude at freebsd.org decided to
> change a macro. Are you getting this?

You need more "commercial" experience because some "commercial" OS's are worse 
about changing macros than FreeBSD is. :)  A word of advice: your 
condescending tone is not going to win you any friends or get your questions 
answered any sooner.  Quite the contrary in fact.

> As a side issue, the number of panics I found along the way is a bit 
> alarming. Its pretty lazy coding. Panic should really only be called
> when a condition is unrecoverable; not every time someone doesn't feel
> like writing the couple of lines of code to handle the condition.

To be honest, in the case of device drivers it can be helpful to make the 
system panic more easily since many of them are lazy about checking return 
values from functions (I've had to deal with several out-of-tree drivers).  
Also, FWIW, other bus devices do panic in this particular case.  The fact 
that PCI doesn't panic in 5.x - 7.x is actually due to a bug (resulting in 
the aforementioned resource leak) that I fixed in 8.

> Is the kernel memory leaked on each access, or is there
> some leakage on allocation and release only? I can live with a static 
> chunk lost, but not if its a continuous thing.

Just on allocation.  However, I think your longer term solution that fits into 
what "new-bus" wants for having multiple drivers share a single device is to 
make a virtual bus device.

-- 
John Baldwin