[PATCH] fix LINK_ZERO parsing in cdsymlinks.c

[PATCH] fix LINK_ZERO parsing in cdsymlinks.c

[Olivier Blin]

[-- Attachment #1: Type: text/plain, Size: 85 bytes --]

Hi,

The following patch from J.A. Magallon fixes LINK_ZERO parsing in
cdsymlinks.c


[-- Attachment #2: fix LINK_ZERO parsing --]
[-- Type: application/octet-stream, Size: 337 bytes --]

[-- Attachment #3: Type: text/plain, Size: 66 bytes --]


Regards

-- 
Olivier Blin
Mandriva
Mandrakesoft becomes Mandriva

Re: [PATCH] fix LINK_ZERO parsing in cdsymlinks.c

[Darren Salt]

[-- Attachment #1: Type: text/plain, Size: 545 bytes --]

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.

-- 
| Darren Salt | nr. Ashington, | d youmustbejoking,demon,co,uk
| Debian,     | Northumberland | s zap,tartarus,org
| RISC OS     | Toon Army      | @
|   One brown paper bag, recently used.

If you notice this notice, you'll notice this notice is not worth noticing.

[-- Attachment #2: udev-068-cdsymlinks.c.patch --]
[-- Type: text/plain, Size: 932 bytes --]

--- udev-068/extras/cdsymlinks.c~	2005-09-06 18:46:38.000000000 +0100
+++ udev-068/extras/cdsymlinks.c	2005-09-06 18:47:22.000000000 +0100
@@ -12,11 +12,12 @@
  * (this last one is "just in case")
  *
  * (c) 2004, 2005 Darren Salt <linux@youmustbejoking.demon.co.uk>
+ *                and contributors
  *
  * Contributors:
  *  - J A Magallon <jamagallon@able.es> (bug fixes)
  *
- * Last modified: 2005-02-15
+ * Last modified: 2005-09-06
  */
 
 #define _GNU_SOURCE
@@ -301,8 +302,8 @@
           }
           else if (!strncmp (p.we_wordv[0], "NUMBERED_LINKS=", 15))
             numbered_links = atoi (p.we_wordv[0] + 15);
-          else if (!strncmp (p.we_wordv[0], "LINK_ZERO=", 15))
-            link_zero = atoi (p.we_wordv[0] + 15);
+          else if (!strncmp (p.we_wordv[0], "LINK_ZERO=", 10))
+            link_zero = atoi (p.we_wordv[0] + 10);
           break;
 	}
 	/* fall through */

Re: [PATCH] fix LINK_ZERO parsing in cdsymlinks.c

[Greg KH]

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?

thanks,

greg k-h


-------------------------------------------------------
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

Re: [PATCH] fix LINK_ZERO parsing in cdsymlinks.c

[Darren Salt]

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?)

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).

-- 
| Darren Salt | d youmustbejoking,demon,co,uk | nr. Ashington,
| Debian,     | s zap,tartarus,org            | Northumberland
| RISC OS     | @                             | Toon Army
|   <URL:http://www.youmustbejoking.demon.co.uk/progs.packages.html>

Captain, permission to hook up blender attachments to Mr Spock.


-------------------------------------------------------
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

Re: [PATCH] fix LINK_ZERO parsing in cdsymlinks.c

[Kay Sievers]

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