linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] udev: udevd shall inform us abot trouble
@ 2004-09-08  7:18 Denis Vlasenko
  2004-09-10 20:30 ` Greg KH
  0 siblings, 1 reply; 7+ messages in thread
From: Denis Vlasenko @ 2004-09-08  7:18 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-kernel

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

Hi Greg,

I found out why udev didn't work for me.
At first I compiled it with wrong install path ($DESTDIR).
On subsequent recompiles with corrected DESTDIR binaries
were still compiled with old DESTDIR hardcoded into them.

I think this Make rule is generating a udev_version.h:

# Rules on how to create the generated header files
udev_version.h:
        @echo \#define UDEV_VERSION             \"$(VERSION)\" > $@
        @echo \#define UDEV_ROOT                \"$(udevdir)/\" >> $@
        @echo \#define UDEV_DB                  \"$(udevdir)/.udev.tdb\" >> $@
        @echo \#define UDEV_CONFIG_DIR          \"$(configdir)\" >> $@
        @echo \#define UDEV_CONFIG_FILE         \"$(configdir)/udev.conf\" >> $@
        @echo \#define UDEV_RULES_FILE          \"$(configdir)/rules.d\" >> $@
        @echo \#define UDEV_PERMISSION_FILE     \"$(configdir)/permissions.d\" >> $@
        @echo \#define UDEV_LOG_DEFAULT         \"yes\" >> $@
        @echo \#define UDEV_BIN                 \"$(DESTDIR)$(sbindir)/udev\" >> $@
        @echo \#define UDEVD_BIN                \"$(DESTDIR)$(sbindir)/udevd\" >> $@

which is not re-created even if DESTDIR has changed.

As a result, udevd was trying to exec udev with wrong path.

I built udev with:

USE_LOG = true
DEBUG = false

but udevd does not log anything under such setting (all
udevd messages are coded as debug messages).

This patch improves situation by changing some dbg()'s
into info()'s.

I run tested this change. udevd will report failure into
syslog now.

Please apply.
--
vda

[-- Attachment #2: udevd.c.logging.patch --]
[-- Type: text/x-diff, Size: 3717 bytes --]

--- udevd.c.orig	Fri Jul  9 20:59:09 2004
+++ udevd.c	Thu Sep  2 09:46:43 2004
@@ -92,7 +92,7 @@ static struct hotplug_msg *msg_create(vo
 
 	new_msg = malloc(sizeof(struct hotplug_msg));
 	if (new_msg == NULL)
-		dbg("error malloc");
+		info("error malloc");
 	return new_msg;
 }
 
@@ -146,11 +146,11 @@ static void udev_run(struct hotplug_msg 
 	case 0:
 		/* child */
 		execle(udev_bin, "udev", msg->subsystem, NULL, env);
-		dbg("exec of child failed");
+		info("exec of child failed");
 		exit(1);
 		break;
 	case -1:
-		dbg("fork of child failed");
+		info("fork of child failed");
 		run_queue_delete(msg);
 		/* note: we never managed to run, so we had no impact on 
 		 * running_with_devpath(), so don't bother setting run_exec_q
@@ -255,7 +255,7 @@ static void handle_msg(int sock)
 
 	msg = msg_create();
 	if (msg == NULL) {
-		dbg("unable to store message");
+		info("unable to store message");
 		return;
 	}
 
@@ -271,24 +271,24 @@ static void handle_msg(int sock)
 	retval = recvmsg(sock, &smsg, 0);
 	if (retval <  0) {
 		if (errno != EINTR)
-			dbg("unable to receive message");
+			info("unable to receive message");
 		return;
 	}
 	cmsg = CMSG_FIRSTHDR(&smsg);
 	cred = (struct ucred *) CMSG_DATA(cmsg);
 
 	if (cmsg == NULL || cmsg->cmsg_type != SCM_CREDENTIALS) {
-		dbg("no sender credentials received, message ignored");
+		info("no sender credentials received, message ignored");
 		goto skip;
 	}
 
 	if (cred->uid != 0) {
-		dbg("sender uid=%i, message ignored", cred->uid);
+		info("sender uid=%i, message ignored", cred->uid);
 		goto skip;
 	}
 
 	if (strncmp(msg->magic, UDEV_MAGIC, sizeof(UDEV_MAGIC)) != 0 ) {
-		dbg("message magic '%s' doesn't match, ignore it", msg->magic);
+		info("message magic '%s' doesn't match, ignore it", msg->magic);
 		goto skip;
 	}
 
@@ -326,7 +326,7 @@ __attribute__((regparm(0))) static void 
 			goto do_write;
 			break;
 		default:
-			dbg("unhandled signal %d", signum);
+			info("unhandled signal %d", signum);
 			return;
 	}
 	
@@ -337,7 +337,7 @@ do_write:
 	if (!sig_flag) {
 		rc = write(pipefds[1],&signum,sizeof(signum));
 		if (rc < 0)
-			dbg("unable to write to pipe");
+			info("unable to write to pipe");
 		else
 			sig_flag = 1;
 	}
@@ -404,26 +404,26 @@ int main(int argc, char *argv[])
 	dbg("version %s", UDEV_VERSION);
 
 	if (getuid() != 0) {
-		dbg("need to be root, exit");
+		info("need to be root, exit");
 		exit(1);
 	}
 
 	/* setup signal handler pipe */
 	retval = pipe(pipefds);
 	if (retval < 0) {
-		dbg("error getting pipes: %s", strerror(errno));
+		info("error getting pipes: %s", strerror(errno));
 		exit(1);
 	}
 
 	retval = fcntl(pipefds[0], F_SETFL, O_NONBLOCK);
-		if (retval < 0) {
-		dbg("error fcntl on read pipe: %s", strerror(errno));
+	if (retval < 0) {
+		info("error fcntl on read pipe: %s", strerror(errno));
 		exit(1);
 	}
 
 	retval = fcntl(pipefds[1], F_SETFL, O_NONBLOCK);
 	if (retval < 0) {
-		dbg("error fcntl on write pipe: %s", strerror(errno));
+		info("error fcntl on write pipe: %s", strerror(errno));
 		exit(1);
 	}
 
@@ -444,14 +444,14 @@ int main(int argc, char *argv[])
 
 	ssock = socket(AF_LOCAL, SOCK_DGRAM, 0);
 	if (ssock == -1) {
-		dbg("error getting socket, exit");
+		info("error getting socket, exit");
 		exit(1);
 	}
 
 	/* the bind takes care of ensuring only one copy running */
 	retval = bind(ssock, (struct sockaddr *) &saddr, addrlen);
 	if (retval < 0) {
-		dbg("bind failed, exit");
+		info("bind failed, exit");
 		goto exit;
 	}
 
@@ -475,7 +475,7 @@ int main(int argc, char *argv[])
 
 		if (retval < 0) {
 			if (errno != EINTR)
-				dbg("error in select: %s", strerror(errno));
+				info("error in select: %s", strerror(errno));
 			continue;
 		}
 

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] udev: udevd shall inform us abot trouble
  2004-09-08  7:18 [PATCH] udev: udevd shall inform us abot trouble Denis Vlasenko
@ 2004-09-10 20:30 ` Greg KH
  2004-09-11 16:43   ` Denis Vlasenko
  0 siblings, 1 reply; 7+ messages in thread
From: Greg KH @ 2004-09-10 20:30 UTC (permalink / raw)
  To: Denis Vlasenko; +Cc: linux-kernel

On Wed, Sep 08, 2004 at 10:18:43AM +0300, Denis Vlasenko wrote:
> Hi Greg,
> 
> I found out why udev didn't work for me.
> At first I compiled it with wrong install path ($DESTDIR).
> On subsequent recompiles with corrected DESTDIR binaries
> were still compiled with old DESTDIR hardcoded into them.
> 
> I think this Make rule is generating a udev_version.h:
> 
> # Rules on how to create the generated header files
> udev_version.h:
>         @echo \#define UDEV_VERSION             \"$(VERSION)\" > $@
>         @echo \#define UDEV_ROOT                \"$(udevdir)/\" >> $@
>         @echo \#define UDEV_DB                  \"$(udevdir)/.udev.tdb\" >> $@
>         @echo \#define UDEV_CONFIG_DIR          \"$(configdir)\" >> $@
>         @echo \#define UDEV_CONFIG_FILE         \"$(configdir)/udev.conf\" >> $@
>         @echo \#define UDEV_RULES_FILE          \"$(configdir)/rules.d\" >> $@
>         @echo \#define UDEV_PERMISSION_FILE     \"$(configdir)/permissions.d\" >> $@
>         @echo \#define UDEV_LOG_DEFAULT         \"yes\" >> $@
>         @echo \#define UDEV_BIN                 \"$(DESTDIR)$(sbindir)/udev\" >> $@
>         @echo \#define UDEVD_BIN                \"$(DESTDIR)$(sbindir)/udevd\" >> $@
> 
> which is not re-created even if DESTDIR has changed.
> 
> As a result, udevd was trying to exec udev with wrong path.

Ick, not nice.

> I built udev with:
> 
> USE_LOG = true
> DEBUG = false
> 
> but udevd does not log anything under such setting (all
> udevd messages are coded as debug messages).
> 
> This patch improves situation by changing some dbg()'s
> into info()'s.

No, I don't like this change, as it increases the size of udevd pretty
unnecessarily (errors like what happened to you are very rare, and we
could blame them on pilot error...)

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] udev: udevd shall inform us abot trouble
  2004-09-10 20:30 ` Greg KH
