From: Kay Sievers <kay.sievers@vrfy.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: [PATCH] add USB coldplay support into udevstart
Date: Wed, 10 Aug 2005 14:47:21 +0000 [thread overview]
Message-ID: <20050810144721.GA32169@vrfy.org> (raw)
In-Reply-To: <m2ll3dxya3.fsf@vador.mandriva.com>
On Wed, Aug 10, 2005 at 01:00:52PM +0200, Olivier Blin wrote:
> Olaf Hering <olh@suse.de> writes:
>
> > On Mon, Aug 08, Kay Sievers wrote:
> >
> >> I don't think, that we want to do this in udevstart, at least at it's
> >> current state. It will break to many setups, cause all the distros have
> >> their own way to handle the coldplug case.
> >
> > Please rename 'udevstart' to 'udev_fill_dev_dir_with_device_node_entries',
> > to reflect what the real purpose is (or was, back in the old days).
>
> I understand the initial goal of udevstart is to populate /dev, but it
> can be extended to replay other events that would have been missed
> before udev was started.
>
> Maybe we could add a --coldplug= option with a comma-separated list of
> buses. Thus it will be backward compatible for distros already
> handling the coldplug case, and it will allow to easily switch to
> udevstart for coldplug. Should I write the patch?
Sure, that would be nice. But start it as it's own program. Maybe copy
udevstart for it, but leave it as it is for now. I don't want to touch
it with experimental stuff, also not with alternate code paths, it is
the most critical part of udev for most of its users.
There are many options to try and I don't think that serializing the
complete coldplug with a single process makes a lot of sense. It would
execute all udev rules for every device it finds, external stuff is called
that may take a unpredictable amount of time to run. This must be some async
operation, similar to what we do with udevd, I think.
> By the way, it would probably be cleaner to use udev_process_event()
> in add_device() (from udevstart), unless there is some special case I
> miss.
We don't want the wait_for_sysfs crap with udevstart, it is much faster
that way. It may change with a future udev version, which dependend on
a specific kernel version, that does not need most of the wait_for_sysfs
anymore.
> And this piece of code:
> if (strcmp(dent->d_name, "net") = 0)
> device_list_insert(dirname2, "net", &device_list);
> else if (has_devt(dirname2))
> device_list_insert(dirname2, dent->d_name, &device_list);
> can be simplified as:
> if (strcmp(dent->d_name, "net") = 0 || has_devt(dirname2))
> device_list_insert(dirname2, dent->d_name, &device_list);
Yeah, that's right.
Thanks,
Kay
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
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
next prev parent reply other threads:[~2005-08-10 14:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-07 20:55 [PATCH] add USB coldplay support into udevstart Thierry Vignaud
2005-08-08 13:12 ` Greg KH
2005-08-08 13:49 ` Greg KH
2005-08-08 14:21 ` Greg KH
2005-08-08 16:09 ` Kay Sievers
2005-08-08 16:14 ` Thierry Vignaud
2005-08-08 16:17 ` Kay Sievers
2005-08-08 16:30 ` Olaf Hering
2005-08-08 19:40 ` Greg KH
2005-08-10 10:59 ` Olivier Blin
2005-08-10 14:47 ` Kay Sievers [this message]
2005-08-10 15:06 ` Marco d'Itri
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=20050810144721.GA32169@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).