Re: PATCH: Multiprobe sanitizer

[Greg KH]

On Thu, Aug 17, 2006 at 01:36:33AM +0100, Alan Cox wrote:
> Ar Mer, 2006-08-16 am 15:26 -0700, ysgrifennodd Greg KH:
> > What would this help out with?  Would the PCI layer (for example) handle
> > this "notify the core that it can continue" type logic?  Or would the
> > individual drivers need to be able to control it?
> > 
> > I'm guessing that you are thinking of this in relation to the disk
> > drivers, have you found cases where something like this is necessary due
> > to hardware constraints?
> 
> Actually it occurs everywhere because what happens is
> 
> 	PCI enumerates in bus order
> 	Threads *usually* run in bus order
> 
> so every n'th boot your devices re-order themselves out of bus order,
> and eth1 becomes eth0 for the day.

As per the help information for this option, this will happen.  Happens
all the time on my machines already, that's why I use a tool that always
names the devices in the proper way (like almost all distros do these
days.)

It's a trade off, if you want a parallel device probe, you have to stop
relying on the kernel name for devices and use something that is not
going to change.  Like PCI device ids, (well, ok, they change all the time
on pci hotplug boxes and bios upgrades) or MAC addresses, or serial
numbers, or file system labels.

> If you have a "ok now continue scanning" API then we can do
> 
> 	Grab resources
> 	Register driver
> 	Go parallel
> 	[Slow stuff]

It seems that for some types of devices, the "Grab resources" portion
takes the longest (SCSI...).  And the "register driver" stuff already
happens later in the process, in an async manner today.  So that's not
going to work :(

> I was thinking if we set multithread = 2 (and define some constants)
> then the core code would do
> 
> 	if (multithread == WAIT)
> 		down(&drv->wait);
> 
> 
> and we'd have
> 
> 	pci_driver_continue_enumerating(struct pci_driver *drv) {
> 		up(&drv->wait);
> 	}

Yeah, I played with limiting the number of outstanding threads in a
manner like this, but couldn't come up with a real reason to limit it.

If you can think of a place in the PCI core that we could block on in
this manner, please let me know.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/