@ 2004-09-11 16:43   ` Denis Vlasenko
  2004-09-11 17:48     ` Kevin P. Fleming
  0 siblings, 1 reply; 7+ messages in thread
From: Denis Vlasenko @ 2004-09-11 16:43 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-kernel

> > I built udev with:
> >
> > USE_LOG = true
> > DEBUG = false
> >
> > but udevd does not log anything under such setting (all
> > udevd messages are coded as debug messages).
> >
> > This patch improves situation by changing some dbg()'s
> > into info()'s.
>
> No, I don't like this change, as it increases the size of udevd pretty
> unnecessarily (errors like what happened to you are very rare, and we
> could blame them on pilot error...)

I do not fully agree, but it is not that important.

So far, udev is working fine for me.
I've seen only two regressons of udev versus devfs, both are not
very serious:

1. amixer races with udev if run directly after modprobe,
like this:

modprobe snd-via82xx
modprobe snd-mixer-oss
modprobe snd-pcm-oss
amixer set 'Master',0 90%,90% unmute
amixer set 'Master Mono',0 90% unmute
amixer set 'PCM',0 90%,90% unmute
amixer set 'Headphone',0 90%,90% unmute

Well, I lied a bit. These lines are from my home box, which is not
udev'ified yet. At the job, I sit on i815 box, and there amixer
fails to set volume. It happens 100% of the time. Adding "sleep 1"
after modprobing helps. With devfs it worked without sleep.

