Re: udev-067 and 2.6.12?

Re: udev-067 and 2.6.12?

[Alistair John Strachan]

On Tuesday 16 August 2005 23:33, David Brown wrote:
> Check out the release notes for udev 059
> I think your problem may be caused by the changes in that release
> and you should probably add the code below to your udev rules file
> <snip>
> RUN+="/sbin/udev_run_devd"
> </snip>
>
> I've noticed this problem as well loading firmware but everything was
> fixed when I made the two extra binaries in extras/run_directory and
> added the code above to my rules file
>
> - David Brown
>

(Sorry linux-hotplug-devel, I thought I'd add to CC after Greg's suggestion 
elsewhere in this thread).

Obviously, this fixed it. Thanks a lot for the hint.

I wouldn't mind knowing how to (from the README) "convert all the calls from 
the directories to explicit udev rules and get completely rid of the 
multiplexing". I'd like to not have to use backward compatibility stuff.

The problem was caused by me renaming the network device on my system from 
"eth1" to "wlan", and the lack of this legacy RUN meant hotplug wasn't doing 
the right thing wrt loading the driver/firmware.

What sort of udev rule am I looking at for both renaming AND fixing up the bad 
hotplug stuff? I've currently got:

KERNEL="eth?", SYSFS{address}="00:11:09:65:78:c7", NAME="lan"
KERNEL="eth?", SYSFS{address}="00:30:b4:00:00:00", NAME="wlan"

Which looks sensible. I think.

-- 
Cheers,
Alistair.

'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.


-------------------------------------------------------
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: udev-067 and 2.6.12?

[David Brown]

Hmmmm, never tried renaming my ethernet or wireless devices with udev rules.
Always just kept what they gave me...

but you might try
KERNEL="eth[0-9]*", SYSFS{address}="00:11:09:65:78:c7", NAME="wlan%n"
Maybe... not to sure about that though...

%n should be the number match so it will make eth0 become wlan0 etc.
might not quite be what you are looking for :-\

- David Brown

On 8/16/05, Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> On Tuesday 16 August 2005 23:33, David Brown wrote:
> > Check out the release notes for udev 059
> > I think your problem may be caused by the changes in that release
> > and you should probably add the code below to your udev rules file
> > <snip>
> > RUN+="/sbin/udev_run_devd"
> > </snip>
> >
> > I've noticed this problem as well loading firmware but everything was
> > fixed when I made the two extra binaries in extras/run_directory and
> > added the code above to my rules file
> >
> > - David Brown
> >
> 
> (Sorry linux-hotplug-devel, I thought I'd add to CC after Greg's suggestion
> elsewhere in this thread).
> 
> Obviously, this fixed it. Thanks a lot for the hint.
> 
> I wouldn't mind knowing how to (from the README) "convert all the calls from
> the directories to explicit udev rules and get completely rid of the
> multiplexing". I'd like to not have to use backward compatibility stuff.
> 
> The problem was caused by me renaming the network device on my system from
> "eth1" to "wlan", and the lack of this legacy RUN meant hotplug wasn't doing
> the right thing wrt loading the driver/firmware.
> 
> What sort of udev rule am I looking at for both renaming AND fixing up the bad
> hotplug stuff? I've currently got:
> 
> KERNEL="eth?", SYSFS{address}="00:11:09:65:78:c7", NAME="lan"
> KERNEL="eth?", SYSFS{address}="00:30:b4:00:00:00", NAME="wlan"
> 
> Which looks sensible. I think.
> 
> --
> Cheers,
> Alistair.
> 
> 'No sense being pessimistic, it probably wouldn't work anyway.'
> Third year Computer Science undergraduate.
> 1F2 55 South Clerk Street, Edinburgh, UK.
>


-------------------------------------------------------
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: udev-067 and 2.6.12?

[Alistair John Strachan]

On Tuesday 16 August 2005 23:49, Alistair John Strachan wrote:
> On Tuesday 16 August 2005 23:33, David Brown wrote:
> > Check out the release notes for udev 059
> > I think your problem may be caused by the changes in that release
> > and you should probably add the code below to your udev rules file
> > <snip>
> > RUN+="/sbin/udev_run_devd"
> > </snip>
> >
> > I've noticed this problem as well loading firmware but everything was
> > fixed when I made the two extra binaries in extras/run_directory and
> > added the code above to my rules file
> >
> > - David Brown
>
> (Sorry linux-hotplug-devel, I thought I'd add to CC after Greg's suggestion
> elsewhere in this thread).
>
> Obviously, this fixed it. Thanks a lot for the hint.

Okay, I've found a few problems with udev 067 so far.

Greg suggested changing comparisons in the udev rules to = instead of =, 
which makes sense (comparison versus assignment). There are several files in 
the etc/udev directory that don't observe this (frugalware/slackware).

Secondly, the stuff in run_directory doesn't link:

