> Wow. A list of iterators to be fixed up ... I get the idea, but it does
> add a fair amount of complexity.
Not that much, been there done that, it's actually quite simple :)
> Would it be easier (and simpler to maintain/debug) to "get" all items
> on the list first, before iterating on them,
Hi,
On Thu, Aug 18, 2005 at 02:58:28PM +1000, Benjamin Herrenschmidt was heard to
remark:
> On Thu, 2005-08-18 at 14:33 +1000, Paul Mackerras wrote:
> > This patch adds a
> > function to the PCI core that traverses all the PCI devices on a PCI
> > bus and under any PCI-PCI bridges on that bus (an
On Wed, 2005-08-17 at 22:13 -0700, Greg KH wrote:
> On Thu, Aug 18, 2005 at 02:58:28PM +1000, Benjamin Herrenschmidt wrote:
> > I wonder if it's finally time to implement proper race free list
> > iterators in the kernel. Not that difficult... A small struct iterator
> > with a list head and the cu
On Thu, Aug 18, 2005 at 02:58:28PM +1000, Benjamin Herrenschmidt wrote:
> I wonder if it's finally time to implement proper race free list
> iterators in the kernel. Not that difficult... A small struct iterator
> with a list head and the current elem pointer, and the "interated" list
> containing
On Thu, 2005-08-18 at 14:33 +1000, Paul Mackerras wrote:
> The PCI error recovery infrastructure needs to be able to contact all
> the drivers affected by a PCI error event, which may mean traversing
> all the devices under a given PCI-PCI bridge. This patch adds a
> function to the PCI core that
The PCI error recovery infrastructure needs to be able to contact all
the drivers affected by a PCI error event, which may mean traversing
all the devices under a given PCI-PCI bridge. This patch adds a
function to the PCI core that traverses all the PCI devices on a PCI
bus and under any PCI-PCI
6 matches
Mail list logo