2. I have no processes on /dev/tty1. Nobody have open descriptors to it,
it is not a ctty for anyone. tty1 still has messages printed by init at boot
before init closed its stdin, stdout and stderr.

If I switch to vc1 and start to move a mouse (I have gpm running), it is
very sluggish. That's because hotplug+udev constantly registers and de-registers
vcs[a]N devices. Agian, I do not see such thing with devfs.
--
vda


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] udev: udevd shall inform us abot trouble
  2004-09-11 16:43   ` Denis Vlasenko
@ 2004-09-11 17:48     ` Kevin P. Fleming
  2004-09-11 18:22       ` Denis Vlasenko
  0 siblings, 1 reply; 7+ messages in thread
From: Kevin P. Fleming @ 2004-09-11 17:48 UTC (permalink / raw)
  To: Denis Vlasenko; +Cc: Greg KH, linux-kernel

Denis Vlasenko wrote:

> Well, I lied a bit. These lines are from my home box, which is not
> udev'ified yet. At the job, I sit on i815 box, and there amixer
> fails to set volume. It happens 100% of the time. Adding "sleep 1"
> after modprobing helps. With devfs it worked without sleep.

This is correct; with devfs, creation of device nodes during module 
loading was synchronous, so it was always (or nearly always) complete 
before modprobe returned. With udev, creation of device nodes is 
completely asynchronous, and may happen at _any_ time after the module 
has been loaded.

The real solution here is for people to re-think their system startup 
processes; if you need mixer settings applied at startup, then build a 
small script somewhere in /etc/hotplug.d or /etc/dev.d that applies them 
to the mixer _when it appears_.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] udev: udevd shall inform us abot trouble
  2004-09-11 17:48     ` Kevin P. Fleming
