linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: linux-hotplug@vger.kernel.org
Subject: Re: hotplug (was devfs)
Date: Wed, 13 Nov 2002 15:14:46 +0000	[thread overview]
Message-ID: <marc-linux-hotplug-103720035306943@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-103719698302880@msgid-missing>

Oliver.Neukum@lrz.uni-muenchen.de wrote:
> On Wed, 13 Nov 2002, Nick Craig-Wood wrote:
> 
>>We have machines with 6 x 4 port USB <-> serial converters attached.
>>These would get randomly assigned usb device ids and hence random
>>/dev/ttyUSB nodes.  Not very useful when there is a load of different
>>things attached to the 24 serial ports!

Right, this is why "physical" paths are needed as well as
sequentially assigned /dev/...N nodes.


>>Sometimes we also found that one of the devices wouldn't get
>>initialised properly.
>>
>>We fixed these problems by removing hotplug and loading the relevant
>>kernel modules in the correct order and voila a perfectly
> 
> Modules ? Plural?

Sounds like a better fix might have been to teach hotplug
about your additional modules... or to fix the modules
so they initialized correctly!


>>So - perhaps hotplug ought to be serialised?
> 
> 
> Definitely, but how far?

Until about the last week before 2.4.0final shipped, hotplug
was serialized.  The serialization got removed at the same
time keventd got added.

Why was it removed?  Because serializing meant that kernel
locks had to be held until a user mode program returned.
That caused deadlock when, for example, network hotplug
had to grab that same lock ... it basically wasn't possible
to get away from that problem in at least that case, and by
extension likely other cases.

So I'm not sure I see hotplug ever getting serialized.
But then, I don't see any reason it would ever fix the
problem of needing to map /dev/... nodes to the physical
device they represent, either.

- Dave





-------------------------------------------------------
This sf.net email is sponsored by: Are you worried about 
your web server security? Click here for a FREE Thawte 
Apache SSL Guide and answer your Apache SSL security 
needs: http://www.gothawte.com/rd523.html
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

  reply	other threads:[~2002-11-13 15:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-13 14:15 hotplug (was devfs) Oliver.Neukum
2002-11-13 15:14 ` David Brownell [this message]
2002-11-13 15:48 ` Nick Craig-Wood

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=marc-linux-hotplug-103720035306943@msgid-missing \
    --to=david-b@pacbell.net \
    --cc=linux-hotplug@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;
as well as URLs for NNTP newsgroup(s).