* Re: [PATCH] configure: allow usb.ids location to be specified
From: Scott James Remnant @ 2011-05-23 19:37 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1305926367-3093-1-git-send-email-scott@netsplit.com>
Pushed with the C&P fix.
On Mon, May 23, 2011 at 1:48 AM, Kay Sievers <kay.sievers@vrfy.org> wrote:
>
> On Fri, May 20, 2011 at 23:19, Scott James Remnant <scott@netsplit.com> wrote:
> > We already allow the pci.ids location to be specified, so add a
> > patch doing the same for usb.ids. Please don't make me explain
> > why this is necessary, it will only make you cry.
>
> I'll not ask. :) Sure, go ahead.
>
> Kay
^ permalink raw reply
* Re: [PATCH] configure: allow usb.ids location to be specified
From: Kay Sievers @ 2011-05-23 21:13 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1305926367-3093-1-git-send-email-scott@netsplit.com>
On Mon, May 23, 2011 at 21:37, Scott James Remnant <scott@netsplit.com> wrote:
> Pushed with the C&P fix ;-)
Btw, why doesn't your system find out where it is installed by asking
pkgconfig? That's why nobody else needs it, unlike they do for pci.
Kay
^ permalink raw reply
* Re: [PATCH] configure: allow usb.ids location to be specified
From: Scott James Remnant @ 2011-05-23 21:43 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1305926367-3093-1-git-send-email-scott@netsplit.com>
Because it's a cross-compiled Gentoo.
So pkg-config reports the location inside the cross-compiled $ROOT,
rather than the runtime location. The designers of pkg-config forgot
about host vs. build vs. target *sigh*
On Mon, May 23, 2011 at 2:13 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
>
> On Mon, May 23, 2011 at 21:37, Scott James Remnant <scott@netsplit.com> wrote:
> > Pushed with the C&P fix ;-)
>
> Btw, why doesn't your system find out where it is installed by asking
> pkgconfig? That's why nobody else needs it, unlike they do for pci.
>
> Kay
^ permalink raw reply
* Re: future of sysctls?
From: Karel Zak @ 2011-05-23 21:49 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201105121741.27459.ludwig.nussel@suse.de>
On Wed, May 18, 2011 at 07:32:30PM +0200, Lennart Poettering wrote:
> On Wed, 18.05.11 09:03, Ludwig Nussel (ludwig.nussel@suse.de) wrote:
>
> > > > > Might be a good idea to just ignore these kinds of settings. Or if this
> > > > > is not possible, then set them from NM or whatever controls the network.
> > > >
> > > > That's that hack that's currently in place. Network scripts grep
> > > > /etc/sysctl.conf for interface specific settings...
> > >
> > > Urks. What we could do to make this nicer is add a simple prefix match
> > > logic to our sysctl apply tool, so that it is easy to apply a subtree of
> > > sysctls when the time comes.
> >
> > I've sent a patch to the procps maintainer but he has yet to
> > respond. It's not a real solution anyways. It just makes a dirty
> > hack a little more efficient.
>
> Note that systemd does not use the procps' implementation of sysctl, but
> our own one since the upstream version does not support /etc/sysctl.d/
> or anything like this.
procps project has been forked, ML:
http://www.freelists.org/list/procps
The upstream is active and maintained by people from Fedora, Suse
and Debian. So, it would be better to contribute to this project
than maintain and distribute systemd specific stuff... :-)
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* [PATCH] rules: set the correct group of the static snd/{seq,timer} nodes
From: Tom Gundersen @ 2011-05-24 13:33 UTC (permalink / raw)
To: linux-hotplug
From 01b159b3f67d5e387ebab879e52ae2d1b6be32bf Mon Sep 17 00:00:00 2001
From: Tom Gundersen <teg@jklm.no>
Date: Tue, 24 May 2011 15:04:56 +0200
Subject: [PATCH] rules: set the correct group of the static
snd/{seq,timer} nodes
When removing some of our custom rules from Arch we found that
a user in the audio group could no longer autoload the snd_seq
module. This fixes it, as proposed by Kay.
An analogous fix is applied to snd/timer.
Signed-off-by: Tom Gundersen <teg@jklm.no>
---
rules/rules.d/50-udev-default.rules | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/rules/rules.d/50-udev-default.rules
b/rules/rules.d/50-udev-default.rules
index cd745ef..f7f134b 100644
--- a/rules/rules.d/50-udev-default.rules
+++ b/rules/rules.d/50-udev-default.rules
@@ -39,6 +39,10 @@ SUBSYSTEM="drm", GROUP="video"
# sound
SUBSYSTEM="sound", GROUP="audio"
+KERNEL="seq", GROUP="audio", MODE="0660", \
+ OPTIONS+="static_node=snd/seq"
+KERNEL="timer", GROUP="audio", MODE="0660", \
+ OPTIONS+="static_node=snd/timer"
# DVB (video)
SUBSYSTEM="dvb", GROUP="video"
--
1.7.5.2
^ permalink raw reply related
* Bug#627931: /etc/udev/rules.d/70-persistent-net.rules not generated
From: Marco d'Itri @ 2011-05-25 18:01 UTC (permalink / raw)
To: linux-hotplug
Does anybody have an opinion about this?
----- Forwarded message from Christian Hammers <chammers@netcologne.de> -----
From: Christian Hammers <chammers@netcologne.de>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: Bug#627931: /etc/udev/rules.d/70-persistent-net.rules not generated on
VMware
Package: udev
Version: 164-3
Severity: normal
On VMware the creation of /etc/udev/rules.d/70-persistent-net.rules is
inhibited by the following block in
/lib/udev/rules.d/75-persistent-net-generator.rules:
# ignore interfaces with locally administered or null MAC addresses
# and KVM and VMWare virtual interfaces
ENV{MATCHADDR}="?[2367abef]:*", ENV{MATCHADDR}=""
ENV{MATCHADDR}="00:00:00:00:00:00", ENV{MATCHADDR}=""
ENV{MATCHADDR}="00:0c:29:*|00:50:56:*", ENV{MATCHADDR}=""
ENV{MATCHADDR}="52:54:00:*|54:52:00:*", ENV{MATCHADDR}=""
Please remove the exception for VMware as it's possible to
choose different network drivers (vmxnet3/e1000) for virtual
machines and this have the same problem as normal PCs that
the system does not boot correctly after a new kernel is
installed.
bye,
-christian-
-- System Information:
Debian Release: 6.0.1
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANGÞ_DE.UTF-8, LC_CTYPEÞ_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages udev depends on:
ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy
ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib
ii libselinux1 2.0.96-1 SELinux runtime shared libraries
ii libudev0 164-3 libudev shared library
ii libusb-0.1-4 2:0.1.12-16 userspace USB programming library
ii lsb-base 3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip
ii util-linux 2.17.2-9 Miscellaneous system utilities
Versions of packages udev recommends:
ii pciutils 1:3.1.7-6 Linux PCI Utilities
ii usbutils 0.87-5 Linux USB utilities
udev suggests no packages.
-- debconf information:
udev/new_kernel_needed: false
udev/sysfs_deprecated_incompatibility:
udev/title/upgrade:
udev/reboot_needed:
----- End forwarded message -----
--
ciao,
Marco
^ permalink raw reply
* Re: Bug#627931: /etc/udev/rules.d/70-persistent-net.rules not
From: Kay Sievers @ 2011-05-25 18:42 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20110525180115.GA15695@bongo.bofh.it>
On Wed, May 25, 2011 at 20:01, Marco d'Itri <md@linux.it> wrote:
> Does anybody have an opinion about this?
Let people who rely on persistent names edit the rules file by hand.
By manually/from-system-management -tools editing the rules file in
/etc.
The /etc/udev/rules.d/70-persistent-net.rules will stay for people to
configure their names, but they should *not* use ethX. The temporary
rename loop to swap names will likely be removed from udev.
We are going to drop the entire "magically create a rules file /etc to
keep names stable"-logic later this year, I expect.
We can not rename network devices in the kernel namespace (ethX)
reliably. It's impossible to get right to rename in a conflicting
namespace while kernel modules are loaded.
The whole thing does not scale with a lot of interfaces or on boxes
with many changes. The rules file just gets full of garbage over time.
We have problems with read-only rootfs and stateless boots.
The few people who rely on stable interface names, need to *configure*
them anyway for other reasons, assign IP addressen and such. Udev
should not try to be smart in the background and write state to disk
on its own.
In the future, udev will not do anything for any unconfigured
interface, not rename it, not write out a rule for the next reboot.
The majority of systems does not need these stable names, and the
current *magic* creates far too many problems. The deal does not seem
right and the fix it not to do it.
Kay
^ permalink raw reply
* Re: Bug#627931: /etc/udev/rules.d/70-persistent-net.rules not
From: Greg KH @ 2011-05-26 7:12 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20110525180115.GA15695@bongo.bofh.it>
On Wed, May 25, 2011 at 08:42:47PM +0200, Kay Sievers wrote:
> In the future, udev will not do anything for any unconfigured
> interface, not rename it, not write out a rule for the next reboot.
> The majority of systems does not need these stable names, and the
> current *magic* creates far too many problems. The deal does not seem
> right and the fix it not to do it.
Yeah!
That sounds like the correct solution to me as well, thanks for planning
on doing this.
greg k-h
^ permalink raw reply
* Re: Bug#627931: /etc/udev/rules.d/70-persistent-net.rules not
From: Kay Sievers @ 2011-05-26 11:59 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20110525180115.GA15695@bongo.bofh.it>
On Thu, May 26, 2011 at 09:12, Greg KH <greg@kroah.com> wrote:
> On Wed, May 25, 2011 at 08:42:47PM +0200, Kay Sievers wrote:
>> In the future, udev will not do anything for any unconfigured
>> interface, not rename it, not write out a rule for the next reboot.
>> The majority of systems does not need these stable names, and the
>> current *magic* creates far too many problems. The deal does not seem
>> right and the fix it not to do it.
>
> Yeah!
>
> That sounds like the correct solution to me as well, thanks for planning
> on doing this.
People who don't rely on it can already do:
./configure --disable-rule_generator
Which will not install any of the files that mangle udev rules ad
hotplug time. The big distros just need to coordinate with the people
who do the system-management tools, that these tools get updated to
allow editing the 70-persistent-net.rules file without udev ever
touching it.
They should also make sure, that network devices are never renamed in
the ethX namespace.
The current biosdevname solution with the lomX and slotX names which
Dell uses, seems to work well, and shows that we should not fear
moving to the proper solution.
It is either leaving the names completely up to the kernel and run
something like NetworkManager which does not care at all what names
the devices have, or the system has manually configured interfaces and
they get meaningful names like 'lom' (for on motherboard) or the PCI
slot number, or something like 'internal', 'external', 'dmz'.
The lom, slot logic, which is pretty simple, we might even want to
move inside the kernel after a while, when things have proven to work
reliably that way.
Only one thing seems sure for now, that udev must stop renaming things
in the kernel namespace. The details for the rest we will need to find
out. :)
Kay
^ permalink raw reply
* Re: Bug#627931: /etc/udev/rules.d/70-persistent-net.rules not
From: Marco d'Itri @ 2011-05-26 13:16 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20110525180115.GA15695@bongo.bofh.it>
On May 25, Kay Sievers <kay.sievers@vrfy.org> wrote:
> We can not rename network devices in the kernel namespace (ethX)
> reliably. It's impossible to get right to rename in a conflicting
> namespace while kernel modules are loaded.
Can you tell me more about this? Because it worked well enough for the
last last 5 years.
> The whole thing does not scale with a lot of interfaces or on boxes
> with many changes. The rules file just gets full of garbage over time.
True, but these are corner cases.
> Only one thing seems sure for now, that udev must stop renaming things
> in the kernel namespace. The details for the rest we will need to find
> out. :)
Maybe you can get away with removing features, but I need to support the
ones used by my users so I am strongly opposed to removing this code
until other software will support all current use cases.
As you showed, distributions which do not feel like supporting it can
just disable it.
--
ciao,
Marco
^ permalink raw reply
* Re: Bug#627931: /etc/udev/rules.d/70-persistent-net.rules not
From: Kay Sievers @ 2011-05-26 14:44 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20110525180115.GA15695@bongo.bofh.it>
On Thu, May 26, 2011 at 15:16, Marco d'Itri <md@linux.it> wrote:
> On May 25, Kay Sievers <kay.sievers@vrfy.org> wrote:
>
>> We can not rename network devices in the kernel namespace (ethX)
>> reliably. It's impossible to get right to rename in a conflicting
>> namespace while kernel modules are loaded.
> Can you tell me more about this? Because it worked well enough for the
> last last 5 years.
It does not fit my idea of "well enough", quite the opposite. The most
important, it does not really solve a problem, but creates a lot of
new ones.
The whole idea of *automatic rules* and *persistence in the file
system* is wrong. Stuff that requires static names requires *manual*
configuration anyway, stuff that does not require static names, does
not need the crappy automagic we do.
You race against the kernel creating new interfaces, while we are in
progress renaming devices. A game we can never win. We actually have
real bugs for that, and can't solve them properly ever. Renaming stuff
in the same namespace without global locks is never going to work,
hence we need to stop pretending we can.
It does not scale. If you have thousands of interfaces, the file will
just be a total mess. People with boxes to 'test' stuff get thousands
of dead rule lines, one for every new device that gets plugged in.
It's just wrong to do that.
A said earlier, it was a mistake to ever try to do *automatic* rule
creation. We are absolutely sure not, that it was a mistake and we
will fix it by not continuing to do that.
>> The whole thing does not scale with a lot of interfaces or on boxes
>> with many changes. The rules file just gets full of garbage over time.
> True, but these are corner cases.
It's not. It's a real bug. That you and I have only one disk in our
box, is no reason for udev not to require to work with 40.000 disks
out-of-the-box. We must stop pretending and solving problems which are
actually no problems.
>> Only one thing seems sure for now, that udev must stop renaming things
>> in the kernel namespace. The details for the rest we will need to find
>> out. :)
> Maybe you can get away with removing features, but I need to support the
> ones used by my users so I am strongly opposed to removing this code
> until other software will support all current use cases.
> As you showed, distributions which do not feel like supporting it can
> just disable it.
When we get there, it will no longer be part of udev, deleted from the
sources. It was a mistake to make a promise we can't deliver. There
will be still infrastructure, the mechanics to rename and manage
interfaces, but there will be no policy to execute it by default, no
rules creator running at hotplug time.
People who want *auto* rules creation can add the files themselves,
they will not be provided by udev.
Kay
^ permalink raw reply
* [ANNOUNCE] udev 171
From: Kay Sievers @ 2011-05-27 0:08 UTC (permalink / raw)
To: linux-hotplug
Here comes a new udev version. Thanks to all who have contributed to
this release.
The tarball can be found here:
ftp://ftp.kernel.org/pub/linux/utils/kernel/hotplug/
The development repository can be found here:
http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=summary
The ChangeLog can be found here:
http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hb=HEAD;f=ChangeLog
udev 171
====
Bugfixes.
The systemd service files require systemd version 28. The systemd
socket activation make it possible now to start 'udevd' and 'udevadm
trigger' in parallel.
The systemd udev.socket files has been split and renamed. If they
are called from package install scripts, the names need to be
adapted.
udev 170
====
Fix bug in control message handling, which can lead to a failing
udevadm control --exit. Thanks to Jürg Billeter for help tracking
it down.
udev 169
====
Bugfixes.
We require at least Linux kernel 2.6.32 now. Some platforms might
require a later kernel that supports accept4() and similar, or
need to backport the trivial syscall wiring to the older kernels.
The hid2hci tool moved to the bluez package and was removed.
Many of the extras can be --enable/--disabled at ./configure
time. The --disable-extras option was removed. Some extras have
been disabled by default. The current options and their defaults
can be checked with './configure --help'.
udev 168
====
Bugfixes.
Udev logs a warning now if /run is not writable at udevd
startup. It will still fall back to /dev/.udev, but this is
now considered a bug.
The running udev daemon can now cleanly shut down with:
udevadm control --exit
Udev in initramfs should clean the state of the udev database
with: udevadm info --cleanup-db which will remove all state left
behind from events/rules in initramfs. If initramfs uses
--cleanup-db and device-mapper/LVM, the rules in initramfs need
to add OPTIONS+="db_persist" for all dm devices. This will
prevent removal of the udev database for these devices.
Spawned programs by PROGRAM/IMPORT/RUN now have a hard
timeout of 120 seconds per process. If that timeout is reached the
spawned process will be killed. The event timeout can be overwritten
with udev rules.
If systemd is used, udev gets now activated by netlink data.
Systemd will bind the netlink socket which will buffer all data.
If needed, such setup allows a seemless update of the udev daemon,
where no event can be lost during a udevd update/restart.
Packages need to make sure to: systemctl stop udev.socket
udev.service or 'mask' udev.service during the upgrade to prevent
any unwanted auto-spawning of udevd.
This version of udev conflicts with systemd version below 25. The
unchanged service files will not work correctly.
^ permalink raw reply
* Re: [PATCH] rules: set the correct group of the static
From: Kay Sievers @ 2011-05-27 0:52 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <BANLkTi=GMO3+6dPk654AUeg49nQezj-u=w@mail.gmail.com>
On Tue, May 24, 2011 at 15:33, Tom Gundersen <teg@jklm.no> wrote:
> When removing some of our custom rules from Arch we found that
> a user in the audio group could no longer autoload the snd_seq
> module. This fixes it, as proposed by Kay.
Found out that we can use something simpler. Should work now.
Thanks for the reminder,
Kay
^ permalink raw reply
* Re: Bug#627931: /etc/udev/rules.d/70-persistent-net.rules not
From: Marco d'Itri @ 2011-05-27 1:26 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20110525180115.GA15695@bongo.bofh.it>
On May 26, Kay Sievers <kay.sievers@vrfy.org> wrote:
> It does not fit my idea of "well enough", quite the opposite. The most
> important, it does not really solve a problem, but creates a lot of
> new ones.
My experience is clearly different, so looks like our respective user
bases have different needs. It almost always solves the problem of
interface names not changing after a reboot and breaking everything.
> You race against the kernel creating new interfaces, while we are in
> progress renaming devices. A game we can never win. We actually have
> real bugs for that, and can't solve them properly ever. Renaming stuff
> in the same namespace without global locks is never going to work,
> hence we need to stop pretending we can.
Again, it has worked well enough for my users for the last 5 years so it
cannot be so much broken.
> A said earlier, it was a mistake to ever try to do *automatic* rule
> creation. We are absolutely sure not, that it was a mistake and we
> will fix it by not continuing to do that.
While it may not cover all cases it still beats all the existing
alternatives. I will be ready to reconsider my position when new
software will appear to handle the currently supported cases.
> When we get there, it will no longer be part of udev, deleted from the
> sources. It was a mistake to make a promise we can't deliver. There
> will be still infrastructure, the mechanics to rename and manage
> interfaces, but there will be no policy to execute it by default, no
> rules creator running at hotplug time.
I can continue maintaining the scripts in my tree as long as it will be
needed, but removing support for renaming interfaces in the same
namespace (which, again, works fine for all my users) will be seriously
inconvenient.
--
ciao,
Marco
^ permalink raw reply
* Re: Bug#627931: /etc/udev/rules.d/70-persistent-net.rules not
From: Kay Sievers @ 2011-05-27 1:52 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20110525180115.GA15695@bongo.bofh.it>
On Fri, May 27, 2011 at 03:26, Marco d'Itri <md@linux.it> wrote:
> On May 26, Kay Sievers <kay.sievers@vrfy.org> wrote:
>
>> It does not fit my idea of "well enough", quite the opposite. The most
>> important, it does not really solve a problem, but creates a lot of
>> new ones.
> My experience is clearly different, so looks like our respective user
> bases have different needs. It almost always solves the problem of
> interface names not changing after a reboot and breaking everything.
Sure, it works on more boxes than it fails. But the thing is that it
is just not needed for the majority of boxes. So the few ones where
the auto-setup is helpful don't justify all the problems this solution
brings.
We have to admit we had an idea, we tried to solve it, and it does not
work out, or is not needed. So we decided to stop doing it. It's just
not worth the trouble.
>> You race against the kernel creating new interfaces, while we are in
>> progress renaming devices. A game we can never win. We actually have
>> real bugs for that, and can't solve them properly ever. Renaming stuff
>> in the same namespace without global locks is never going to work,
>> hence we need to stop pretending we can.
> Again, it has worked well enough for my users for the last 5 years so it
> cannot be so much broken.
Nope, it doesn't work. We run all the renaming during bootup while we
still load kernel modules. The interface creation from inside the
kernel races against our renaming/name swapping. Names we just freed
to take them with a rename get re-used for newly created interfaces in
the kernel. These are real bugs with bug reports. We can never fix
that properly. It's a game we can only lose.
>> A said earlier, it was a mistake to ever try to do *automatic* rule
>> creation. We are absolutely sure not, that it was a mistake and we
>> will fix it by not continuing to do that.
> While it may not cover all cases it still beats all the existing
> alternatives. I will be ready to reconsider my position when new
> software will appear to handle the currently supported cases.
The only sensible option is to provide system-management tools to
specify stable custom names for interfaces based on whatever match
that fits. We should stop trying to solve problems which don't really
exist. Today's stuff handles other names than ethX just fine, and the
majority of boxes handles changing names at reboot just fine.
>> When we get there, it will no longer be part of udev, deleted from the
>> sources. It was a mistake to make a promise we can't deliver. There
>> will be still infrastructure, the mechanics to rename and manage
>> interfaces, but there will be no policy to execute it by default, no
>> rules creator running at hotplug time.
> I can continue maintaining the scripts in my tree as long as it will be
> needed, but removing support for renaming interfaces in the same
> namespace (which, again, works fine for all my users) will be seriously
> inconvenient.
Sure, that's up to the distro, what to do. It's just that upstream
will not continue to provide things that can't be fixed properly.
Just look at the VMware example: We excluded it because the auto-rules
crated trouble for VMware images, now people think they want it. It
just does not make sense to try to be smart here. We can't solve these
issues automatically. It sounds good, but it's bad in reality.
People who need persistent names, need it for a reason, they have a
custom matching network config. So they need to setup the interface
config they match against too. Udev will get out of their way, and
only do what it it told to do instead of trying to fix non-existing
problem, and create a ton of new ones that way.
Kay
^ permalink raw reply
* Re: [ANNOUNCE] udev 171
From: Gabor Z. Papp @ 2011-05-27 6:47 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <BANLkTi=QsO7aw3GKDwOjk2nC-NWeM4QmLQ@mail.gmail.com>
* Kay Sievers <kay.sievers@vrfy.org>:
| udev 171
| ====
| Bugfixes.
[...]
| udev 169
| ====
| Bugfixes.
| We require at least Linux kernel 2.6.32 now.
CC extras/input_id/input_id.o
extras/input_id/input_id.c: In function 'test_key':
extras/input_id/input_id.c:167: error: 'BTN_TRIGGER_HAPPY' undeclared (first use in this function)
extras/input_id/input_id.c:167: error: (Each undeclared identifier is reported only once
extras/input_id/input_id.c:167: error: for each function it appears in.)
make[2]: *** [extras/input_id/input_id.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
$ uname -a
Linux gzp 2.6.32.41 #1 SMP PREEMPT Tue May 24 09:17:23 CEST 2011 i686 GNU/Linux
^ permalink raw reply
* Re: [ANNOUNCE] udev 171
From: Paul Bender @ 2011-05-27 10:09 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <BANLkTi=QsO7aw3GKDwOjk2nC-NWeM4QmLQ@mail.gmail.com>
On 5/26/2011 11:47 PM, Gabor Z. Papp wrote:
> * Kay Sievers<kay.sievers@vrfy.org>:
>
> | udev 171
> | ====
> | Bugfixes.
>
> [...]
>
> | udev 169
> | ====
> | Bugfixes.
>
> | We require at least Linux kernel 2.6.32 now.
>
> CC extras/input_id/input_id.o
> extras/input_id/input_id.c: In function 'test_key':
> extras/input_id/input_id.c:167: error: 'BTN_TRIGGER_HAPPY' undeclared (first use in this function)
> extras/input_id/input_id.c:167: error: (Each undeclared identifier is reported only once
> extras/input_id/input_id.c:167: error: for each function it appears in.)
> make[2]: *** [extras/input_id/input_id.o] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
>
> $ uname -a
> Linux gzp 2.6.32.41 #1 SMP PREEMPT Tue May 24 09:17:23 CEST 2011 i686 GNU/Linux
I believe that BTN_TRIGGER_HAPPY was added to linux/input.h in the
2.6.34 kernel.
Given that the udev function in question is attempting to differentiate
between KEY_* and BTN_* events and given that KEY_* and BTN_* events are
intermixed numerically, I cannot think of a reliable solution (even the
current implementation is not reliable).
When I wrote eventlircd, my solution to this problem (I wanted to
separate keyboard events from mice and joystick events) was to write an
awk script that created a look up array for KEY_* versus BTN_* by
parsing linux/input.h. I used the autoconf archives macro
AX_ABSOLUTE_HEADER to locate linux/input.h at build time in the
configure phase. While not ideal, it was the best hack I could come up with.
^ permalink raw reply
* Re: [PATCH] rules: set the correct group of the static
From: Tom Gundersen @ 2011-05-29 23:35 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <BANLkTi=GMO3+6dPk654AUeg49nQezj-u=w@mail.gmail.com>
[forgot to cc]
On Fri, May 27, 2011 at 2:52 AM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Tue, May 24, 2011 at 15:33, Tom Gundersen <teg@jklm.no> wrote:
>> When removing some of our custom rules from Arch we found that
>> a user in the audio group could no longer autoload the snd_seq
>> module. This fixes it, as proposed by Kay.
>
> Found out that we can use something simpler. Should work now.
Close, but no cigar. Looks like the static nodes are not assigned
permissions 0660 even if a gid is set (the nodes have perms 0600).
Cheers,
Tom
^ permalink raw reply
* Re: [PATCH] rules: set the correct group of the static
From: Kay Sievers @ 2011-05-30 0:27 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <BANLkTi=GMO3+6dPk654AUeg49nQezj-u=w@mail.gmail.com>
On Mon, May 30, 2011 at 01:35, Tom Gundersen <teg@jklm.no> wrote:
> On Fri, May 27, 2011 at 2:52 AM, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> On Tue, May 24, 2011 at 15:33, Tom Gundersen <teg@jklm.no> wrote:
>>> When removing some of our custom rules from Arch we found that
>>> a user in the audio group could no longer autoload the snd_seq
>>> module. This fixes it, as proposed by Kay.
>>
>> Found out that we can use something simpler. Should work now.
>
> Close, but no cigar. Looks like the static nodes are not assigned
> permissions 0660 even if a gid is set (the nodes have perms 0600).
rules: static_node - use 0660 if group is given to get the cigar
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h¡12873b5bc9ebbae39c32f502bc6211f33546cc
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] rules: set the correct group of the static
From: Tom Gundersen @ 2011-05-30 12:02 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <BANLkTi=GMO3+6dPk654AUeg49nQezj-u=w@mail.gmail.com>
On Mon, May 30, 2011 at 2:27 AM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Mon, May 30, 2011 at 01:35, Tom Gundersen <teg@jklm.no> wrote:
>> On Fri, May 27, 2011 at 2:52 AM, Kay Sievers <kay.sievers@vrfy.org> wrote:
>>> On Tue, May 24, 2011 at 15:33, Tom Gundersen <teg@jklm.no> wrote:
>>>> When removing some of our custom rules from Arch we found that
>>>> a user in the audio group could no longer autoload the snd_seq
>>>> module. This fixes it, as proposed by Kay.
>>>
>>> Found out that we can use something simpler. Should work now.
>>
>> Close, but no cigar. Looks like the static nodes are not assigned
>> permissions 0660 even if a gid is set (the nodes have perms 0600).
>
> rules: static_node - use 0660 if group is given to get the cigar
> http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h¡12873b5bc9ebbae39c32f502bc6211f33546cc
Thanks!
-t
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* udev queue error
From: Markus Rathgeb @ 2011-05-30 19:46 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 2186 bytes --]
Hello!
If I insert a special USB stick to my computer, udev will go crazy.
The USB stick is a "SanDisk Cruzer" device. It represents himself as a
block device and a CD rom device.
I do not know, how I could help. So pleace have a look at the logs:
/proc/kmsg if I insert the stick:
<7>[99224.649752] hub 4-1:1.0: state 7 ports 4 chg 0000 evt 0008
<7>[99224.651372] hub 4-1:1.0: port 3, status 0101, change 0001, 12 Mb/s
<7>[99224.758955] hub 4-1:1.0: debounce: port 3: total 100ms stable
100ms status 0x101
<6>[99224.824960] usb 4-1.3: new high speed USB device number 18 using ehci_hcd
<7>[99224.903944] usb 4-1.3: default language 0x0409
<7>[99224.904691] usb 4-1.3: udev 18, busnum 4, minor = 401
<6>[99224.904699] usb 4-1.3: New USB device found, idVendor=0781, idProduct=5406
<6>[99224.904704] usb 4-1.3: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
<6>[99224.904709] usb 4-1.3: Product: U3 Cruzer Micro
<6>[99224.904713] usb 4-1.3: Manufacturer: SanDisk
<6>[99224.904716] usb 4-1.3: SerialNumber: 22427202FB10CD97
<7>[99224.904892] usb 4-1.3: usb_probe_device
<7>[99224.904901] usb 4-1.3: configuration #1 chosen from 1 choice
<7>[99224.905078] usb 4-1.3: adding 4-1.3:1.0 (config #1, interface 0)
<6>[99224.907302] scsi13 : usb-storage 4-1.3:1.0
<7>[99224.907520] drivers/usb/core/inode.c: creating file '018'
<5>[99225.911208] scsi 13:0:0:0: Direct-Access SanDisk Cruzer
8.02 PQ: 0 ANSI: 0 CCS
<5>[99225.911485] sd 13:0:0:0: Attached scsi generic sg2 type 0
<5>[99225.913086] scsi 13:0:0:1: CD-ROM SanDisk Cruzer
8.02 PQ: 0 ANSI: 0
<5>[99225.921089] sr 13:0:0:1: Attached scsi generic sg3 type 5
Attached is a log of "udevadm monitor" when I plugged in the stick,
wait a moment and remove it again. But the messages do not stop...
I have to stop udev and start it again.
uname -a
Linux thor 2.6.39-gentoo #1 SMP Mon May 23 23:11:54 CEST 2011 i686 AMD
Athlon(tm) 7750 Dual-Core Processor AuthenticAMD GNU/Linux
I am using gentoo with sys-kernel/gentoo-sources-2.6.39. Should I test
also a vanilla kernel?
Gentoo package for udev: sys-fs/udev-168-r2
udevd --version
168
I hope someone could give me a hint...
With regards,
Markus
[-- Attachment #2: udev-monitor.log.bz2 --]
[-- Type: application/x-bzip2, Size: 4130 bytes --]
^ permalink raw reply
* Re: udev queue error
From: Kay Sievers @ 2011-05-30 20:06 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <BANLkTim9kJEroUeqpqNoE-tCRvxa5=nghw@mail.gmail.com>
On Mon, May 30, 2011 at 21:46, Markus Rathgeb <maggu2810@googlemail.com> wrote:
> If I insert a special USB stick to my computer, udev will go crazy.
> The USB stick is a "SanDisk Cruzer" device. It represents himself as a
> block device and a CD rom device.
>
> I do not know, how I could help. So please have a look at the logs:
Yeah, the fake cdrom on the stick seems pretty broken. It generates
media-changed events on very open(), and udev runs open() for the new
event, which ... creates the loop you are seeing.
# /sbin/udevadm monitor &
# touch /dev/sr1
KERNEL[1306785694.680617] change \
/devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1:1.0/host4/target4:0:0/4:0:0:1/block/sr1
(block)
ACTION=change
SUBSYSTEM=block
DISK_MEDIA_CHANGE=1
...
# grep . /sys/class/block/sr1/*
/sys/class/block/sr1/alignment_offset:0
/sys/class/block/sr1/capability:19
/sys/class/block/sr1/dev:11:1
/sys/class/block/sr1/discard_alignment:0
/sys/class/block/sr1/events:media_change eject_request
/sys/class/block/sr1/events_poll_msecs:-1
/sys/class/block/sr1/ext_range:1
/sys/class/block/sr1/inflight: 0 0
/sys/class/block/sr1/range:1
/sys/class/block/sr1/removable:1
/sys/class/block/sr1/ro:0
/sys/class/block/sr1/size:62972
We need to find a way to work around such issues in the kernel, I guess.
Tejun, any idea?
Kay
^ permalink raw reply
* failure test of udev-164
From: Agostino Sarubbo @ 2011-05-30 21:51 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: Text/Plain, Size: 305 bytes --]
https://bugs.gentoo.org/show_bug.cgi?id=369395
regards
--
Agostino Sarubbo ( ago )
Mail: ago@autistici.org
Irc: irc.freenode.net ago
Gpg: 0x7CD2DC5D
Arch Tester for Gentoo Linux amd64 http://is.gd/hcQem
Admin for HacklabCS c/o HPCC at Unical
This mail has been sent with kmail on gentoo.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: failure test of udev-164
From: Kay Sievers @ 2011-05-30 22:34 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201105302351.09160.ago@autistici.org>
On Mon, May 30, 2011 at 23:51, Agostino Sarubbo <ago@autistici.org> wrote:
> https://bugs.gentoo.org/show_bug.cgi?id69395
> PASS: test/udev-test.pl
> File "./test/rule-syntax-check.py", line 58
> print 'Invalid line %s:%i: %s' % (path, lineno, line)
> ^
> SyntaxError: invalid syntax
> FAIL: test/rules-test.sh
> =======================
> 1 of 2 tests failed
> Please report to linux-hotplug@vger.kernel.org
> =======================
That works fine here. Maybe your python is different and is causing it to fail.
Kay
^ permalink raw reply
* Re: failure test of udev-164
From: Agostino Sarubbo @ 2011-05-30 22:35 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201105302351.09160.ago@autistici.org>
[-- Attachment #1: Type: Text/Plain, Size: 1081 bytes --]
On Tuesday 31 May 2011 00:34:16 Kay Sievers wrote:
> On Mon, May 30, 2011 at 23:51, Agostino Sarubbo <ago@autistici.org> wrote:
> > https://bugs.gentoo.org/show_bug.cgi?id=369395
> >
> > PASS: test/udev-test.pl
> >
> > File "./test/rule-syntax-check.py", line 58
> >
> > print 'Invalid line %s:%i: %s' % (path, lineno, line)
> >
> > ^
> >
> > SyntaxError: invalid syntax
> > FAIL: test/rules-test.sh
> > ==============================================
> > 1 of 2 tests failed
> > Please report to linux-hotplug@vger.kernel.org
> > ==============================================
>
> That works fine here. Maybe your python is different and is causing it to
> fail.
>
> Kay
Sure, but it should be amended to works with new version of python?
I'm using python 3.2
--
Agostino Sarubbo ( ago )
Mail: ago@autistici.org
Irc: irc.freenode.net ago
Gpg: 0x7CD2DC5D
Arch Tester for Gentoo Linux amd64 http://is.gd/hcQem
Admin for HacklabCS c/o HPCC at Unical
This mail has been sent with kmail on gentoo.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox