Re: pci_alloc_resource is broken

--- On Mon, 3/30/09, John Baldwin <jhb_at_freebsd.org> wrote:

> From: John Baldwin <jhb_at_freebsd.org>
> Subject: Re: pci_alloc_resource is broken
> To: barney_cordoba_at_yahoo.com
> Cc: freebsd-current_at_freebsd.org
> Date: Monday, March 30, 2009, 12:14 PM
> On Monday 30 March 2009 11:53:02 am Barney Cordoba wrote:
> > > This was actually on purpose to prevent multiple
> > > allocations of a resource.  
> > > Multiple allocations actually leak kernel memory
> since the
> > > resource only 
> > > keeps track of the current mapping.  My question
> is why are
> > > you having one 
> > > device allocate resources of another device?  If
> you have
> > > two functions of a 
> > > multi-function PCI adapter that you want one
> logical driver
> > > for, then have 
> > > each function's driver allocate its own
> resources and
> > > store the 'struct 
> > > resource *' in a "global" softc. 
> You can
> > > then use whichever resource you 
> > > need for bus_read/write when you do bit-banging.
> > > 
> > > -- 
> > > John Baldwin
> > 
> > We're remapping in another driver because in the
> commercial world,
> > we don't always have access to kernel source, and
> there is a strong
> > desire to separate the NIC driver from the secondary
> function so 
> > customers can get patches for the OS without having to
> worry about
> > incompatibility with the secondary modules.
> > 
> > I can add a function to the NIC driver also, but the
> goal is to be
> > able to distribute a module that doesn't require
> modification to the
> > stock driver for the system.
> 
> In FreeBSD you do always have access to the source. :) 
> (And fwiw, I have 
> worked on proprietary FreeBSD drivers in the past including
> a driver for a 
> multi-function card that actually managed two functions via
> one logical 
> driver.)
> 
> However, I am curious that you are able to make this work
> on "commercial" 
> operating systems as well.  On OS X only the IOService
> child of a PCI node 
> can map the BARs of that node.  Well, you can actually walk
> up to the parent 
> PCI bus, find your sibling IOService node and get its BARs
> that way which 
> does work.  In Windows I'm not sure how you would make
> this work as when you 
> attach to a FDO you get callbacks for each of your
> resources for tha tnode in 
> BAR order.  AFAIK, there isn't a good way to discover
> or use the resources of 
> another device in WDM, at least not at the time of Windows
> XP.
> 
> -- 
> John Baldwin

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. 

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?

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. 

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.

Barney