# make
cc -DUSE_LOG -O2 -march=k8 -mfpmath=sse -s -pipe -c -o run_directory.o 
run_directory.c
ld -s -o udev_run_devd udev_run_devd.o 
run_directory.o ../../udev.a ../../libsysfs/sysfs.a
ld: warning: cannot find entry symbol _start; defaulting to 00000000004000f0
udev_run_devd.o: In function `log_message':
udev_run_devd.c:(.text+0x9d): undefined reference to `vsyslog'
udev_run_devd.c:(.text+0xb6): undefined reference to `getenv'

GCC 4.0.1/binutils 2.16.91.0.2. I worked around it by linking with gcc instead 
(like the rest of udev does). This worked fine. I didn't compile udev or the 
run_directory stuff against klibc.

Finally, I'm sure this is my fault, but modules like "mousedev" and "sd_mod" 
don't get loaded by hotplug/udev when I plug in my mouse or pendrive after 
booting. This is because they are not actually dependencies of the modules 
usbhid and usb-storage, so they don't get loaded by modprobe.

udev 053 used to do this, 067 doesn't any more. I've got both the 
udev_run_devd and udev_run_hotplugd binaries compiled and in the right place; 
I stole the configuration from the gentoo rules. Any idea what's changed?

These are my now vastly simplified rules (no other rules files exist):
http://devzero.co.uk/~alistair/50-desktop.rules

-- 
Cheers,
Alistair.

'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.


-------------------------------------------------------
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: udev-067 and 2.6.12?

[David Brown]

Okay you can disable syslog or I had to make an extra C file and patch
the makefile to get it to work.

to disable syslog `make USE_LOGúlse`

- David Brown

== begin Makefile.patch =--- Makefile.old	2005-07-23 09:27:02.000000000 -0700
+++ Makefile	2005-07-24 22:52:21.000000000 -0700
@@ -145,7 +145,8 @@
 	udev_db.o			\
 	udev_rules.o			\
 	udev_rules_parse.o		\
-	udev_libc_wrapper.o
+	udev_libc_wrapper.o             \
+	udev_logger.o
 
 OBJS = \
 	udev.a			\
@@ -377,11 +378,6 @@
 	$(INSTALL_PROGRAM) -D $(INFO) $(DESTDIR)$(usrbindir)/$(INFO)
 	$(INSTALL_PROGRAM) -D $(TESTER) $(DESTDIR)$(usrbindir)/$(TESTER)
 	$(INSTALL_PROGRAM) -D $(STARTER) $(DESTDIR)$(sbindir)/$(STARTER)
-ifndef DESTDIR
-	- killall $(DAEMON)
-	- rm -rf $(udevdb)
-	- $(sbindir)/$(DAEMON) --daemon
-endif
 	@extras="$(EXTRAS)" ; for target in $$extras ; do \
 		echo $$target ; \
 		$(MAKE) prefix=$(prefix) LD="$(LD)" SYSFS="$(SYSFS)" \
== end Makefile.patch =
== begin udev_logger.c =#include <syslog.h>
#include <stdarg.h>

extern int udev_log_priority;

#ifdef USE_LOG
void log_message(int priority, const char *format, ...)
{
	va_list args;

	if (priority > udev_log_priority)
		return;

	va_start(args, format);
	vsyslog(priority, format, args);
	va_end(args);
}
#endif
== end udev_logger.c =
On 8/16/05, Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> On Tuesday 16 August 2005 23:49, Alistair John Strachan wrote:
> > On Tuesday 16 August 2005 23:33, David Brown wrote:
> > > Check out the release notes for udev 059
> > > I think your problem may be caused by the changes in that release
> > > and you should probably add the code below to your udev rules file
> > > <snip>
> > > RUN+="/sbin/udev_run_devd"
> > > </snip>
> > >
> > > I've noticed this problem as well loading firmware but everything was
> > > fixed when I made the two extra binaries in extras/run_directory and
> > > added the code above to my rules file
> > >
> > > - David Brown
> >
> > (Sorry linux-hotplug-devel, I thought I'd add to CC after Greg's suggestion
> > elsewhere in this thread).
> >
> > Obviously, this fixed it. Thanks a lot for the hint.
> 
> Okay, I've found a few problems with udev 067 so far.
> 
> Greg suggested changing comparisons in the udev rules to = instead of =,
> which makes sense (comparison versus assignment). There are several files in
> the etc/udev directory that don't observe this (frugalware/slackware).
> 
> Secondly, the stuff in run_directory doesn't link:
> 
> # make
> cc -DUSE_LOG -O2 -march=k8 -mfpmath=sse -s -pipe -c -o run_directory.o
> run_directory.c
> ld -s -o udev_run_devd udev_run_devd.o
> run_directory.o ../../udev.a ../../libsysfs/sysfs.a
> ld: warning: cannot find entry symbol _start; defaulting to 00000000004000f0
> udev_run_devd.o: In function `log_message':
> udev_run_devd.c:(.text+0x9d): undefined reference to `vsyslog'
> udev_run_devd.c:(.text+0xb6): undefined reference to `getenv'
> 
> GCC 4.0.1/binutils 2.16.91.0.2. I worked around it by linking with gcc instead
> (like the rest of udev does). This worked fine. I didn't compile udev or the
> run_directory stuff against klibc.
> 
> Finally, I'm sure this is my fault, but modules like "mousedev" and "sd_mod"
> don't get loaded by hotplug/udev when I plug in my mouse or pendrive after
> booting. This is because they are not actually dependencies of the modules
> usbhid and usb-storage, so they don't get loaded by modprobe.
> 
> udev 053 used to do this, 067 doesn't any more. I've got both the
> udev_run_devd and udev_run_hotplugd binaries compiled and in the right place;
> I stole the configuration from the gentoo rules. Any idea what's changed?
> 
> These are my now vastly simplified rules (no other rules files exist):
> http://devzero.co.uk/~alistair/50-desktop.rules
> 
> --
> Cheers,
> Alistair.
> 
> 'No sense being pessimistic, it probably wouldn't work anyway.'
> Third year Computer Science undergraduate.
> 1F2 55 South Clerk Street, Edinburgh, UK.
>


-------------------------------------------------------
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: udev-067 and 2.6.12?

[Kay Sievers]

