Date: Tue, 31 Mar 2009 10:55:47 -0400 From: John Baldwin <jhb@freebsd.org> To: barney_cordoba@yahoo.com Cc: freebsd-current@freebsd.org Subject: Re: pci_alloc_resource is broken Message-ID: <200903311055.48136.jhb@freebsd.org> In-Reply-To: <105551.54281.qm@web63901.mail.re1.yahoo.com> References: <105551.54281.qm@web63901.mail.re1.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200903311055.48136.jhb>