new release of udev?

new release of udev?

[Greg KH]

Ok, now that the next kernel release is going to require people to
update udev, I want to make a new release.  I know the two of you have
been talking a lot about if the 057 release was good enough to package
up due to the dev.d change.

Did you come to any conclusions?

For now, we are still processing the dev.d tree by default, right?

Anyone have anything they want to see fixed before I release a 058
version?

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_idt12&alloc_id\x16344&op=click
_______________________________________________
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: new release of udev?

[Kay Sievers]

On Wed, 2005-05-18 at 23:58 -0700, Greg KH wrote:
> Ok, now that the next kernel release is going to require people to
> update udev, I want to make a new release.  I know the two of you have
> been talking a lot about if the 057 release was good enough to package
> up due to the dev.d change.
> 
> Did you come to any conclusions?

It wasn't continued. I'm on the way starting a big next roud of work on
the udev package. Basically moving a lot of the SUSE version upstream.
The SUSE package has a lot of nice features, like netlink instead of
udevsend and initramfs-event-replay... All that can be compile options
in the upstream package.

The 057 has changed from 056 to read _all_ rules regardless of a NAME
match, to make the RUN= key working nicely - even when RUN= rules are at
the end of the rules.

There is a small hole in the rules concept:
If a custom rule want's to set custom permissions, but the system has a
SUBSYSTEM-only rule to set default permissions, the user supplied perms
are overridden. To prevent that, the rule can use "last_rule", but that
prevents later RUN-rules to be executed.

That behavior was that way since the beginning, not a change in 057.
Only the use of the RUN key is a bit difficult then. To solve that, I
will implement deferred(question mark) assignment, like in Makefiles for
the default system-supplied rules to use:
  SUBSYSTEM="block", GROUP?="disk"

will only set the permissions if no other rule has already set the
group. This should solve that small issue.

> For now, we are still processing the dev.d tree by default, right?

Yes, nothing has changed in that area.

> Anyone have anything they want to see fixed before I release a 058
> version?

Kay



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_idt12&alloc_id\x16344&op=click
_______________________________________________
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: new release of udev?

[Greg KH]

On Thu, May 19, 2005 at 09:30:27AM +0200, Kay Sievers wrote:
> On Wed, 2005-05-18 at 23:58 -0700, Greg KH wrote:
> > Ok, now that the next kernel release is going to require people to
> > update udev, I want to make a new release.  I know the two of you have
> > been talking a lot about if the 057 release was good enough to package
> > up due to the dev.d change.
> > 
> > Did you come to any conclusions?
> 
> It wasn't continued. I'm on the way starting a big next roud of work on
> the udev package. Basically moving a lot of the SUSE version upstream.
> The SUSE package has a lot of nice features, like netlink instead of
> udevsend and initramfs-event-replay... All that can be compile options
> in the upstream package.

That's great, but I think I need to get a release out before then, due
to the kernel issue I created :)

> There is a small hole in the rules concept:
> If a custom rule want's to set custom permissions, but the system has a
> SUBSYSTEM-only rule to set default permissions, the user supplied perms
> are overridden. To prevent that, the rule can use "last_rule", but that
> prevents later RUN-rules to be executed.
> 
> That behavior was that way since the beginning, not a change in 057.
> Only the use of the RUN key is a bit difficult then. To solve that, I
> will implement deferred(question mark) assignment, like in Makefiles for
> the default system-supplied rules to use:
>   SUBSYSTEM="block", GROUP?="disk"
> 
> will only set the permissions if no other rule has already set the
> group. This should solve that small issue.

Ah, ok, thanks for the explaination.  And thanks for the proposed fix.

> > For now, we are still processing the dev.d tree by default, right?
> 
> Yes, nothing has changed in that area.

Good, it shouldn't be that tough of an upgrade then.

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_idt12&alloc_id\x16344&op=click
_______________________________________________
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: new release of udev?

[Marco d'Itri]

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

On May 19, Kay Sievers <kay.sievers@vrfy.org> wrote:

> Only the use of the RUN key is a bit difficult then. To solve that, I
> will implement deferred(question mark) assignment, like in Makefiles for
> the default system-supplied rules to use:
>   SUBSYSTEM=="block", GROUP?="disk"
> 
> will only set the permissions if no other rule has already set the
> group. This should solve that small issue.
As I explained in our private discussion, this is complex and does not
solve the SYMLINK problem: users would still not be able to override
the distribution SYMLINK directives without using last_rule, which is
not an option because it breaks RUN processing.
With its current semantics, last_rule should almost never be used by
users.

I still think that having different "last_rule" directives for NAME and
RUN rules would be a better solution, and it looks much simpler to
implement and understand too.

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: new release of udev?

[Kay Sievers]

On Thu, May 19, 2005 at 12:32:20PM +0200, Marco d'Itri wrote:
> On May 19, Kay Sievers <kay.sievers@vrfy.org> wrote:
> 
> > Only the use of the RUN key is a bit difficult then. To solve that, I
> > will implement deferred(question mark) assignment, like in Makefiles for
> > the default system-supplied rules to use:
> >   SUBSYSTEM="block", GROUP?="disk"
> > 
> > will only set the permissions if no other rule has already set the
> > group. This should solve that small issue.
> As I explained in our private discussion, this is complex and does not
> solve the SYMLINK problem: users would still not be able to override
> the distribution SYMLINK directives without using last_rule, which is
> not an option because it breaks RUN processing.

Well, SYMLINK is a list not a single value. Why does someone want to
supress the additional system-supplied symlinks?

> With its current semantics, last_rule should almost never be used by
> users.

Yeah, it can be used exactly for what the name stands for. :)

> I still think that having different "last_rule" directives for NAME and
> RUN rules would be a better solution, and it looks much simpler to
> implement and understand too.

I don't think that this is simpler in any kind. That moves the complexity
away from the system-rules to the user-rules. And the system-rule
writer _must_ understand the complexity anyway. :)

Kay


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_idt12&alloc_id\x16344&op=click
_______________________________________________
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: new release of udev?

[Marco d'Itri]

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

On May 19, Kay Sievers <kay.sievers@vrfy.org> wrote:

> > As I explained in our private discussion, this is complex and does not
> > solve the SYMLINK problem: users would still not be able to override
> > the distribution SYMLINK directives without using last_rule, which is
> > not an option because it breaks RUN processing.
> Well, SYMLINK is a list not a single value. Why does someone want to
> supress the additional system-supplied symlinks?
Why not? I think it's a very reasonable request. Different people have
different ideas about /dev.

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: new release of udev?

[Darren Salt]

I demand that Greg KH may or may not have written...

> Anyone have anything they want to see fixed before I release a 058 version?

Application of the cdsymlinks patch which I posted here a while ago, if
you've not already done so. (The patch is present in the Debian package of
version 056.)

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

I need all of your money.


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_idt12&alloc_id\x16344&op=click
_______________________________________________
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: new release of udev?

[Greg KH]

On Thu, May 19, 2005 at 06:49:45PM +0100, Darren Salt wrote:
> I demand that Greg KH may or may not have written...
> 
> > Anyone have anything they want to see fixed before I release a 058 version?
> 
> Application of the cdsymlinks patch which I posted here a while ago, if
> you've not already done so. (The patch is present in the Debian package of
> version 056.)

Care to resend it?  There have been a lot of different patches for that
file floating around :)

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_idt12&alloc_id\x16344&op=click
_______________________________________________
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: new release of udev?

[Darren Salt]

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

I demand that Greg KH may or may not have written...

> On Thu, May 19, 2005 at 06:49:45PM +0100, Darren Salt wrote:
>> I demand that Greg KH may or may not have written...
>>> Anyone have anything they want to see fixed before I release a 058
>>> version?
>> Application of the cdsymlinks patch which I posted here a while ago, if
>> you've not already done so. (The patch is present in the Debian package of
>> version 056.)

(Or at least the shell script part of it is there...)

> Care to resend it?  There have been a lot of different patches for that
> file floating around :)

Attached.

-- 
| 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/> (PGP 2.6, GPG keys)

Forget the people. There are valuable computers at stake.