On Wed, Aug 17, 2005 at 12:26:11AM +0100, Alistair John Strachan wrote:
> On Tuesday 16 August 2005 23:49, Alistair John Strachan wrote:
> > On Tuesday 16 August 2005 23:33, David Brown wrote:
> > > Check out the release notes for udev 059
> > > I think your problem may be caused by the changes in that release
> > > and you should probably add the code below to your udev rules file
> > > <snip>
> > > RUN+="/sbin/udev_run_devd"
> > > </snip>
> > >
> > > I've noticed this problem as well loading firmware but everything was
> > > fixed when I made the two extra binaries in extras/run_directory and
> > > added the code above to my rules file
> > >
> > > - David Brown
> >
> > (Sorry linux-hotplug-devel, I thought I'd add to CC after Greg's suggestion
> > elsewhere in this thread).
> >
> > Obviously, this fixed it. Thanks a lot for the hint.
> 
> Okay, I've found a few problems with udev 067 so far.
> 
> Greg suggested changing comparisons in the udev rules to = instead of =, 
> which makes sense (comparison versus assignment). There are several files in 
> the etc/udev directory that don't observe this (frugalware/slackware).

Yes, that's good to make the correct assignment. For now only SYMLINKwill reset former assigned values and you need SYMLINK+= and ENV{}= will
assing instead of match. All other keys should still work, but if we
require some more features for a key, we may need to change that in the
future.

> Secondly, the stuff in run_directory doesn't link:
> 
> # make
> cc -DUSE_LOG -O2 -march=k8 -mfpmath=sse -s -pipe -c -o run_directory.o 
> run_directory.c
> ld -s -o udev_run_devd udev_run_devd.o 
> run_directory.o ../../udev.a ../../libsysfs/sysfs.a
> ld: warning: cannot find entry symbol _start; defaulting to 00000000004000f0
> udev_run_devd.o: In function `log_message':
> udev_run_devd.c:(.text+0x9d): undefined reference to `vsyslog'
> udev_run_devd.c:(.text+0xb6): undefined reference to `getenv'
> 
> GCC 4.0.1/binutils 2.16.91.0.2. I worked around it by linking with gcc instead 
> (like the rest of udev does). This worked fine. I didn't compile udev or the 
> run_directory stuff against klibc.

Hmm, no other distro seems to have this problem. Did you overwrite
CFLAGS for the make?

> Finally, I'm sure this is my fault, but modules like "mousedev" and "sd_mod" 
> don't get loaded by hotplug/udev when I plug in my mouse or pendrive after 
> booting. This is because they are not actually dependencies of the modules 
> usbhid and usb-storage, so they don't get loaded by modprobe.

For scsi see here:
  http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hh3a22a2bb756566b7e18a57231bae9913e61da2;hbV18b5611bccf64a1e22f8cbcebe8ecba9713c9c;f=etc/udev/suse/udev.rules#l158

And better compile mousedev in the kernel. That does not make a lot of
sense as a module. If you really want a module, load it with an init-script.

> udev 053 used to do this, 067 doesn't any more. I've got both the 
> udev_run_devd and udev_run_hotplugd binaries compiled and in the right place; 
> I stole the configuration from the gentoo rules. Any idea what's changed?

No idea what's changed. Probably one of the hotplug agents is not
called, but we want to get rid of them anyway. :)

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

Re: udev-067 and 2.6.12?

[Arioch]

David Brown пишет:
> Hmmmm, never tried renaming my ethernet or wireless devices with udev rules..
> Always just kept what they gave me...

Maybe rename them later with toold like ifrename ?



-------------------------------------------------------
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: udev-067 and 2.6.12?

[Alistair John Strachan]

On Wednesday 17 August 2005 00:55, Kay Sievers wrote:
> On Wed, Aug 17, 2005 at 12:26:11AM +0100, Alistair John Strachan wrote:
> > On Tuesday 16 August 2005 23:49, Alistair John Strachan wrote:
> > > On Tuesday 16 August 2005 23:33, David Brown wrote:
> > > > Check out the release notes for udev 059
> > > > I think your problem may be caused by the changes in that release
> > > > and you should probably add the code below to your udev rules file
> > > > <snip>
> > > > RUN+="/sbin/udev_run_devd"
> > > > </snip>
> > > >
> > > > I've noticed this problem as well loading firmware but everything was
> > > > fixed when I made the two extra binaries in extras/run_directory and
> > > > added the code above to my rules file
> > > >
> > > > - David Brown
> > >
> > > (Sorry linux-hotplug-devel, I thought I'd add to CC after Greg's
> > > suggestion elsewhere in this thread).
> > >
> > > Obviously, this fixed it. Thanks a lot for the hint.
> >
> > Okay, I've found a few problems with udev 067 so far.
> >
> > Greg suggested changing comparisons in the udev rules to = instead of =,
> > which makes sense (comparison versus assignment). There are several files
> > in the etc/udev directory that don't observe this (frugalware/slackware).
>
> Yes, that's good to make the correct assignment. For now only SYMLINK> will reset former assigned values and you need SYMLINK+= and ENV{}= will
> assing instead of match. All other keys should still work, but if we
> require some more features for a key, we may need to change that in the
> future.
>
> > Secondly, the stuff in run_directory doesn't link:
> >
> > # make
> > cc -DUSE_LOG -O2 -march=k8 -mfpmath=sse -s -pipe -c -o run_directory.o
> > run_directory.c
> > ld -s -o udev_run_devd udev_run_devd.o
> > run_directory.o ../../udev.a ../../libsysfs/sysfs.a
> > ld: warning: cannot find entry symbol _start; defaulting to
> > 00000000004000f0 udev_run_devd.o: In function `log_message':
> > udev_run_devd.c:(.text+0x9d): undefined reference to `vsyslog'
> > udev_run_devd.c:(.text+0xb6): undefined reference to `getenv'
> >
> > GCC 4.0.1/binutils 2.16.91.0.2. I worked around it by linking with gcc
> > instead (like the rest of udev does). This worked fine. I didn't compile
> > udev or the run_directory stuff against klibc.
>
> Hmm, no other distro seems to have this problem. Did you overwrite
> CFLAGS for the make?

