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