[-- Attachment #2: udev-057_cdsymlinks.diff --]
[-- Type: text/plain, Size: 16173 bytes --]

diff -ur udev-057.orig/extras/cdsymlinks.c udev-057/extras/cdsymlinks.c
--- udev-057.orig/extras/cdsymlinks.c	2005-04-14 22:39:34.000000000 +0100
+++ udev-057/extras/cdsymlinks.c	2005-02-15 02:23:03.000000000 +0000
@@ -11,7 +11,12 @@
  * BUS="scsi", KERNEL="scd[0-9]*", PROGRAM="/etc/udev/cdsymlinks.sh %k", SYMLINK="%c{1} %c{2} %c{3} %c{4} %c{5} %c{6}"
  * (this last one is "just in case")
  *
- * (c) 2004 Darren Salt <linux@youmustbejoking.demon.co.uk>
+ * (c) 2004, 2005 Darren Salt <linux@youmustbejoking.demon.co.uk>
+ *
+ * Contributors:
+ *  - J A Magallon <jamagallon@able.es> (bug fixes)
+ *
+ * Last modified: 2005-02-15
  */
 
 #define _GNU_SOURCE
@@ -56,6 +61,7 @@
 /* Configuration variables */
 static struct list_t allowed_output = {0};
 static int numbered_links = 1;
+static int link_zero = 0;
 
 /* Available devices */
 static struct list_t Devices = {0};
@@ -65,14 +71,40 @@
  */
 static struct list_t cap_DVDRAM = {0}, cap_DVDRW = {0}, cap_DVD = {0},
 		     cap_CDRW = {0}, cap_CDR = {0}, cap_CDWMRW = {0},
-		     cap_CDMRW = {0};
+		     cap_CDMRW = {0}, cap_CDRAM = {0};
 
 /* Device capabilities by name */
 static struct list_t dev_DVDRAM = {0}, dev_DVDRW = {0}, dev_DVD = {0},
 		     dev_CDRW = {0}, dev_CDR = {0}, dev_CDWMRW = {0},
-		     dev_CDMRW = {0};
+		     dev_CDMRW = {0}, dev_CDRAM = {0};
 #define dev_CD Devices
 
+typedef struct {
+  struct list_t *cap, *dev;
+  const char label[8], symlink[8];
+  const char *captext;
+  int captextlen;
+} cap_dev_t;
+
+#define CAPDEV(X) &cap_##X, &dev_##X
+
+static const cap_dev_t cap_dev_info[] = {
+  { NULL, &dev_CD,  "CD",     "cdrom",  NULL, 0 },
+  { CAPDEV(CDR),    "CDR",    "cd-r",   "Can write CD-R:", 15 },
+  { CAPDEV(CDRW),   "CDRW",   "cdrw",   "Can write CD-RW:", 16 },
+  { CAPDEV(DVD),    "DVD",    "dvd",    "Can read DVD:", 13 },
+  { CAPDEV(DVDRW),  "DVDRW",  "dvdrw",  "Can write DVD-R:", 16 },
+  { CAPDEV(DVDRAM), "DVDRAM", "dvdram", "Can write DVD-RAM:", 18 },
+  { CAPDEV(CDMRW),  "CDMRW",  "cdm",    "Can read MRW:", 13 },  /* CDC-MRW R */
+  { CAPDEV(CDWMRW), "CDWMRW", "cdmrw",  "Can write MRW:", 14 }, /* CDC-MRW W */
+  { CAPDEV(CDRAM),  "CDRAM",  "cdram",  "Can write RAM:", 14 }, /* CDC-RAM W */
+  { NULL }
+};
+
+#define foreach_cap_dev(loop) \
+  for ((loop) = cap_dev_info; (loop)->label[0]; ++(loop))
+#define foreach_cap_dev_noCD(loop) \
+  for ((loop) = cap_dev_info + 1; (loop)->label[0]; ++(loop))
 
 /*
  * Some library-like bits first...
@@ -218,7 +250,7 @@
 list_assign_split (struct list_t *list, char *text)
 {
   char *token = strchr (text, ':');
-  token = strtok (token ? token + 1 : text, " \t");
+  token = strtok (token ? token + 1 : text, " \t\n");
   while (token)
   {
     list_prepend (list, token);
@@ -267,8 +299,10 @@
             list_delete (&allowed_output);
             list_assign_split (&allowed_output, p.we_wordv[0] + 7);
           }
-          else if (!strncmp (p.we_wordv[0], "NUMBERED_LINKS=", 14))
-            numbered_links = atoi (p.we_wordv[0] + 14);
+          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);
           break;
 	}
 	/* fall through */
@@ -315,20 +349,16 @@
   {
     if (!strncasecmp (text, "drive name", 10))
       list_assign_split (&Devices, text);
-    else if (!strncasecmp (text, "Can write DVD-RAM", 17))
-      list_assign_split (&cap_DVDRAM, text);
-    else if (!strncasecmp (text, "Can write DVD-R", 15))
-      list_assign_split (&cap_DVDRW, text);
-    else if (!strncasecmp (text, "Can read DVD", 12))
-      list_assign_split (&cap_DVD, text);
-    else if (!strncasecmp (text, "Can write CD-RW", 15))
-      list_assign_split (&cap_CDRW, text);
-    else if (!strncasecmp (text, "Can write CD-R", 14))
-      list_assign_split (&cap_CDR, text);
-    else if (!strncasecmp (text, "Can read MRW", 14))
-      list_assign_split (&cap_CDMRW, text);
-    else if (!strncasecmp (text, "Can write MRW", 14))
-      list_assign_split (&cap_CDWMRW, text);
+    else
+    {
+      const cap_dev_t *cap;
+      foreach_cap_dev_noCD (cap)
+	if (!strncasecmp (text, cap->captext, cap->captextlen))
+	{
+	  list_assign_split (cap->cap, text);
+	  break;
+	}
+    }
   }
   if (!feof (info))
     errexit ("error accessing CD/DVD info");
@@ -341,7 +371,8 @@
  * taking into account existing links and the capability list for type LINK.
  */
 static void
-do_output (const char *name, const char *link, const struct list_t *dev)
+do_output (const char *name, const char *link, const struct list_t *dev,
+	   int do_link_zero)
 {
   const struct list_item_t *i = (const struct list_item_t *)dev;
   if (!i->next)
@@ -406,6 +437,8 @@
       /* Existing symlink found - don't output a new one.
        * If ISDEV, we output the name of the existing symlink.
        */
+      if (do_link_zero)
+	return;
       present = 1;
       if (isdev)
         printf (" %s", list_nth (&devls, li)->data);
@@ -415,14 +448,19 @@
     if (!present)
     {
       char buf[256];
-      snprintf (buf, sizeof (buf), count ? "%s%d" : "%s", link, count);
+      snprintf (buf, sizeof (buf), count || do_link_zero ? "%s%d" : "%s",
+		link, count);
       /* Find the next available (not present) symlink name.
        * We always need to do this for reasons of output consistency: if a
        * symlink is created by udev as a result of use of this program, we
        * DON'T want different output!
        */
       while (list_search (&devls, buf))
+      {
+	if (do_link_zero)
+	  return;
         snprintf (buf, sizeof (buf), "%s%d", link, ++count);
+      }
       /* If ISDEV, output it. */
       if (isdev && (numbered_links || count == 0))
         printf (" %s", buf);
@@ -431,6 +469,8 @@
        */
       if (!list_search (&devls, buf))
       {
+	if (do_link_zero)
+	  return;
         list_append (&devls, buf);
         ++count;
       }
@@ -458,6 +498,8 @@
 int
 main (int argc, char *argv[])
 {
+  const cap_dev_t *capdev;
+
   progname = argv[0];
   debug = argc > 2 && !strcmp (argv[2], "-d");
 
@@ -470,62 +512,43 @@
   read_defaults ();
   populate_capability_lists ();
 
-  /* Construct the device lists from the capability lists. */
-  populate_device_list (&dev_DVDRAM, &cap_DVDRAM);
-  populate_device_list (&dev_DVDRW, &cap_DVDRW);
-  populate_device_list (&dev_DVD, &cap_DVD);
-  populate_device_list (&dev_CDRW, &cap_CDRW);
-  populate_device_list (&dev_CDR, &cap_CDR);
-  populate_device_list (&dev_CDWMRW, &cap_CDWMRW);
-  populate_device_list (&dev_CDMRW, &cap_CDMRW);
-  /* (All devices can read CDs.) */
+  /* Construct the device lists from the capability lists.
+   * (We assume that all relevant devices can read CDs.)
+   */
+  foreach_cap_dev_noCD (capdev)
+    populate_device_list (capdev->dev, capdev->cap);
 
   if (debug)
   {
-#define printdev(DEV) \
-	printf ("%-7s:", #DEV); \
-        list_print (&cap_##DEV, stdout); \
-        list_print (&dev_##DEV, stdout); \
-	puts ("");
-
     printf ("Devices:");
     const struct list_item_t *item = (const struct list_item_t *)&Devices;
     while ((item = item->next) != NULL)
       printf (" %s", item->data);
-    puts ("");
 
-    printdev (DVDRAM);
-    printdev (DVDRW);
-    printdev (DVD);
-    printdev (CDRW);
-    printdev (CDR);
-    printdev (CDWMRW);
-    printdev (CDMRW);
-
-    printf ("CDROM  : (all)");
+    printf ("\nCDROM     : (all)");
     item = (const struct list_item_t *)&dev_CD;
     while ((item = item->next) != NULL)
       printf (" %s", item->data);
     puts ("");
+
+    foreach_cap_dev_noCD (capdev)
+    {
+      printf ("%-10s:", capdev->label);
+      list_print (capdev->cap, stdout);
+      list_print (capdev->dev, stdout);
+      puts ("");
+    }
+
   }
 
   /* Write the symlink names. */
-  if (list_search (&allowed_output, "CD"))
-    do_output (argv[1], "cdrom",  &dev_CD);
-  if (list_search (&allowed_output, "CDR"))
-    do_output (argv[1], "cd-r",   &dev_CDR);
-  if (list_search (&allowed_output, "CDRW"))
-    do_output (argv[1], "cdrw",   &dev_CDRW);
-  if (list_search (&allowed_output, "DVD"))
-    do_output (argv[1], "dvd",    &dev_DVD);
-  if (list_search (&allowed_output, "DVDRW"))
-    do_output (argv[1], "dvdrw",  &dev_DVDRW);
-  if (list_search (&allowed_output, "DVDRAM"))
-    do_output (argv[1], "dvdram", &dev_DVDRAM);
-  if (list_search (&allowed_output, "CDMRW"))
-    do_output (argv[1], "cdmrw",   &dev_CDMRW);
-  if (list_search (&allowed_output, "CDWMRW"))
-    do_output (argv[1], "cdwmrw",   &dev_CDWMRW);
+  foreach_cap_dev (capdev)
+    if (list_search (&allowed_output, capdev->label))
+    {
+      do_output (argv[1], capdev->symlink, capdev->dev, 0);
+      if (link_zero)
+        do_output (argv[1], capdev->symlink, capdev->dev, 1);
+    }
   puts ("");
 
   return 0;
diff -ur udev-057.orig/extras/cdsymlinks.conf udev-057/extras/cdsymlinks.conf
--- udev-057.orig/extras/cdsymlinks.conf	2005-04-14 22:39:39.000000000 +0100
+++ udev-057/extras/cdsymlinks.conf	2005-02-15 02:30:11.000000000 +0000
@@ -1,8 +1,13 @@
 # Configuration file for cdsymlinks
 
 # Output links for these types of devices.
-# Allowed keywords are CD, CDR, CDRW, DVD, DVDRW, DVDRAM, CDMRW, CDWMRW.
+# Allowed keywords are:     corresponding to device names:
+#   CD    CDR    CDRW         cdrom cd-r  cdrw
+#   DVD   DVDRW  DVDRAM       dvd   dvdrw dvdram
+#   CDMRW CDWMRW              cdm   cdmrw
+#   CDRAM                     cdram
 # Other words are accepted but ignored.
+# Devices with multiple recognised capabilities WILL get multiple links.
 #OUTPUT="CD CDRW DVD DVDRW DVDRAM"
 
 # Whether to output numbered links.
@@ -10,3 +15,7 @@
 # 0 = don't output 'cdrom1', 'dvd1' etc.
 # We always output 'cdrom', 'dvd' etc. for the best-match devices.
 #NUMBERED_LINKS=1
+
+# Whether to output link 0 along with each unnumbered link.
+# (No effect if NUMBERED_LINKS=0.)
+#LINK_ZERO=0
diff -ur udev-057.orig/extras/cdsymlinks.sh udev-057/extras/cdsymlinks.sh
--- udev-057.orig/extras/cdsymlinks.sh	2005-04-14 22:39:34.000000000 +0100
+++ udev-057/extras/cdsymlinks.sh	2005-02-15 02:22:52.000000000 +0000
@@ -1,6 +1,7 @@
 #! /bin/sh -e
 #
-# Map cdrom, cdm, cdmrw, cd-r, cdrw, dvd, dvdrw, dvdram to suitable devices.
+# Map cdrom, cd-r, cdrw, dvd, dvdrw, dvdram, cdm, cdmrw, cdram
+# to suitable devices.
 # Prefers cd* for DVD-incapable and cdrom and dvd for read-only devices.
 # First parameter is the kernel device name.
 # Second parameter, if present, must be "-d" => output the full mapping.
@@ -11,13 +12,16 @@
 # BUS="scsi", KERNEL="scd[0-9]*", PROGRAM="/etc/udev/cdsymlinks.sh %k", SYMLINK="%c{1} %c{2} %c{3} %c{4} %c{5} %c{6}"
 # (this last one is "just in case")
 #
-# (c) 2004 Darren Salt <linux@youmustbejoking.demon.co.uk>
+# (c) 2004, 2005 Darren Salt <linux@youmustbejoking.demon.co.uk>
+#
+# Last modified: 2005-02-15
 
 test -e /proc/sys/dev/cdrom/info || exit 0
 
 # Defaults; it's better that you alter them in /etc/udev/cdsymlinks.conf
 OUTPUT='CD CDRW DVD DVDRW DVDRAM'
 NUMBERED_LINKS=1
+LINK_ZERO=0
 
 test -e /etc/udev/cdsymlinks.conf && . /etc/udev/cdsymlinks.conf
 
@@ -61,6 +65,7 @@
 setArray CDRs    `sed -re '/^Can write CD-R:/I!    d; s/.*://' /proc/sys/dev/cdrom/info`
 setArray CDMRWs  `sed -re '/^Can write MRW:/I!     d; s/.*://' /proc/sys/dev/cdrom/info`
 setArray CDMs    `sed -re '/^Can read MRW:/I!      d; s/.*://' /proc/sys/dev/cdrom/info`
+setArray CDRAMs  `sed -re '/^Can write RAM:/I!     d; s/.*://' /proc/sys/dev/cdrom/info`
 
 # How many devices do we have?
 NumDevs=$(($DEVICES-1))
@@ -80,6 +85,7 @@
   test "`ix CDRs $i`"    != '' || ixs CDRs $i 0
   test "`ix CDMRWs $i`"  != '' || ixs CDMRWs $i 0
   test "`ix CDMs $i`"    != '' || ixs CDMs $i 0
+  test "`ix CDRAMs $i`"  != '' || ixs CDRAMs $i 0
 done
 
 DVDRAM=''
@@ -89,6 +95,7 @@
 CDR=''
 CDMRW=''
 CDM=''
+CDRAM=''
 CD=''
 
 # Calculate symlink->device mappings.
@@ -117,27 +124,31 @@
   test "`ix CDMs $i`" = 1 &&	CDM="$CDM `ix DEVICES $i`"
 done
 for i in $Count; do
+  test "`ix CDRAMs $i`" = 1 &&	CDRAM="$CDRAM `ix DEVICES $i`"
+done
+for i in $Count; do
 				CD="$CD `ix DEVICES $i`"
 done
 
 # Debug output
 if test "$DEBUG" = 1; then
   echo 'Devices:' `for i in $Count; do ix DEVICES $i; echo -n \ ; done`
-  echo 'DVDRAM :' `for i in $Count; do ix DVDRAMs $i; echo -n \ ; done` $DVDRAM
-  echo 'DVDRW  :' `for i in $Count; do ix DVDRWs  $i; echo -n \ ; done` $DVDRW
-  echo 'DVD    :' `for i in $Count; do ix DVDs    $i; echo -n \ ; done` $DVD
-  echo 'CDRW   :' `for i in $Count; do ix CDRWs   $i; echo -n \ ; done` $CDRW
+  echo 'CDROM  : (all)' $CD
   echo 'CD-R   :' `for i in $Count; do ix CDRs    $i; echo -n \ ; done` $CDR
+  echo 'CDRW   :' `for i in $Count; do ix CDRWs   $i; echo -n \ ; done` $CDRW
+  echo 'DVD    :' `for i in $Count; do ix DVDs    $i; echo -n \ ; done` $DVD
+  echo 'DVDRW  :' `for i in $Count; do ix DVDRWs  $i; echo -n \ ; done` $DVDRW
+  echo 'DVDRAM :' `for i in $Count; do ix DVDRAMs $i; echo -n \ ; done` $DVDRAM
   echo 'CDMRW  :' `for i in $Count; do ix CDMRWs  $i; echo -n \ ; done` $CDMRW
-  echo 'CDM    :' `for i in $Count; do ix CDMs    $i; echo -n \ ; done` $CDM
-  echo 'CDROM  : (all)' $CD
+  echo 'CDWMRW :' `for i in $Count; do ix CDMs    $i; echo -n \ ; done` $CDM
+  echo 'CDRAM  :' `for i in $Count; do ix CDRAMs  $i; echo -n \ ; done` $CDRAM
 fi
 
 # Prepare symlink names output
-output () {
+do_output () {
   test "`eval echo '$'$3`" = '' && return
   local i
-  local COUNT=''
+  local COUNT=$4
   local DEVLS="`ls -dl \"/dev/$2\" \"/dev/$2\"[0-9]* 2>/dev/null`"
   local PRESENT="`echo "$DEVLS" |
     sed -re 's!^.* /dev/('$2'[[:digit:]]*) -> [^[:space:]]+$!\1!'`"
@@ -148,6 +159,7 @@
     if test "$DEVPRESENT" != ""; then
       # Existing symlinks found - don't output a new one.
       # If the target dev ($1) is the current dev ($i), we output their names.
+      test -z "$4" || return;
       test "$1" = "$i" && echo " $DEVPRESENT" | sed -e 'N; $ s/\n/ /'
     else
       # If we found no existing symlinks for the target device...
@@ -156,15 +168,17 @@
       # symlink is created by udev as a result of use of this program, we
       # DON'T want different output!
       until notin PRESENT "$2$COUNT"; do
+        test -z "$4" || return;
 	COUNT=$(($COUNT+1))
       done
       # If the target dev ($1) is the current dev ($i), we output its name.
-      if test $(($NUMBERED_LINKS)) -ne 0 || test "$COUNT" = ''; then
-	test "$i" = "$1" && echo -n " $2$COUNT"
+      if test $(($NUMBERED_LINKS)) -ne 0 || test -z "$COUNT"; then
+	test "$i" != "$1" || echo -n " $2$COUNT"
       fi
       # If the link isn't in our "existing links" list, add it and increment
       # our counter.
-      if test ! -e "/dev/$2$COUNT"; then
+      if notin PRESENT "$2$COUNT"; then
+        test -z "$4" || return;
 	PRESENT="$PRESENT\n$2$COUNT"
 	COUNT=$(($COUNT+1))
       fi
@@ -172,13 +186,19 @@
   done
 }
 
+output () {
+  do_output "$@"
+  test $(($LINK_ZERO)) -eq 0 || do_output "$@" 0
+}
+
 # And output it
 notin OUTPUT CD     || echo -n "`output "$1" cdrom CD`"
-notin OUTPUT CDMRW  || echo -n "`output "$1" cdmrw CDM`"
-notin OUTPUT CDWMRW || echo -n "`output "$1" cdwmrw CDMRW`"
 notin OUTPUT CDR    || echo -n "`output "$1" cd-r CDR`"
 notin OUTPUT CDRW   || echo -n "`output "$1" cdrw CDRW`"
 notin OUTPUT DVD    || echo -n "`output "$1" dvd DVD`"
 notin OUTPUT DVDRW  || echo -n "`output "$1" dvdrw DVDRW`"
 notin OUTPUT DVDRAM || echo -n "`output "$1" dvdram DVDRAM`"
+notin OUTPUT CDMRW  || echo -n "`output "$1" cdmrw CDM`"
+notin OUTPUT CDWMRW || echo -n "`output "$1" cdwmrw CDMRW`"
+notin OUTPUT CDRAM  || echo -n "`output "$1" cdram CDRAM`"
 echo

Re: new release of udev?

[Kay Sievers]

On Thu, 2005-05-19 at 18:09 +0200, Marco d'Itri wrote:
> On May 19, Kay Sievers <kay.sievers@vrfy.org> wrote:
> 
> > > As I explained in our private discussion, this is complex and does not
> > > solve the SYMLINK problem: users would still not be able to override
> > > the distribution SYMLINK directives without using last_rule, which is
> > > not an option because it breaks RUN processing.
> > Well, SYMLINK is a list not a single value. Why does someone want to
> > supress the additional system-supplied symlinks?
> Why not? I think it's a very reasonable request. Different people have
> different ideas about /dev.

Well I still don't see a real need for this. Anyway, what about some
"final assignments" instead:
  GROUP:="mygroup" or
  SYMLINK:="mylink"
would set the value unchangeable for later rules. That may give us finer
grained control and if you leave the permissions alone with your
user-rule you still get the systems default.

Thanks,
Kay



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_idt12&alloc_id\x16344&op=click
_______________________________________________
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: new release of udev?

[Marco d'Itri]

[-- Attachment #1.1: Type: text/plain, Size: 882 bytes --]

On May 20, Kay Sievers <kay.sievers@vrfy.org> wrote:

> > Why not? I think it's a very reasonable request. Different people have
> > different ideas about /dev.
> 
> Well I still don't see a real need for this. Anyway, what about some
> "final assignments" instead:
>   GROUP:="mygroup" or
>   SYMLINK:="mylink"
> would set the value unchangeable for later rules. That may give us finer
> grained control and if you leave the permissions alone with your
> user-rule you still get the systems default.

I don't get it... Now you invented a third kind of assignment, and you
say that all this is simpler to use and to understand than just
supporting OPTIONS="last_run_rule" (which would also allow overriding
the RUN rules and simplify the rules for the console devices).

I'm attaching a patch which shows how simple supporting this would be.

-- 
ciao,
Marco

[-- Attachment #1.2: last_run_rule.diff --]
[-- Type: text/plain, Size: 2522 bytes --]

diff -ruNp udev-058.orig/udev_rules.c udev-058/udev_rules.c
--- udev-058.orig/udev_rules.c	2005-05-20 22:18:28.000000000 +0200
+++ udev-058/udev_rules.c	2005-05-22 02:48:33.000000000 +0200
@@ -942,7 +942,7 @@ int udev_rules_get_run(struct udevice *u
 		dbg("add run '%s'", program);
 		name_list_add(&udev->run_list, program, 0);
 
-		if (rule->last_rule) {
+		if (rule->last_run_rule) {
 			dbg("last rule to be applied");
 			break;
 		}
diff -ruNp udev-058.orig/udev_rules.h udev-058/udev_rules.h
--- udev-058.orig/udev_rules.h	2005-05-20 22:18:28.000000000 +0200
+++ udev-058/udev_rules.h	2005-05-22 02:49:10.000000000 +0200
@@ -47,6 +47,7 @@
 #define KEY_OPTIONS		"OPTIONS"
 
 #define OPTION_LAST_RULE	"last_rule"
+#define OPTION_LAST_RUN_RULE	"last_run_rule"
 #define OPTION_IGNORE_DEVICE	"ignore_device"
 #define OPTION_IGNORE_REMOVE	"ignore_remove"
 #define OPTION_PARTITIONS	"all_partitions"
@@ -102,6 +103,7 @@ struct udev_rule {
 	char run[PATH_SIZE];
 
 	int last_rule;
+	int last_run_rule;
 	int ignore_device;
 	int ignore_remove;
 	int partitions;
diff -ruNp udev-058.orig/udev_rules_parse.c udev-058/udev_rules_parse.c
--- udev-058.orig/udev_rules_parse.c	2005-05-20 22:18:28.000000000 +0200
+++ udev-058/udev_rules_parse.c	2005-05-22 02:52:05.000000000 +0200
@@ -53,11 +53,13 @@ static int add_config_dev(struct udev_ru
 	    "sysfs_file[0]='%s', sysfs_value[0]='%s', "
 	    "kernel='%s', program='%s', result='%s', "
 	    "owner='%s', group='%s', mode=%#o, "
-	    "all_partions=%u, ignore_remove=%u, ignore_device=%u, last_rule=%u",
+	    "all_partions=%u, ignore_remove=%u, ignore_device=%u, "
+	    "last_rule=%u, last_run_rule=%u",
 	    rule->name, rule->symlink, rule->bus, rule->id,
 	    rule->sysfs_pair[0].name, rule->sysfs_pair[0].value,
 	    rule->kernel, rule->program, rule->result, rule->owner, rule->group, rule->mode,
-	    rule->partitions, rule->ignore_remove, rule->ignore_device, rule->last_rule);
+	    rule->partitions, rule->ignore_remove, rule->ignore_device,
+	    rule->last_rule, rule->last_run_rule);
 
 	return 0;
 }
@@ -397,6 +399,10 @@ static int rules_parse(const char *filen
 					dbg("last rule to be applied");
 					rule.last_rule = 1;
 				}
+				if (strstr(value, OPTION_LAST_RUN RULE) != NULL) {
+					dbg("last run rule to be applied");
+					rule.last_run_rule = 1;
+				}
 				if (strstr(value, OPTION_IGNORE_DEVICE) != NULL) {
 					dbg("device should be ignored");
 					rule.ignore_device = 1;

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: new release of udev?

[Kay Sievers]

On Sun, May 22, 2005 at 02:59:28AM +0200, Marco d'Itri wrote:
> On May 20, Kay Sievers <kay.sievers@vrfy.org> wrote:
> 
> > > Why not? I think it's a very reasonable request. Different people have
> > > different ideas about /dev.
> > 
> > Well I still don't see a real need for this. Anyway, what about some
> > "final assignments" instead:
> >   GROUP:="mygroup" or
> >   SYMLINK:="mylink"
> > would set the value unchangeable for later rules. That may give us finer
> > grained control and if you leave the permissions alone with your
> > user-rule you still get the systems default.
> 
> I don't get it... Now you invented a third kind of assignment, and you
> say that all this is simpler to use and to understand than just
> supporting OPTIONS="last_run_rule" (which would also allow overriding
> the RUN rules and simplify the rules for the console devices).
> 
> I'm attaching a patch which shows how simple supporting this would be.

Too simple! How do you control symlinks, control permissions with
a user-rule. You want a last_symlink_rule, last_permission_rule? I will
implement := final assigments that prevent changes by later rules and
everything should work.

Kay


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_idt12&alloc_id\x16344&op=click
_______________________________________________
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: new release of udev?

[Marco d'Itri]

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

On May 22, Kay Sievers <kay.sievers@vrfy.org> wrote:

> Too simple! How do you control symlinks, control permissions with
> a user-rule. You want a last_symlink_rule, last_permission_rule? I will
No. Everything would work exactly as when NAME rules were terminal.

Since we can't get an agreement on this solution, what about a different
scheme? We could have = and += assignments: when used with elements like
SYMLINK and RUN the first would reset all previous assignments, and the
second would add it.
This way it would be possible to easily override any value, even to remove
any other with rules like SUBSYSTEM="vc", RUN="".

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: new release of udev?

[Kay Sievers]

On Sun, May 22, 2005 at 02:01:21PM +0200, Marco d'Itri wrote:
> On May 22, Kay Sievers <kay.sievers@vrfy.org> wrote:
> 
> > Too simple! How do you control symlinks, control permissions with
> > a user-rule. You want a last_symlink_rule, last_permission_rule? I will
> No. Everything would work exactly as when NAME rules were terminal.
> 
> Since we can't get an agreement on this solution, what about a different
> scheme? We could have = and += assignments: when used with elements like
> SYMLINK and RUN the first would reset all previous assignments, and the
> second would add it.
> This way it would be possible to easily override any value, even to remove
> any other with rules like SUBSYSTEM="vc", RUN="".

It was _you_ who asked to be able to overwrite the system specified rules
for symlinks. That's not possible this way. And again, how do you prevent
overriding the permissions from later system specified rules?

Kay


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_idt12&alloc_id\x16344&op=click
_______________________________________________
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: new release of udev?

[Marco d'Itri]

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

On May 22, Kay Sievers <kay.sievers@vrfy.org> wrote:

> It was _you_ who asked to be able to overwrite the system specified rules
> for symlinks. That's not possible this way. And again, how do you prevent
Sure it is: if you want to override any previous value you use SYMLINK=
instead of the usual SYMLINK+=.

> overriding the permissions from later system specified rules?
By documenting that system rules files are installed only in specific
parts of the name space, this is something which is needed for every
scheme.

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: new release of udev?

[Kay Sievers]

On Sun, May 22, 2005 at 02:55:18PM +0200, Marco d'Itri wrote:
> On May 22, Kay Sievers <kay.sievers@vrfy.org> wrote:
> 
> > It was _you_ who asked to be able to overwrite the system specified rules
> > for symlinks. That's not possible this way. And again, how do you prevent
> Sure it is: if you want to override any previous value you use SYMLINK> instead of the usual SYMLINK+=.

System-supplied rules are usually _not_ "previous". This will not work.

> > overriding the permissions from later system specified rules?
> By documenting that system rules files are installed only in specific
> parts of the name space, this is something which is needed for every
> scheme.

What scheme? What namespace? What documentation? Care to be more
specific?

Kay


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_idt12&alloc_id\x16344&op=click
_______________________________________________
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: new release of udev?

[Marco d'Itri]

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

On May 22, Kay Sievers <kay.sievers@vrfy.org> wrote:

> > > It was _you_ who asked to be able to overwrite the system specified rules
> > > for symlinks. That's not possible this way. And again, how do you prevent
> > Sure it is: if you want to override any previous value you use SYMLINK=
> > instead of the usual SYMLINK+=.
> System-supplied rules are usually _not_ "previous". This will not work.
Usually? Users will put their custom rules where it's needed to make
them work, I do not think this is a great argument.

> > > overriding the permissions from later system specified rules?
> > By documenting that system rules files are installed only in specific
> > parts of the name space, this is something which is needed for every
> > scheme.
> What scheme? What namespace? What documentation? Care to be more
> specific?
The rules.d/ directory file names. For the debian package I'm documenting
a policy like "all default permissions are set before 030_*" and "RUN
rules must be set from z40_* onward" (the actual values will change).
If the order of rules is important, then this needs to be documented to
allow users and package maintainers to choose the right file names.

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: new release of udev?

[Kay Sievers]

On Sun, May 22, 2005 at 03:07:56PM +0200, Marco d'Itri wrote:
> On May 22, Kay Sievers <kay.sievers@vrfy.org> wrote:
> 
> > > > It was _you_ who asked to be able to overwrite the system specified rules
> > > > for symlinks. That's not possible this way. And again, how do you prevent
> > > Sure it is: if you want to override any previous value you use SYMLINK> > > instead of the usual SYMLINK+=.
> > System-supplied rules are usually _not_ "previous". This will not work.
> Usually? Users will put their custom rules where it's needed to make
> them work, I do not think this is a great argument.

Well, I personaly prefer to put _all_ my custom rules in _one_ file.
Your solution solves only _your_ problem, which _is_ a great argument.

> > > > overriding the permissions from later system specified rules?
> > > By documenting that system rules files are installed only in specific
> > > parts of the name space, this is something which is needed for every
> > > scheme.
> > What scheme? What namespace? What documentation? Care to be more
> > specific?
> The rules.d/ directory file names. For the debian package I'm documenting
> a policy like "all default permissions are set before 030_*" and "RUN
> rules must be set from z40_* onward" (the actual values will change).
> If the order of rules is important, then this needs to be documented to
> allow users and package maintainers to choose the right file names.

Well, sounds like a pretty complicated requirement to solve a simple problem.

Anyway, I will do the "final assignments". Just ignore it if you don't
like it. :)
I see no problem to clear a value list if "=" is used instead of '+='.
The parser already supports this, I wanted to do this somtimes anyway.

I will _not_ add any more OPTIONS for individual keys like the "last_run_rule",
stuff. That belongs to the key operation itself not in the OPTIONS.

Kay


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_idt12&alloc_id\x16344&op=click
_______________________________________________
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: new release of udev?

[Hannes Reinecke]

Marco d'Itri wrote:
> On May 22, Kay Sievers <kay.sievers@vrfy.org> wrote:
> 
>>It was _you_ who asked to be able to overwrite the system specified rules
>>for symlinks. That's not possible this way. And again, how do you prevent
> Sure it is: if you want to override any previous value you use SYMLINK> instead of the usual SYMLINK+=.
> 
No. Definitely not.
This would break _every_ rule file out there as the current
specification for SYMLINK= is 'add to the existing SYMLINK'.
The semantics _have_ to stay the same. If you want different
funtionality, use different symbols.
Otherwise you end up in maintenance hell.

But you are correct in one point, that is that the 'reset symlinks list'
functionality is not provided.

So I propose a new type of assignment,

SYMLINK%
which resets the list and add the argument as the first element in that
list.

Then we'll have:

SYMLINK%= (reset and add to list)
SYMLINK= (add to list)
SYMLINK:= (add and terminate list)

which make for a full set of modifications.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke			hare@suse.de
SuSE Linux AG				S390 & zSeries
Maxfeldstraße 5				+49 911 74053 688
90409 Nürnberg				http://www.suse.de


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_idt12&alloc_id\x16344&opÃk
_______________________________________________
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: new release of udev?

[Marco d'Itri]

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

On May 23, Hannes Reinecke <hare@suse.de> wrote:

> The semantics _have_ to stay the same. If you want different
Wake up, it has already changed by not making NAME rules terminal
anymore.

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: new release of udev?

[Marco d'Itri]

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

On May 22, Kay Sievers <kay.sievers@vrfy.org> wrote:

> Well, I personaly prefer to put _all_ my custom rules in _one_ file.
> Your solution solves only _your_ problem, which _is_ a great argument.
Looks like different people have different problems...

> > The rules.d/ directory file names. For the debian package I'm documenting
> > a policy like "all default permissions are set before 030_*" and "RUN
> > rules must be set from z40_* onward" (the actual values will change).
> > If the order of rules is important, then this needs to be documented to
> > allow users and package maintainers to choose the right file names.
> Well, sounds like a pretty complicated requirement to solve a simple problem.
This is something needed for all proposed schemes, none of them is
order-indepented.

> Anyway, I will do the "final assignments". Just ignore it if you don't
> like it. :)
> I see no problem to clear a value list if "=" is used instead of '+='.
> The parser already supports this, I wanted to do this somtimes anyway.
> 
> I will _not_ add any more OPTIONS for individual keys like the "last_run_rule",
> stuff. That belongs to the key operation itself not in the OPTIONS.
OK. I can live with this just as well as long as you can add support for
+= and the revised =.

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: new release of udev?

[Marco d'Itri]

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

On May 23, Marco d'Itri <md@Linux.IT> wrote:

> > Anyway, I will do the "final assignments". Just ignore it if you don't
> > like it. :)
> > I see no problem to clear a value list if "=" is used instead of '+='.
> > The parser already supports this, I wanted to do this somtimes anyway.
> > 
> > I will _not_ add any more OPTIONS for individual keys like the "last_run_rule",
> > stuff. That belongs to the key operation itself not in the OPTIONS.
> OK. I can live with this just as well as long as you can add support for
> += and the revised =.

Are you ready to merge support for +=? I need to upload a debian package
of a more recent release of udev to support 2.6.12, and without this
feature it would be very hard, as we discussed last month.

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: new release of udev?

[Kay Sievers]

On Mon, Jun 20, 2005 at 08:10:34PM +0200, Marco d'Itri wrote:
> On May 23, Marco d'Itri <md@Linux.IT> wrote:
> 
> > > Anyway, I will do the "final assignments". Just ignore it if you don't
> > > like it. :)
> > > I see no problem to clear a value list if "=" is used instead of '+='.
> > > The parser already supports this, I wanted to do this somtimes anyway.
> > > 
> > > I will _not_ add any more OPTIONS for individual keys like the "last_run_rule",
> > > stuff. That belongs to the key operation itself not in the OPTIONS.
> > OK. I can live with this just as well as long as you can add support for
> > += and the revised =.
> 
> Are you ready to merge support for +=?

Yes, it's working. Currently it's somehting like this:
  SYMLINK+="abc"
    add a value to the list

  SYMLINK="abc"
    clear the liat and assign this single value

  SYMLINK=""
    clear the list

> I need to upload a debian package
> of a more recent release of udev to support 2.6.12, and without this
> feature it would be very hard, as we discussed last month.

It will be something like this:
  http://ehlo.org/~kay/gitweb.cgi?p=linux/hotplug/udev-kay.git;a=summary

I'm still working on it and we are still in a testing-phase, but it
should be ready to go upstream in the next few days...

Kay


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&op=click
_______________________________________________
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