No. I typed "make" and edited nothing. I'm sceptical that this is a problem 
with "only" my configuration, since I've compiled literally hundreds of 
packages with a problem, and run_directory/ is the only thing I've ever seen 
not link bizarrely. I think the problem is that it's a mistake to use ld 
explicitly to link in the case where I want to also link in libc, and not use 
klibc. Many of the missing symbols were from libc.

>
> > Finally, I'm sure this is my fault, but modules like "mousedev" and
> > "sd_mod" don't get loaded by hotplug/udev when I plug in my mouse or
> > pendrive after booting. This is because they are not actually
> > dependencies of the modules usbhid and usb-storage, so they don't get
> > loaded by modprobe.
>
> For scsi see here:
>  
> http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hh3a22a2bb7565
>66b7e18a57231bae9913e61da2;hbV18b5611bccf64a1e22f8cbcebe8ecba9713c9c;f=etc
>/udev/suse/udev.rules#l158

This seems like a step backwards from what 053 was doing. I can't see how it's 
beneficial to not be intuitively loading useful modules without an explicit 
rule.

>
> And better compile mousedev in the kernel. That does not make a lot of
> sense as a module. If you really want a module, load it with an
> init-script.
>

Agreed, I used to run with an allbuiltin kernel because back in the early 
2.5s, it was your only option. When I migrated to udev I switched to modules 
before the udevstart program was mature, and was probably a bit overzealous 
compiling out as much as possible.

I still think this is a counter intuitive change.

>
> > udev 053 used to do this, 067 doesn't any more. I've got both the
> > udev_run_devd and udev_run_hotplugd binaries compiled and in the right
> > place; I stole the configuration from the gentoo rules. Any idea what's
> > changed?
>
> No idea what's changed. Probably one of the hotplug agents is not
> called, but we want to get rid of them anyway. :)

Well, I suppose this makes sense. What would really be nice is if udev didn't 
abandon people running none of the six supported distributions, and instead 
provided broken apart rules files (much like how debian does it), so that at 
least the raw, basic functionality is always going to be installed.

Things like automatically loading sd_mod when a scsi disk is added, and 
running the legacy devd/hotplugd helpers should really be done until there 
are 100% suitable replacements for them. udev promised not only automation, 
but an unparalleled minimum required configuration to work (I don't even have 
a modules.conf, or have to explicitly load any modules. It's great.)

-- 
Cheers,
Alistair.

'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.


-------------------------------------------------------
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: udev-067 and 2.6.12?

[Kay Sievers]

On Wed, Aug 17, 2005 at 09:26:08AM +0100, Alistair John Strachan wrote:
> On Wednesday 17 August 2005 00:55, Kay Sievers wrote:
> > On Wed, Aug 17, 2005 at 12:26:11AM +0100, Alistair John Strachan wrote:
> > > On Tuesday 16 August 2005 23:49, Alistair John Strachan wrote:

> > > # make
> > > cc -DUSE_LOG -O2 -march=k8 -mfpmath=sse -s -pipe -c -o run_directory.o
> > > run_directory.c
> > > ld -s -o udev_run_devd udev_run_devd.o
> > > run_directory.o ../../udev.a ../../libsysfs/sysfs.a
> > > ld: warning: cannot find entry symbol _start; defaulting to
> > > 00000000004000f0 udev_run_devd.o: In function `log_message':
> > > udev_run_devd.c:(.text+0x9d): undefined reference to `vsyslog'
> > > udev_run_devd.c:(.text+0xb6): undefined reference to `getenv'
> > >
> > > GCC 4.0.1/binutils 2.16.91.0.2. I worked around it by linking with gcc
> > > instead (like the rest of udev does). This worked fine. I didn't compile
> > > udev or the run_directory stuff against klibc.
> >
> > Hmm, no other distro seems to have this problem. Did you overwrite
> > CFLAGS for the make?
> 
> No. I typed "make" and edited nothing. I'm sceptical that this is a problem 
> with "only" my configuration, since I've compiled literally hundreds of 
> packages with a problem, and run_directory/ is the only thing I've ever seen 
> not link bizarrely. I think the problem is that it's a mistake to use ld 
> explicitly to link in the case where I want to also link in libc, and not use 
> klibc. Many of the missing symbols were from libc.

You may need to run make from the top-level directory of of the udev
tree with "make EXTRAS=extras/run_directory"?

> > > Finally, I'm sure this is my fault, but modules like "mousedev" and
> > > "sd_mod" don't get loaded by hotplug/udev when I plug in my mouse or
> > > pendrive after booting. This is because they are not actually
> > > dependencies of the modules usbhid and usb-storage, so they don't get
> > > loaded by modprobe.
> >
> > For scsi see here:
> >  
> > http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hh3a22a2bb7565
> >66b7e18a57231bae9913e61da2;hbV18b5611bccf64a1e22f8cbcebe8ecba9713c9c;f=etc
> >/udev/suse/udev.rules#l158
> 
> This seems like a step backwards from what 053 was doing. I can't see how it's 
> beneficial to not be intuitively loading useful modules without an explicit 
> rule.

I don't see any problem here. If the kernel has no dependency to load
the module, _you_ need to load it.

> > And better compile mousedev in the kernel. That does not make a lot of
> > sense as a module. If you really want a module, load it with an
> > init-script.
> >
> 
> Agreed, I used to run with an allbuiltin kernel because back in the early 
> 2.5s, it was your only option. When I migrated to udev I switched to modules 
> before the udevstart program was mature, and was probably a bit overzealous 
> compiling out as much as possible.
> 
> I still think this is a counter intuitive change.

You can still use the old hotplug multiplexer /sbin/hotplug and the
shell scripts and use udev only in as a device node manager, if you
like that more.

> > > udev 053 used to do this, 067 doesn't any more. I've got both the
> > > udev_run_devd and udev_run_hotplugd binaries compiled and in the right
> > > place; I stole the configuration from the gentoo rules. Any idea what's
> > > changed?
> >
> > No idea what's changed. Probably one of the hotplug agents is not
> > called, but we want to get rid of them anyway. :)
> 
> Well, I suppose this makes sense. What would really be nice is if udev didn't 
> abandon people running none of the six supported distributions, and instead 
> provided broken apart rules files (much like how debian does it), so that at 
> least the raw, basic functionality is always going to be installed.
> 
> Things like automatically loading sd_mod when a scsi disk is added, and 
> running the legacy devd/hotplugd helpers should really be done until there 
> are 100% suitable replacements for them. udev promised not only automation, 
> but an unparalleled minimum required configuration to work (I don't even have 
> a modules.conf, or have to explicitly load any modules. It's great.)

Well, what people are calling "great" varies so much, that I decided to
remove the broken "default" rules, cause too many people complained about
these rules and it's simply wrong to claim to have a default, when nobody
cares what's in the default.
I'm happy to put your working rules for your distro in the tree if you
send it, but there will be no "default" rules anymore as the distro
rules are well maintained and are the best examples what may be needed
to get udev integrated.

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

Re: udev-067 and 2.6.12?

[Alistair John Strachan]

On Wednesday 17 August 2005 13:35, Kay Sievers wrote:
> On Wed, Aug 17, 2005 at 09:26:08AM +0100, Alistair John Strachan wrote:
[snip]
> > No. I typed "make" and edited nothing. I'm sceptical that this is a
> > problem with "only" my configuration, since I've compiled literally
> > hundreds of packages with a problem, and run_directory/ is the only thing
> > I've ever seen not link bizarrely. I think the problem is that it's a
> > mistake to use ld explicitly to link in the case where I want to also
> > link in libc, and not use klibc. Many of the missing symbols were from
> > libc.
>
> You may need to run make from the top-level directory of of the udev
> tree with "make EXTRAS=extras/run_directory"?

[alistair] 15:34 [~/udev-067] make extras/run_directory
make: Nothing to be done for `extras/run_directory'.

[alistair] 15:34 [~/udev-067/extras/run_directory] make
cc -O2 -march=pentium-m -mfpmath=sse -s -pipe -c -o run_directory.o 
run_directory.c
ld -s -o udev_run_devd udev_run_devd.o 
run_directory.o ../../udev.a ../../libsysfs/sysfs.a
ld: warning: cannot find entry symbol _start; defaulting to 080480a0
udev_run_devd.o(.text+0x20): In function `main':
: undefined reference to `getenv'
udev_run_devd.o(.text+0x32): In function `main':
: undefined reference to `exit'
udev_run_devd.o(.text+0x45): In function `main':
: undefined reference to `strstr'
udev_run_devd.o(.text+0x68): In function `main':
[...]

[alistair] 15:35 [~/udev-067/extras/run_directory] CFLAGS="" make
cc  -c -o run_directory.o run_directory.c
ld -s -o udev_run_devd udev_run_devd.o 
run_directory.o ../../udev.a ../../libsysfs/sysfs.a
ld: warning: cannot find entry symbol _start; defaulting to 080480a0
udev_run_devd.o(.text+0x20): In function `main':
: undefined reference to `getenv'
udev_run_devd.o(.text+0x32): In function `main':
: undefined reference to `exit'
[...]

I'm convinced there's a problem here. This is actually running on my laptop, a 
completely different machine, but I get the exact same errors. I figured out 
the only way to make it work was..

[alistair] 15:39 [~/udev-067/extras/run_directory] CFLAGS="$CFLAGS -DUSE_LOG" 
LD="gcc" make
cc -O2 -march=pentium-m -mfpmath=sse -s -pipe -DUSE_LOG -c -o udev_run_devd.o 
udev_run_devd.c
cc -O2 -march=pentium-m -mfpmath=sse -s -pipe -DUSE_LOG -c -o run_directory.o 
run_directory.c
gcc -s -o udev_run_devd udev_run_devd.o 
run_directory.o ../../udev.a ../../libsysfs/sysfs.a
cc -O2 -march=pentium-m -mfpmath=sse -s -pipe -DUSE_LOG -c -o 
udev_run_hotplugd.o udev_run_hotplugd.c
gcc -s -o udev_run_hotplugd udev_run_hotplugd.o 
run_directory.o ../../udev.a ../../libsysfs/sysfs.a

And the resulting binaries worked fine..

> > > > Finally, I'm sure this is my fault, but modules like "mousedev" and
> > > > "sd_mod" don't get loaded by hotplug/udev when I plug in my mouse or
> > > > pendrive after booting. This is because they are not actually
> > > > dependencies of the modules usbhid and usb-storage, so they don't get
> > > > loaded by modprobe.
> > >
> > > For scsi see here:
> > >
> > > http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hh3a22a2bb
> > >7565
> > > 66b7e18a57231bae9913e61da2;hbV18b5611bccf64a1e22f8cbcebe8ecba9713c9c;
> > >f=etc /udev/suse/udev.rules#l158
> >
> > This seems like a step backwards from what 053 was doing. I can't see how
> > it's beneficial to not be intuitively loading useful modules without an
> > explicit rule.
>
> I don't see any problem here. If the kernel has no dependency to load
> the module, _you_ need to load it.
>
> > > And better compile mousedev in the kernel. That does not make a lot of
> > > sense as a module. If you really want a module, load it with an
> > > init-script.
> >
> > Agreed, I used to run with an allbuiltin kernel because back in the early
> > 2.5s, it was your only option. When I migrated to udev I switched to
> > modules before the udevstart program was mature, and was probably a bit
> > overzealous compiling out as much as possible.
> >
> > I still think this is a counter intuitive change.
>
> You can still use the old hotplug multiplexer /sbin/hotplug and the
> shell scripts and use udev only in as a device node manager, if you
> like that more.

Okay! So this is the primary reason why so much has changed with the newer 
udev; I didn't realise udev had taken on such a general role.

Retrospectively I think I was wrong about automatically loading mousedev and 
sd_mod, it's just from a user perspective it made a lot of sense, reduced the 
number of rules required, and broke in an incompatible way through a simple 
upgrade of udev.

If udev is taking on a newer and more encompassing role, I highly agree that 
it should have the configurability and flexibility to match.

>
> > > > udev 053 used to do this, 067 doesn't any more. I've got both the
> > > > udev_run_devd and udev_run_hotplugd binaries compiled and in the
> > > > right place; I stole the configuration from the gentoo rules. Any
> > > > idea what's changed?
> > >
> > > No idea what's changed. Probably one of the hotplug agents is not
> > > called, but we want to get rid of them anyway. :)
> >
> > Well, I suppose this makes sense. What would really be nice is if udev
> > didn't abandon people running none of the six supported distributions,
> > and instead provided broken apart rules files (much like how debian does
> > it), so that at least the raw, basic functionality is always going to be
> > installed.
> >
> > Things like automatically loading sd_mod when a scsi disk is added, and
> > running the legacy devd/hotplugd helpers should really be done until
> > there are 100% suitable replacements for them. udev promised not only
> > automation, but an unparalleled minimum required configuration to work (I
> > don't even have a modules.conf, or have to explicitly load any modules.
> > It's great.)
>
> Well, what people are calling "great" varies so much, that I decided to
> remove the broken "default" rules, cause too many people complained about
> these rules and it's simply wrong to claim to have a default, when nobody
> cares what's in the default.
> I'm happy to put your working rules for your distro in the tree if you
> send it, but there will be no "default" rules anymore as the distro
> rules are well maintained and are the best examples what may be needed
> to get udev integrated.
>

Though, as noted, many are still using the old style of writing, which should 
be corrected, and there are many parts of them that are identical and could 
be consolidated. Also, the sooner the udev_run_ helpers can be gotten rid of, 
the better. Currently it seems there's really no alternative to them if I 
want to upload my wireless card's firmware on startup, with or without 
renaming the interface.

I think having hotplug around purely so firmware_class doesn't fit about not 
being called correctly is wrong (and the interaction between udev and the 
firmware.class helper in hotplug isn't very clear.. I just get firmware 
failure messages to dmesg which magically disappear when I use the RUN+= 
hacks, it's non-trivial to debug).

Thanks for your information though, it's really appreciated. I can guarantee 
there will be people trawling google for similar information in the future. 
It's my opinion that I shouldn't have to know everything about a utility, or 
read every piece of documentation, to configure it in such a way that it will 
work on an unsupported distribution...

-- 
Cheers,
Alistair.

'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.


-------------------------------------------------------
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: udev-067 and 2.6.12?

[Kay Sievers]

On Wed, Aug 17, 2005 at 03:52:26PM +0100, Alistair John Strachan wrote:
> On Wednesday 17 August 2005 13:35, Kay Sievers wrote:
> > On Wed, Aug 17, 2005 at 09:26:08AM +0100, Alistair John Strachan wrote:
> [snip]
> > > No. I typed "make" and edited nothing. I'm sceptical that this is a
> > > problem with "only" my configuration, since I've compiled literally
> > > hundreds of packages with a problem, and run_directory/ is the only thing
> > > I've ever seen not link bizarrely. I think the problem is that it's a
> > > mistake to use ld explicitly to link in the case where I want to also
> > > link in libc, and not use klibc. Many of the missing symbols were from
> > > libc.
> >
> > You may need to run make from the top-level directory of of the udev
> > tree with "make EXTRAS=extras/run_directory"?
> 
> [alistair] 15:34 [~/udev-067] make extras/run_directory

Seems you didn't you try what I wrote in the last mail:
  make EXTRAS=extras/run_directory

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

Re: udev-067 and 2.6.12?

[Greg KH]

On Tue, Aug 16, 2005 at 04:31:48PM -0700, David Brown wrote:
> Okay you can disable syslog or I had to make an extra C file and patch
> the makefile to get it to work.
> 
> to disable syslog `make USE_LOGúlse`

I don't understand the need for this patch.  Care to provide more
details?

> == begin Makefile.patch => --- Makefile.old	2005-07-23 09:27:02.000000000 -0700
> +++ Makefile	2005-07-24 22:52:21.000000000 -0700
> @@ -145,7 +145,8 @@
>  	udev_db.o			\
>  	udev_rules.o			\
>  	udev_rules_parse.o		\
> -	udev_libc_wrapper.o
> +	udev_libc_wrapper.o             \
> +	udev_logger.o
>  
>  OBJS = \
>  	udev.a			\
> @@ -377,11 +378,6 @@
>  	$(INSTALL_PROGRAM) -D $(INFO) $(DESTDIR)$(usrbindir)/$(INFO)
>  	$(INSTALL_PROGRAM) -D $(TESTER) $(DESTDIR)$(usrbindir)/$(TESTER)
>  	$(INSTALL_PROGRAM) -D $(STARTER) $(DESTDIR)$(sbindir)/$(STARTER)
> -ifndef DESTDIR
> -	- killall $(DAEMON)
> -	- rm -rf $(udevdb)
> -	- $(sbindir)/$(DAEMON) --daemon
> -endif

Why did you comment this out?

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: udev-067 and 2.6.12?

[David Brown]

Well I'm a developer for SourceMage and one of the things that we
pride ourselves on is options.  So there's a couple of things we had
to change with udev to make it fit into our system of doing things.
1) no package to start or stop services in the process of installing
the package... hence the removal of the killall udevd && udevd
--daemon call
2) the `make -C extras/run_directory USE_LOG=true` didn't work if the
root directory of udev was built with logging support.

I had to add the udev_logger.c to the root directory add that file to
the Makefile so it would end up in udev.a, then the command I used to
build with syslog support is `make -C extras/run_directory
LDFLAGS="-lc" USE_LOG=true`.

So the main reason for using this patch and adding the udev_logger.c
source file is so that the extras/run_directory can have syslog
support or not have syslog support.

- David Brown

On 8/17/05, Greg KH <greg@kroah.com> wrote:
> On Tue, Aug 16, 2005 at 04:31:48PM -0700, David Brown wrote:
> > Okay you can disable syslog or I had to make an extra C file and patch
> > the makefile to get it to work.
> >
> > to disable syslog `make USE_LOGúlse`
> 
> I don't understand the need for this patch.  Care to provide more
> details?
> 
> > == begin Makefile.patch => > --- Makefile.old      2005-07-23 09:27:02.000000000 -0700
> > +++ Makefile  2005-07-24 22:52:21.000000000 -0700
> > @@ -145,7 +145,8 @@
> >       udev_db.o                       \
> >       udev_rules.o                    \
> >       udev_rules_parse.o              \
> > -     udev_libc_wrapper.o
> > +     udev_libc_wrapper.o             \
> > +     udev_logger.o
> >
> >  OBJS = \
> >       udev.a                  \
> > @@ -377,11 +378,6 @@
> >       $(INSTALL_PROGRAM) -D $(INFO) $(DESTDIR)$(usrbindir)/$(INFO)
> >       $(INSTALL_PROGRAM) -D $(TESTER) $(DESTDIR)$(usrbindir)/$(TESTER)
> >       $(INSTALL_PROGRAM) -D $(STARTER) $(DESTDIR)$(sbindir)/$(STARTER)
> > -ifndef DESTDIR
> > -     - killall $(DAEMON)
> > -     - rm -rf $(udevdb)
> > -     - $(sbindir)/$(DAEMON) --daemon
> > -endif
> 
> Why did you comment this out?
> 
> 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: udev-067 and 2.6.12?

[Greg KH]

A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?


On Thu, Aug 18, 2005 at 08:27:52AM -0700, David Brown wrote:
> Well I'm a developer for SourceMage and one of the things that we
> pride ourselves on is options.  So there's a couple of things we had
> to change with udev to make it fit into our system of doing things.
> 1) no package to start or stop services in the process of installing
> the package... hence the removal of the killall udevd && udevd
> --daemon call

So you install a new version of udev and don't kill the old udevd
program?  That's not good at all.  Remember, if you set DEST_DIR, that
doesn't get called.  That is there to allow you to build and not mess
with any running services (as is needed on rpm and deb build machines.)

> 2) the `make -C extras/run_directory USE_LOG=true` didn't work if the
> root directory of udev was built with logging support.

That's not how you build things in the extras directory (as per the
documentation.)

Did you try:
	make USE_LOG=true EXTRAS="extras/run_directory"
?  That should work just fine, and if not, please let us know.  There's
a script in the test directory that builds everything with all options
to determine if we break anything.  Have you tried that?

> I had to add the udev_logger.c to the root directory add that file to
> the Makefile so it would end up in udev.a, then the command I used to
> build with syslog support is `make -C extras/run_directory
> LDFLAGS="-lc" USE_LOG=true`.
> 
> So the main reason for using this patch and adding the udev_logger.c
> source file is so that the extras/run_directory can have syslog
> support or not have syslog support.

Ok, and as I don't think you are building things correctly, I don't
think this patch is needed :)

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: udev-067 and 2.6.12?

[David Brown]

On 8/18/05, Greg KH <greg@kroah.com> wrote:
> 
> A: http://en.wikipedia.org/wiki/Top_post
> Q: Were do I find info about this thing called top-posting?
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
> 
> A: No.
> Q: Should I include quotations after my reply?

Sorry I'll try not to do that any more ;-)

> So you install a new version of udev and don't kill the old udevd
> program?  That's not good at all.  Remember, if you set DEST_DIR, that
> doesn't get called.  That is there to allow you to build and not mess
> with any running services (as is needed on rpm and deb build machines.)

I'll mention this to the other developers and see what they think... I
inherited this diff from previous versions of the package (going back
to 04x iirc) it may need another look if it's needed.
 
> That's not how you build things in the extras directory (as per the
> documentation.)
> 
> Did you try:
>         make USE_LOG=true EXTRAS="extras/run_directory"
> ?  That should work just fine, and if not, please let us know.  There's
> a script in the test directory that builds everything with all options
> to determine if we break anything.  Have you tried that?

Ah, yes thanks that does work.  I must have misread the RELEASE-NOTES... :-\
Maybe adding back-ticks could make that line seem more like 'this is
the exact command to execute.'  (just a suggestion)
I'll be sure to fix this thanks...

> Ok, and as I don't think you are building things correctly, I don't
> think this patch is needed :)

Yes agreed thanks for the help :)

Thanks
- David Brown


-------------------------------------------------------
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: udev-067 and 2.6.12?

[Alistair John Strachan]

On Thursday 18 August 2005 16:38, Greg KH wrote:
[snip truths :-)]
>
> On Thu, Aug 18, 2005 at 08:27:52AM -0700, David Brown wrote:
> > Well I'm a developer for SourceMage and one of the things that we
> > pride ourselves on is options.  So there's a couple of things we had
> > to change with udev to make it fit into our system of doing things.
> > 1) no package to start or stop services in the process of installing
> > the package... hence the removal of the killall udevd && udevd
> > --daemon call
>
> So you install a new version of udev and don't kill the old udevd
> program?  That's not good at all.  Remember, if you set DEST_DIR, that
> doesn't get called.  That is there to allow you to build and not mess
> with any running services (as is needed on rpm and deb build machines.)
>
> > 2) the `make -C extras/run_directory USE_LOG=true` didn't work if the
> > root directory of udev was built with logging support.
>
> That's not how you build things in the extras directory (as per the
> documentation.)

autotools.

>
> Did you try:
> 	make USE_LOG=true EXTRAS="extras/run_directory"
> ?  That should work just fine, and if not, please let us know.  There's
> a script in the test directory that builds everything with all options
> to determine if we break anything.  Have you tried that?
>
> > I had to add the udev_logger.c to the root directory add that file to
> > the Makefile so it would end up in udev.a, then the command I used to
> > build with syslog support is `make -C extras/run_directory
> > LDFLAGS="-lc" USE_LOG=true`.
> >
> > So the main reason for using this patch and adding the udev_logger.c
> > source file is so that the extras/run_directory can have syslog
> > support or not have syslog support.
>
> Ok, and as I don't think you are building things correctly, I don't
> think this patch is needed :)

autotools. --enable-run-helpers

>
> thanks,
>
> greg k-h

a) Assume that not all users are distributors, and have not done things like 
install udev 067 multiple times;

b) Assume that users will not read documentation (I profusely apologise for 
not doing this);

c) Assume users even after complaining won't read replies properly, and still 
think there's a problem. This is the result of lack of sleep etc.;

d) Autotools are standard, better than make KITCHEN_SINK=magical/keyword.

If this is deemed acceptable I can help autotool udev.

-- 
Cheers,
Alistair.

'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.


-------------------------------------------------------
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: udev-067 and 2.6.12?

[Greg KH]

On Thu, Aug 18, 2005 at 05:32:18PM +0100, Alistair John Strachan wrote:
> On Thursday 18 August 2005 16:38, Greg KH wrote:
> [snip truths :-)]
> >
> > On Thu, Aug 18, 2005 at 08:27:52AM -0700, David Brown wrote:
> > > Well I'm a developer for SourceMage and one of the things that we
> > > pride ourselves on is options.  So there's a couple of things we had
> > > to change with udev to make it fit into our system of doing things.
> > > 1) no package to start or stop services in the process of installing
> > > the package... hence the removal of the killall udevd && udevd
> > > --daemon call
> >
> > So you install a new version of udev and don't kill the old udevd
> > program?  That's not good at all.  Remember, if you set DEST_DIR, that
> > doesn't get called.  That is there to allow you to build and not mess
> > with any running services (as is needed on rpm and deb build machines.)
> >
> > > 2) the `make -C extras/run_directory USE_LOG=true` didn't work if the
> > > root directory of udev was built with logging support.
> >
> > That's not how you build things in the extras directory (as per the
> > documentation.)
> 
> autotools.

No, autotools are not an answer to this, they are only the start of a
bigger problem :)

> a) Assume that not all users are distributors, and have not done things like 
> install udev 067 multiple times;

udev users are not encouraged to build and install udev unless they
_really_ know what they are doing (how many users install their own
/sbin/init?)  It requires a lot of distro specific startup logic to get
correct due to what it is doing.

> d) Autotools are standard, better than make KITCHEN_SINK=magical/keyword.
> 
> If this is deemed acceptable I can help autotool udev.

Many people have tried in the past.  It's not needed at all, and only
will make things worse.  So please don't even try.

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: udev-067 and 2.6.12?

[Alistair John Strachan]

Hi Greg,

On Thursday 18 August 2005 17:56, Greg KH wrote:
[snip]
>
> > a) Assume that not all users are distributors, and have not done things
> > like install udev 067 multiple times;
>
> udev users are not encouraged to build and install udev unless they
> _really_ know what they are doing (how many users install their own
> /sbin/init?)  It requires a lot of distro specific startup logic to get
> correct due to what it is doing.

I think certain features could be documented better, but it's been explained 
that udev is transitioning into a replacement for hotplug anyway, so maybe 
now isn't the best time to speculate about how to make deployment easier.

In my case, the interests were for embedding Linux on custom hardware, 
unfortunately distros don't cut it. But I can accept that all of my issues 
can be explained away by teething issues and not reading the documentation.

>
> > d) Autotools are standard, better than make KITCHEN_SINK=magical/keyword.
> >
> > If this is deemed acceptable I can help autotool udev.
>
> Many people have tried in the past.  It's not needed at all, and only
> will make things worse.  So please don't even try.

I'm confident you know what will work and won't work.

Also, David, Greg's 100% right. Your patch is not required. Simply build the 
run_directory as him, Kay, the docs, and the black marker on my forehead have 
said.

It works. On everything.

We've both just not read the documentation thoroughly enough.

-- 
Cheers,
Alistair.

'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.


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