All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kay Sievers <kay.sievers@vrfy.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: Problems using scsi_id with udevstart
Date: Wed, 06 Oct 2004 23:08:04 +0000	[thread overview]
Message-ID: <20041006230804.GA11754@vrfy.org> (raw)
In-Reply-To: <1097019226.2300.38.camel@bluto.andrew>

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

On Wed, Oct 06, 2004 at 03:24:58PM -0700, Greg KH wrote:
> On Wed, Oct 06, 2004 at 11:39:17PM +0200, Kay Sievers wrote:
> > On Wed, Oct 06, 2004 at 03:22:03PM -0600, Andrew Patterson wrote:
> > > On Wed, 2004-10-06 at 21:13 +0200, Kay Sievers wrote:
> > > > On Wed, 2004-10-06 at 12:42 -0600, Andrew Patterson wrote:
> > > > > On Wed, 2004-10-06 at 09:59 -0700, Patrick Mansfield wrote:
> > > > > > On Wed, Oct 06, 2004 at 10:26:13AM -0600, Andrew Patterson wrote:
> > > > > > 
> > > > > > > Note: here is the error you get when scsi_id is run without any
> > > > > > > parameters:
> > > > > > > 
> > > > > > > # /sbin/scsi_id
> > > > > > > -s must be specified
> > > > > > 
> > > > > > For the udev PROGRAM rules with no arguments, it is effectively invoked
> > > > > > like this (well there are other environment values but scsi_id only cares
> > > > > > about DEVPATH):
> > > > > > 
> > > > > > DEVPATH=/block/sda /sbin/scsi_id block
> > > > > > 
> > > > > 
> > > > > This is what I thought was supposed to happen.  I printed out the
> > > > > arguments and the environment when scsi_id was invoked through
> > > > > udevstart.  No arguments were passed and UDEVPATH was always set
> > > > > to /class/net/lo for every path in /sys.  Note that DEVNAME does seem to
> > > > > be set correctly.
> > > > 
> > > > Yes, this is a bug. We need to export the DEVPATH for the callout if we
> > > > run as udevstart. I will fix that now.
> > > 
> > > So did you confirm that the subsystem is indeed being passed as an
> > > argument when running udevstart as well?  My testing shows no.  I think
> > > you need both to make this work.
> > 
> > Yes, when udevstart was running we didn't set the environment and the
> > subsystem argument for the callouts the dev.d/ scripts.
> > 
> > Here is a fix, that sets that with every udevstart iteration, corrects
> > argv[0] to be the basename() only not the whole path  and adds a test
> > for invoking callouts without arguments.
> 
> Applied, thanks.

Here is the correction for the dev.d/ scripts too. We should pass
the right argv[0] here too. A script may depend on the right value, as
udev does with udev/udevstart.

Here is the old version:
  [pid  4692] execve("/etc/dev.d/default/log.dev", ["./udev", "block"], [/* 41 vars */]) = 0

this the new one:
  [pid  9832] execve("/etc/dev.d/default/log.dev", ["/etc/dev.d/default/log.dev", "block"], [/* 41 vars */]) = 0

Thanks,
Kay

[-- Attachment #2: udev-dev.d-argv0-fix-01.patch --]
[-- Type: text/plain, Size: 963 bytes --]

===== dev_d.c 1.10 vs edited =====
--- 1.10/dev_d.c	2004-09-20 16:02:44 +02:00
+++ edited/dev_d.c	2004-10-07 00:57:31 +02:00
@@ -39,6 +39,7 @@ static int run_program(char *name)
 {
 	pid_t pid;
 	int fd;
+	char *argv[3];
 
 	dbg("running %s", name);
 
@@ -54,7 +55,12 @@ static int run_program(char *name)
 			dup2(fd, STDERR_FILENO);
 		}
 		close(fd);
-		execv(name, main_argv);
+
+		argv[0] = name;
+		argv[1] = main_argv[1];
+		argv[2] = NULL;
+
+		execv(name, argv);
 		dbg("exec of child failed");
 		exit(1);
 	case -1:
===== namedev.c 1.148 vs edited =====
--- 1.148/namedev.c	2004-10-06 23:27:35 +02:00
+++ edited/namedev.c	2004-10-07 00:51:40 +02:00
@@ -450,11 +450,6 @@ static int execute_program(const char *p
 		dbg("execute '%s' with subsystem '%s' argument", arg, argv[1]);
 	}
 
-	/* set basename() only */
-	pos = strrchr(argv[0], '/');
-	if (pos != NULL)
-		argv[0] = &pos[1];
-
 	retval = pipe(fds);
 	if (retval != 0) {
 		dbg("pipe failed");

  parent reply	other threads:[~2004-10-06 23:08 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-05 23:33 Problems using scsi_id with udevstart Andrew Patterson
2004-10-05 23:53 ` Patrick Mansfield
2004-10-05 23:55 ` Kay Sievers
2004-10-06 16:20 ` Andrew Patterson
2004-10-06 16:26 ` Andrew Patterson
2004-10-06 16:44 ` Kay Sievers
2004-10-06 16:59 ` Patrick Mansfield
2004-10-06 17:33 ` Andrew Patterson
2004-10-06 18:07 ` Kay Sievers
2004-10-06 18:42 ` Andrew Patterson
2004-10-06 19:13 ` Kay Sievers
2004-10-06 21:22 ` Andrew Patterson
2004-10-06 21:39 ` Kay Sievers
2004-10-06 22:24 ` Greg KH
2004-10-06 22:28 ` Andrew Patterson
2004-10-06 23:08 ` Kay Sievers [this message]
2004-10-06 23:19 ` Greg KH

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=20041006230804.GA11754@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.