public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg KH <greg@kroah.com>, akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: PATCH: Multiprobe sanitizer
Date: Thu, 17 Aug 2006 08:57:13 +0200	[thread overview]
Message-ID: <1155797833.11312.160.camel@localhost.localdomain> (raw)
In-Reply-To: <1155774994.15195.12.camel@localhost.localdomain>

On Thu, 2006-08-17 at 01:36 +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.

Devices reorder themselves anyways .... look at my XPC shuttle, it has
some usb all-sort-of-card reader built-in and every other day, I get
that to be sda instead of the internal SATA... solution: use mounting by
label. With USB network type of things etc... same problem. I really
don't like the idea of having to add special things in PCI drivers to
"work around" the problem (which will only work in some cases and will
slightly lower how much parallelism we can do).

In fact, I'm all about making the problem worse by agressively
paralellilizing everything to get distros config mecanisms to catch up
and stop using the interface name (or use ifrename).

Ben.



  reply	other threads:[~2006-08-17  6:57 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-16 16:42 PATCH: Multiprobe sanitizer Alan Cox
2006-08-16 22:26 ` Greg KH
2006-08-17  0:36   ` Alan Cox
2006-08-17  6:57     ` Benjamin Herrenschmidt [this message]
2006-08-17  7:00       ` Arjan van de Ven
2006-08-17  8:41       ` Alan Cox
2006-08-17  9:24         ` Benjamin Herrenschmidt
2006-08-17 12:00           ` Greg KH
2006-08-17 12:12             ` Benjamin Herrenschmidt
2006-08-17 12:22               ` Greg KH
2006-08-17 12:37                 ` Benjamin Herrenschmidt
2006-08-17 13:04                   ` Arjan van de Ven
2006-08-17 13:10                     ` Benjamin Herrenschmidt
2006-08-17 15:44                     ` Greg KH
2006-08-17 14:43                 ` Olaf Hering
2006-08-17 15:42                   ` Greg KH
2006-08-17 11:58     ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1155797833.11312.160.camel@localhost.localdomain \
    --to=benh@kernel.crashing.org \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox