From: Kay Sievers <kay.sievers@vrfy.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: [PATCH] fix LINK_ZERO parsing in cdsymlinks.c
Date: Thu, 08 Sep 2005 02:55:33 +0000 [thread overview]
Message-ID: <20050908025533.GA25251@vrfy.org> (raw)
In-Reply-To: <m364tea44g.fsf@dynamo.mandriva.com>
On Thu, Sep 08, 2005 at 02:41:28AM +0100, Darren Salt wrote:
> I demand that Greg KH may or may not have written...
>
> > On Tue, Sep 06, 2005 at 06:45:42PM +0100, Darren Salt wrote:
> >> I demand that Olivier Blin may or may not have written...
> >>> The following patch from J.A. Magallon fixes LINK_ZERO parsing in
> >>> cdsymlinks.c
> >> Good catch...
> >> I'm attaching that patch *uncompressed* and with appropriate adjustments
> >> to the comments at the start of the file.
>
> > This file is obsoleted by the cdrom_id program. Mind if we just delete the
> > cdsymlinks stuff from the udev tree as it isn't needed anymore?
>
> I'd prefer to have them log some "obsoleted, will be removed in version xxx"
> messages for a couple of releases. (Output on stderr?)
The program is still available in the old releases. The packagers can pick it
up from there if needed. We only ship *_id programs from now on to have a
consistent way to do device naming. IMPORT'ed variables are accesible for
later rules to match against and they are also stored in the udev database to
be queried by other programs any time later.
> BTW, I'm not sure that the behaviour of cdrom_id and its associated rules
> concerning links for a device for which symlinks already exists is right;
> although, as it stands, it'll only be a problem if udev gets duplicate events
> (or /dev isn't a tmpfs mount or similar).
Unknown links are always overwritten if they are not registered in the udev
database. Duplicate events should create the same nodes and links.
If you miss some feature, please add it to the cdrom_id program now.
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
prev parent reply other threads:[~2005-09-08 2:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-06 10:21 [PATCH] fix LINK_ZERO parsing in cdsymlinks.c Olivier Blin
2005-09-06 17:45 ` Darren Salt
2005-09-07 20:44 ` Greg KH
2005-09-08 1:41 ` Darren Salt
2005-09-08 2:55 ` Kay Sievers [this message]
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=20050908025533.GA25251@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).