public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Edgar Toernig <froese@gmx.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [udev/vcs] tons of creating/removing /dev/vcs* during boot
Date: Mon, 12 Sep 2005 22:55:33 -0700	[thread overview]
Message-ID: <20050913055533.GA7206@kroah.com> (raw)
In-Reply-To: <20050912170618.69e18341.froese@gmx.de>

On Mon, Sep 12, 2005 at 05:06:18PM +0200, Edgar Toernig wrote:
> Hi,
> 
> switching from SuSE's 2.6.11.4 to vanilla 2.6.13 I noticed
> that I get tons of these lines in the log during boot:
> 
> udev[2124]: configured rule in '/etc/udev/rules.d/50-udev.rules[98]' ...
> udev[2121]: creating device node '/dev/vcs5'
> udev[2124]: creating device node '/dev/vcsa3'
> udev[2140]: configured rule in '/etc/udev/rules.d/50-udev.rules[98]' ...
> udev[2144]: configured rule in '/etc/udev/rules.d/50-udev.rules[98]' ...
> udev[2140]: creating device node '/dev/vcs3'
> udev[2144]: creating device node '/dev/vcsa6'
> udev[2147]: removing device node '/dev/vcs6'
> udev[2149]: configured rule in '/etc/udev/rules.d/50-udev.rules[98]' ...
> udev[2158]: removing device node '/dev/vcs4'
> udev[2157]: removing device node '/dev/vcsa3'
> udev[2149]: creating device node '/dev/vcsa5'
> udev[2172]: configured rule in '/etc/udev/rules.d/50-udev.rules[98]' ....
> udev[2171]: removing device node '/dev/vcsa2'
> udev[2172]: creating device node '/dev/vcs5'
> 
> It's caused by various loadkeys, setleds, etc performed early in an
> init script.  It seems, that every open/close of a tty generates
> a hotplug event for the appropriate vcs/vcsa device.  It stops at
> the moment gettys are spawned.
> 
> Looking at the 2.6.11.4 source of drivers/char/vc_screen.c I see
> that hotplug events are explicitly disabled for the vcs and vcsa
> devices (not sure whether this was done by SuSE).

Yes, this was a SUSE change, that's never been in mainline.

> In 2.6.13 all of that code is gone, including the class_simple that
> was used to disable hotplug events.

Well, consider it "never present" instead of gone :)

> How can I avoid all of these hotplug events?

Why do you want to?  You need them in order to create the proper device
node for the virtual terminal, right?

And, if you use the latest versions of udev, no hotplug events need
cause a program execute, udev can watch the hotplug netlink socket and
just act on it, _very_ quickly.  So quickly you will not even care I
bet...

> Best would be of course to generate only a single event at the same
> time the tty device is create.

That's what you are seeing.  And then watching as it's being destroyed.
And then created.  And then destroyed.  And so on (virtual ttys are
nasty at times..)

> But I could also live with no hotplug events for vcs* at all.

You would not be able to use them if you use udev then :(

Seriously, try the latest udev, with the netlink socket, and see if it
still matters anymore.

thanks,

greg k-h

  reply	other threads:[~2005-09-13  5:55 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-12 15:06 [udev/vcs] tons of creating/removing /dev/vcs* during boot Edgar Toernig
2005-09-13  5:55 ` Greg KH [this message]
2005-09-13 13:14   ` Andreas Jellinghaus

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=20050913055533.GA7206@kroah.com \
    --to=greg@kroah.com \
    --cc=froese@gmx.de \
    --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