linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kay Sievers <kay.sievers@vrfy.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: strange delays in vc class
Date: Fri, 15 Oct 2004 20:09:25 +0000	[thread overview]
Message-ID: <20041015200925.GA6617@vrfy.org> (raw)
In-Reply-To: <20041015000446.GA2796@vrfy.org>

On Fri, Oct 15, 2004 at 09:18:26PM +0200, Kay Sievers wrote:
> On Fri, Oct 15, 2004 at 11:59:35AM -0700, Greg KH wrote:
> > 
> > Ugh.  In looking at the kernel code, I don't see how it could be doing
> > this.  But the console startup code is a strange beast...
> 
> The close will remove the "dev" file and the wait_for_sysfs from the
> add-hotplug will spin and fail or at best will recover with the next
> hotplug-add. The "remove" event beats the "add"! We have the same event
> serializing problem here, we solved with udevd for udev.

I may reactivate my old hotplugd work to address this?

We merge udev and udevd. We parse the config and rules once on startup and
then wait for events as udevd does today.

On a kernel event udevd does a fork() but _no_ exec(). This will create a
new instance of the same code with the already parsed config in memory.

The forked udevd instance will:
  o wait for sysfs internally
  o if needed create the node and set the environment
  o execute /etc/hotplug.d/ scripts (with DEVPATH in the environment)

This leads to:
  o complete serialized hotplug sequence handling
  o hotplug.d/ execution with sane sysfs state and created node
  o no more dev.d/ (can just live in hotplug.d/)
  o no udev disk activity (with nodes and db on tmpfs)
  o only one process fork() for every event (besides possible callouts)

It is a bit far from the current model but we already rely on a running
daemon. I've had something like this in mind with all my recent work.
In the very long run we may even set /proc/sys/kernel/hotplug to "" after
bootup and udevd(hotplugd) can get the hotplug-events over netlink :)

What do you think?

Kay


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
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

  parent reply	other threads:[~2004-10-15 20:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-15  0:04 strange delays in vc class Kay Sievers
2004-10-15  0:23 ` Kay Sievers
2004-10-15 18:34 ` Greg KH
2004-10-15 18:48 ` Kay Sievers
2004-10-15 18:59 ` Greg KH
2004-10-15 19:18 ` Kay Sievers
2004-10-15 20:09 ` Kay Sievers [this message]
2004-10-15 22:12 ` Greg KH
2004-10-15 23:20 ` Greg KH
2004-10-16  0:08 ` Kay Sievers

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=20041015200925.GA6617@vrfy.org \
    --to=kay.sievers@vrfy.org \
    --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).