@ 2004-09-11 18:22       ` Denis Vlasenko
  2004-09-11 19:59         ` Kevin P. Fleming
  2004-09-12 16:58         ` Greg KH
  0 siblings, 2 replies; 7+ messages in thread
From: Denis Vlasenko @ 2004-09-11 18:22 UTC (permalink / raw)
  To: Kevin P. Fleming; +Cc: Greg KH, linux-kernel

On Saturday 11 September 2004 20:48, Kevin P. Fleming wrote:
> Denis Vlasenko wrote:
> > Well, I lied a bit. These lines are from my home box, which is not
> > udev'ified yet. At the job, I sit on i815 box, and there amixer
> > fails to set volume. It happens 100% of the time. Adding "sleep 1"
> > after modprobing helps. With devfs it worked without sleep.
>
> This is correct; with devfs, creation of device nodes during module
> loading was synchronous, so it was always (or nearly always) complete
> before modprobe returned. With udev, creation of device nodes is
> completely asynchronous, and may happen at _any_ time after the module
> has been loaded.

Yes. I know why it works differently.

> The real solution here is for people to re-think their system startup
> processes; if you need mixer settings applied at startup, then build a
> small script somewhere in /etc/hotplug.d or /etc/dev.d that applies them
> to the mixer _when it appears_.

As a user, I prefer to be able to use device right away after
modprobe. Imagine ethN appearing "sometime after" modprobe.
Would you like such behavior?
--
vda


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] udev: udevd shall inform us abot trouble
  2004-09-11 18:22       ` Denis Vlasenko
@ 2004-09-11 19:59         ` Kevin P. Fleming
  2004-09-12 16:58         ` Greg KH
  1 sibling, 0 replies; 7+ messages in thread
From: Kevin P. Fleming @ 2004-09-11 19:59 UTC (permalink / raw)
  To: Denis Vlasenko; +Cc: Greg KH, linux-kernel

Denis Vlasenko wrote:

> As a user, I prefer to be able to use device right away after
> modprobe. Imagine ethN appearing "sometime after" modprobe.
> Would you like such behavior?

Imagine that the device isn't plugged in when modprobe is run, but is 
plugged in later.

Imagine that the device is plugged in when modprobe is run, but some 
intermediate device (for example a USB hub) is not working, so when you 
correct if the device appears.

There are many more scenarios where true hotplug-based initialization 
makes more sense than otherwise.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] udev: udevd shall inform us abot trouble
  2004-09-11 18:22       ` Denis Vlasenko
  2004-09-11 19:59         ` Kevin P. Fleming
@ 2004-09-12 16:58         ` Greg KH
  1 sibling, 0 replies; 7+ messages in thread
From: Greg KH @ 2004-09-12 16:58 UTC (permalink / raw)
  To: Denis Vlasenko; +Cc: Kevin P. Fleming, linux-kernel

On Sat, Sep 11, 2004 at 09:22:36PM +0300, Denis Vlasenko wrote:
> > The real solution here is for people to re-think their system startup
> > processes; if you need mixer settings applied at startup, then build a
> > small script somewhere in /etc/hotplug.d or /etc/dev.d that applies them
> > to the mixer _when it appears_.
> 
> As a user, I prefer to be able to use device right away after
> modprobe. Imagine ethN appearing "sometime after" modprobe.
> Would you like such behavior?

That happens today without udev with my usb wireless and ethernet
devices all the time.

See Kay's message for how this should be fixed up in userspace to work
properly.  It's what gentoo has switched over too, with much success.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2004-09-12 17:10 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-09-08  7:18 [PATCH] udev: udevd shall inform us abot trouble Denis Vlasenko
2004-09-10 20:30 ` Greg KH
2004-09-11 16:43   ` Denis Vlasenko
2004-09-11 17:48     ` Kevin P. Fleming
2004-09-11 18:22       ` Denis Vlasenko
2004-09-11 19:59         ` Kevin P. Fleming
2004-09-12 16:58         ` Greg KH

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