* [PATCH V4 1/2] tracing, perf : add cpu hotplug trace events
From: Vincent Guittot @ 2011-01-31 10:22 UTC (permalink / raw)
To: linux-kernel, linux-hotplug, fweisbec, rostedt, amit.kucheria
Please find below a new proposal for adding trace events for cpu hotplug.
The goal is to measure the latency of each part (kernel, architecture)
and also to trace the cpu hotplug activity with other power events. I
have tested these traces events on an arm platform.
Subject: [PATCH 1/2] cpu hotplug tracepoint
this patch adds new events for cpu hotplug tracing
* plug/unplug sequence
* core and architecture latency measurements
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
---
include/trace/events/cpu_hotplug.h | 103 ++++++++++++++++++++++++++++++++++++
1 files changed, 103 insertions(+), 0 deletions(-)
create mode 100644 include/trace/events/cpu_hotplug.h
diff --git a/include/trace/events/cpu_hotplug.h
b/include/trace/events/cpu_hotplug.h
new file mode 100644
index 0000000..af05775
--- /dev/null
+++ b/include/trace/events/cpu_hotplug.h
@@ -0,0 +1,103 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM cpu_hotplug
+
+#if !defined(_TRACE_CPU_HOTPLUG_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_CPU_HOTPLUG_H
+
+#include <linux/tracepoint.h>
+
+DECLARE_EVENT_CLASS(cpu_hotplug,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid),
+
+ TP_STRUCT__entry(
+ __field( unsigned int, cpuid )
+ ),
+
+ TP_fast_assign(
+ __entry->cpuid = cpuid;
+ ),
+
+ TP_printk("cpuid=%u", __entry->cpuid)
+);
+
+/* Core function of cpu hotplug */
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_down_start,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_down_end,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_up_start,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_up_end,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+/* Architecture function for cpu hotplug */
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_disable_start,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_disable_end,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_die_start,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_die_end,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_up_start,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_up_end,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+#endif /* _TRACE_CPU_HOTPLUG_H */
+
+/* This part must be outside protection */
+#include <trace/define_trace.h>
--
1.7.1
^ permalink raw reply related
* [PATCH V4 2/2] tracing, perf : add cpu hotplug trace events
From: Vincent Guittot @ 2011-01-31 10:23 UTC (permalink / raw)
To: linux-kernel, linux-hotplug, fweisbec, rostedt, amit.kucheria
Please find below a new proposal for adding trace events for cpu hotplug.
The goal is to measure the latency of each part (kernel, architecture)
and also to trace the cpu hotplug activity with other power events. I
have tested these traces events on an arm platform.
Subject: [PATCH 2/2] add hotplug tracepoint
this patch adds new events for cpu hotplug tracing
* plug/unplug sequence
* core and architecture latency measurements
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
---
kernel/cpu.c | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 156cc55..692e819 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -16,6 +16,9 @@
#include <linux/mutex.h>
#include <linux/gfp.h>
+#define CREATE_TRACE_POINTS
+#include <trace/events/cpu_hotplug.h>
+
#ifdef CONFIG_SMP
/* Serializes the updates to cpu_online_mask, cpu_present_mask */
static DEFINE_MUTEX(cpu_add_remove_lock);
@@ -197,10 +200,13 @@ struct take_cpu_down_param {
static int __ref take_cpu_down(void *_param)
{
struct take_cpu_down_param *param = _param;
+ unsigned int cpu = (unsigned int)(param->hcpu);
int err;
/* Ensure this CPU doesn't handle any more interrupts. */
+ trace_cpu_hotplug_disable_start(cpu);
err = __cpu_disable();
+ trace_cpu_hotplug_disable_end(cpu);
if (err < 0)
return err;
@@ -256,7 +262,9 @@ static int __ref _cpu_down(unsigned int cpu, int
tasks_frozen)
cpu_relax();
/* This actually kills the CPU. */
+ trace_cpu_hotplug_die_start(cpu);
__cpu_die(cpu);
+ trace_cpu_hotplug_die_end(cpu);
/* CPU is completely dead: tell everyone. Too late to complain. */
cpu_notify_nofail(CPU_DEAD | mod, hcpu);
@@ -274,6 +282,8 @@ int __ref cpu_down(unsigned int cpu)
{
int err;
+ trace_cpu_hotplug_down_start(cpu);
+
cpu_maps_update_begin();
if (cpu_hotplug_disabled) {
@@ -285,6 +295,8 @@ int __ref cpu_down(unsigned int cpu)
out:
cpu_maps_update_done();
+
+ trace_cpu_hotplug_down_end(cpu);
return err;
}
EXPORT_SYMBOL(cpu_down);
@@ -310,7 +322,9 @@ static int __cpuinit _cpu_up(unsigned int cpu, int
tasks_frozen)
}
/* Arch-specific enabling code. */
+ trace_cpu_hotplug_arch_up_start(cpu);
ret = __cpu_up(cpu);
+ trace_cpu_hotplug_arch_up_end(cpu);
if (ret != 0)
goto out_notify;
BUG_ON(!cpu_online(cpu));
@@ -335,6 +349,8 @@ int __cpuinit cpu_up(unsigned int cpu)
pg_data_t *pgdat;
#endif
+ trace_cpu_hotplug_up_start(cpu);
+
if (!cpu_possible(cpu)) {
printk(KERN_ERR "can't online cpu %d because it is not "
"configured as may-hotadd at boot time\n", cpu);
@@ -376,6 +392,8 @@ int __cpuinit cpu_up(unsigned int cpu)
err = _cpu_up(cpu, 0);
+ trace_cpu_hotplug_up_end(cpu);
+
out:
cpu_maps_update_done();
return err;
--
1.7.1
^ permalink raw reply related
* microcode issues on VIA C-7
From: Ozan Çağlayan @ 2011-02-01 16:53 UTC (permalink / raw)
To: linux-hotplug
Hi,
Fedora ships a udev rule for automatic microcode loading. It seems that
this causes a weird looping on an HP mini 2133 (VIA C-7 processor).
modprobe returns "No such device" as the system does not support
microcode loading but when you listen to events with
udevadm monitor
there's an infinite loop of "/module/microcode" ADD/REMOVE. So
microcode_ctl is nearly always running according to top, hogging the
machine.
Do you have any idea what can cause this? Here's the udev rule:
KERNEL="cpu[0-9]*", ACTION="add", RUN+="/sbin/modprobe microcode"
KERNEL="microcode", ACTION="add", RUN+="/sbin/microcode_ctl -Qu"
The kernel is 2.6.37.
--
Pardus Linux
http://www.pardus.org.tr/eng
^ permalink raw reply
* Re: microcode issues on VIA C-7
From: Ozan Çağlayan @ 2011-02-06 20:26 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4D483A86.3030904@pardus.org.tr>
On 01.02.2011 18:53, Ozan Çağlayan wrote:
> The kernel is 2.6.37.
No idea? Nothing?
:)
--
Pardus Linux
http://www.pardus.org.tr/eng
^ permalink raw reply
* Re: net device renaming 2-step, IFNAMSIZ limit
From: Kay Sievers @ 2011-02-08 14:42 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20101129032908.GA29904@auslistsprd01.us.dell.com>
On Sat, Jan 29, 2011 at 16:23, Matt Domsch <Matt_Domsch@dell.com> wrote:
> On Tue, Dec 07, 2010 at 12:45:04AM -0200, Piter PUNK wrote:
>> Matt Domsch wrote:
> I need this in udev fairly quickly
> please. Some kind folks from IBM have been testing biosdevname with
> quad-port Intel SR-IOV-capable devices, and instantiating all the VFs,
> can easily have >100 eth* devices created in the kernel
> instantaneously. That bumps step 1 in the 2-step rename operation
> over IFNAMSIZ (eth100-pci2#3_62 is 16 chars).
What is all this about?
If biosdevname ever needs a two-step renaming, there is something
wrong. Two-step renaming happens only for conflicting names. We do not
want to support renaming in conflicting namespaces anymore.
Also, we can not use hashes without checking for conflicts, it's
unlikely to happen, but we just don't do such hacks. Just use the
ifindex or whatever fits to be correct.
Kay
^ permalink raw reply
* Re: net device renaming 2-step, IFNAMSIZ limit
From: Scott James Remnant @ 2011-02-08 18:07 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20101129032908.GA29904@auslistsprd01.us.dell.com>
Indeed, speaking as the guy who wrote the two-step naming, the point
was to make it possible to *swap* eth0 and eth1.
If you're renaming from eth0 -> e1 and eth1 -> e0, you don't need the
two steps, since the destination names cannot possible conflict.
Scott
On Tue, Feb 8, 2011 at 6:42 AM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Sat, Jan 29, 2011 at 16:23, Matt Domsch <Matt_Domsch@dell.com> wrote:
>> On Tue, Dec 07, 2010 at 12:45:04AM -0200, Piter PUNK wrote:
>>> Matt Domsch wrote:
>
>> I need this in udev fairly quickly
>> please. Some kind folks from IBM have been testing biosdevname with
>> quad-port Intel SR-IOV-capable devices, and instantiating all the VFs,
>> can easily have >100 eth* devices created in the kernel
>> instantaneously. That bumps step 1 in the 2-step rename operation
>> over IFNAMSIZ (eth100-pci2#3_62 is 16 chars).
>
> What is all this about?
>
> If biosdevname ever needs a two-step renaming, there is something
> wrong. Two-step renaming happens only for conflicting names. We do not
> want to support renaming in conflicting namespaces anymore.
>
> Also, we can not use hashes without checking for conflicts, it's
> unlikely to happen, but we just don't do such hacks. Just use the
> ifindex or whatever fits to be correct.
>
> 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: net device renaming 2-step, IFNAMSIZ limit
From: Matt Domsch @ 2011-02-09 16:21 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20101129032908.GA29904@auslistsprd01.us.dell.com>
> On Tue, Feb 8, 2011 at 6:42 AM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> > If biosdevname ever needs a two-step renaming, there is something
> > wrong. Two-step renaming happens only for conflicting names. We do not
> > want to support renaming in conflicting namespaces anymore.
biosdevname by default uses --policy=physical, which uses the emN and
pci<slot>p<port>_<vf> convention. I believed (incorrectly)
that all renames were 2-step, thus going from eth100 -> pci4p1_63
could overflow. Since only renames in the same space use the 2-step
process, then this isn't as much of a concern.
biosdevname does have --policy=all_ethN, for those who really love
their ethN convention. It's not default, and it's not in the udev
rules file to use it, but it would be an option. As long
as we don't have >10k devices, we're ok.
> > Also, we can not use hashes without checking for conflicts, it's
> > unlikely to happen, but we just don't do such hacks. Just use the
> > ifindex or whatever fits to be correct.
I do like the idea of using ifindex here instead of a hash, just
because we allow any arbitrary-length name to be used in a rename
rule. biosdevname itself won't exceed the length, but if someone had
a rule that would move from eth12345 to eth67890, it would trigger.
Thanks,
Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
^ permalink raw reply
* [PATCH] keymap: Remove wlan from Dell
From: Matthew Garrett @ 2011-02-09 21:32 UTC (permalink / raw)
To: linux-hotplug
The Dell rfkill key is handled by hardware and the dell-laptop driver catches
the i8042 event in order to update the rfkill state. Sending wlan to userspace
will just result in userspace trying to revert the change the hardware has
just made.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
---
| 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--git a/extras/keymap/keymaps/dell b/extras/keymap/keymaps/dell
index fbbb903..4f907b3 100644
--- a/extras/keymap/keymaps/dell
+++ b/extras/keymap/keymaps/dell
@@ -5,7 +5,7 @@
0x85 brightnessdown # Fn+Down arrow Brightness Down
0x86 brightnessup # Fn+Up arrow Brightness Up
0x87 battery # Fn+F3 battery icon
-0x88 wlan # Fn+F2 Turn On/Off Wireless
+0x88 unknown # Fn+F2 Turn On/Off Wireless - handled in hardware
0x89 ejectclosecd # Fn+F10 Eject CD
0x8A suspend # Fn+F1 hibernate
0x8B switchvideomode # Fn+F8 CRT/LCD (high keycode: "displaytoggle")
--
1.7.4
^ permalink raw reply related
* Re: [PATCH] keymap: Remove wlan from Dell
From: Martin Pitt @ 2011-02-10 5:42 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1297287163-14589-1-git-send-email-mjg@redhat.com>
Hello Matthew,
Matthew Garrett [2011-02-09 16:32 -0500]:
> The Dell rfkill key is handled by hardware and the dell-laptop driver catches
> the i8042 event in order to update the rfkill state. Sending wlan to userspace
> will just result in userspace trying to revert the change the hardware has
> just made.
Thanks! Pushed.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* [RESEND] ID_SERIAL for udev bluetooth joystick events
From: Antonio Ospite @ 2011-02-10 10:42 UTC (permalink / raw)
To: linux-hotplug; +Cc: linux-input, linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 1830 bytes --]
Hi,
I have a question about udev events generated by a bluetooth joystick:
when udev generates the joystick event for a bt joystick, the ID_SERIAL
property matches the one of the bt adapter not the one of the joystick.
For example (using "udevadm monitor --property"), when connecting the
Sony Sixaxis via usb I get:
ID_SERIAL=Sony_PLAYSTATION_R_3_Controller
in the input and joystick events, but when I connect it via bt, I get:
ID_SERIAL=Broadcom_Corp_ANYCOM_Blue_USB-200_250
which matches my bluetooth adapter.
Is this expected/known, or is it a bug?
I am using kernel 2.6.37, udev 164
For the records, I also get ID_BUS=usb when connecting via bt, but I can
live with that since I can differenciate usb and bt operation using
ID_USB_DRIVER=usbhid
versus
ID_USB_DRIVER=btusb
Some insight of what I am trying to achieve with udev:
1. Monitor new joystick devices.
2. If ID_SERIAL != Sony_PLAYSTATION_R_3_Controller, then STOP.
3. Get the associated hidraw device node navigating the event tree.
4. Set leds using the value from the ID_INPUT_JOYSTICK property.
5. If ID_USB_DRIVER=usbhid do the needed pairing.
And with the current behaviour for ID_SERIAL I cannot enforce 2.
I could listen for the (hid) event and use HID_NAME which seems to be a
little more consistent:
usb -> HID_NAME=Sony PLAYSTATION(R)3 Controller
bt -> HID_NAME=PLAYSTATION(R)3 Controller
and navigate the event hierarchy to get ID_INPUT_JOYSTICK, but that is
slightly more complicated, and I am curious about the ID_SERIAL
behavior anyways :)
Thanks,
Antonio
--
Antonio Ospite
http://ao2.it
PGP public key ID: 0x4553B001
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* fixed id for mouse and keyboard
From: MONDON Daniel @ 2011-02-14 8:53 UTC (permalink / raw)
To: linux-hotplug
Hi,
For users, i have computers with TouchScreen, and application without
any mouse and keyboard.
(no access to system).
1 - There is a driver conflict between mouse and TouchScreen : multi
press and release.
I (or technicians) have to go on the machines to control them (plugging
keyboard).
2 - I want to help them to access to parts of systems by programming
shortchuts.
BUT
Hot plugged, Mouse or Keyboard are not identicaly identified (because
rarely the sames).
Both problems could be solved if i know how i can affect an unique ID
(and event) to all usb mouses and all keyboards.
How can i do that, or if i have to use an other solution ?
(For mouse, i've got the solution by eeti (eGalax driver).)
(For keyboard, i know how catching keyboard event.)
Thanks,
Daniel.
^ permalink raw reply
* [PATCH] udevadm: update prev properly
From: Kei Tokunaga @ 2011-02-15 9:59 UTC (permalink / raw)
To: linux-hotplug
Hi,
When I tried to boot a system with 256 disks x 4 paths with
device-mapper, udevadm trigger (--typeÞvices) that was called
from start_udev ended up dumping a core due to a segmentation
fault.
In udev_enumerate_get_list_entry(), if it finds the devices that
should be delayed, it calls syspath_add(). If realloc() in
syspath_add() allocates the required memory at a different memory
address, referring prev->len afterward causes the segmentation
fault. I think something like this patch may be needed.
Signed-off-by: Kei Tokunaga <tokunaga.keiich@jp.fujitsu.com>
---
udev-166-kei/libudev/libudev-enumerate.c | 3 +++
1 file changed, 3 insertions(+)
diff -puN libudev/libudev-enumerate.c~fix-prev-segfault libudev/libudev-enumerate.c
--- udev-166/libudev/libudev-enumerate.c~fix-prev-segfault 2011-02-15 13:40:23.000000000 +0900
+++ udev-166-kei/libudev/libudev-enumerate.c 2011-02-15 13:40:23.000000000 +0900
@@ -274,6 +274,9 @@ struct udev_list_entry *udev_enumerate_g
/* skip to be delayed devices, and add them to the end of the list */
if (devices_delay_end(udev_enumerate->udev, entry->syspath)) {
syspath_add(udev_enumerate, entry->syspath);
+ /* need to update prev here for the case realloc() gives
+ a different address */
+ prev = &udev_enumerate->devices[i];
continue;
}
_
^ permalink raw reply
* Re: [PATCH] udevadm: update prev properly
From: Kay Sievers @ 2011-02-15 21:31 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4D5A4E7C.3050207@jp.fujitsu.com>
On Tue, Feb 15, 2011 at 10:59, Kei Tokunaga
<tokunaga.keiich@jp.fujitsu.com> wrote:
> When I tried to boot a system with 256 disks x 4 paths with
> device-mapper, udevadm trigger (--typeÞvices) that was called
> from start_udev ended up dumping a core due to a segmentation
> fault.
>
> In udev_enumerate_get_list_entry(), if it finds the devices that
> should be delayed, it calls syspath_add(). Â If realloc() in
> syspath_add() allocates the required memory at a different memory
> address, referring prev->len afterward causes the segmentation
> fault. Â I think something like this patch may be needed.
Applied.
Thanks,
Kay
^ permalink raw reply
* biosdevname v0.3.7
From: Matt Domsch @ 2011-02-17 16:15 UTC (permalink / raw)
To: linux-hotplug, netdev, K, Narendra, Hargrave, Jordan,
Rose, Charles, Co
biosdevname, now version 0.3.7.
Major visible changes include no longer using '#' in device names (by
popular demand), no longer suggesting new names if running inside a VM
guest (tested with KVM, SLES 10 Xen, XenServer, VMware ESX, but it
uses the generic cpuid test, so should work on most virt platforms),
and a new kernel command line option 'biosdevname={0|1}' which udev
honors, to force enabling or disabling of invoking biosdevname.
Still to come: NPAR partition->port mapping support (initially
Dell-specific, but if NIC vendors have other ways to expose this,
please let me know).
Grab it here:
http://linux.dell.com/files/biosdevname/permalink/biosdevname-0.3.7.tar.gz
http://linux.dell.com/files/biosdevname/permalink/biosdevname-0.3.7.tar.gz.sign
git://linux.dell.com/biosdevname.git
I built this today for Fedora rawhide and F15, and I encourage
other distributions to pick it up as well.
shortlog:
Andrew Cooper (3):
Fix segfault when BIOS advertises zero sized PIRQ Routing Table
Add 'bonding' and 'openvswitch' to the virtual devices list
Typo fixes
Harald Hoyer (1):
Add kernel command line parameter "biosdevname={0|1}" to turn off/on
Matt Domsch (7):
don't build or package dump_pirq, use biosdecode from dmidecode instead
don't use '#' in names, use 'p' instead, by popular demand
properly look for SMBIOS, then $PIR, then recurse
update changelog
Fix test for PIRQ table version
fail PIRQ lookups if device domain is not 0
exit(4) if running a virtual machine
Thanks,
Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
^ permalink raw reply
* Suggested enhancement to udev script
From: Paul Brewer @ 2011-02-17 19:50 UTC (permalink / raw)
To: linux-hotplug
Hi,
I'm running udev-161-8.fc14.x86_64 on Fedora 14.
The script /etc/init.d/udev-post contains the boilerplate text:
"Retrigger failed udev events".
Whilst this is doubtless technically accurate, some may become a trifle
alarmed to see the word "failed" in their logs when this is a perfectly
normal state and all is working exactly as designed.
Might I suggest that instead, at boot, something like:
"Trigger outstanding udev events"
might be more appropriate?
If this is addressed to the wrong people, please accept my apologies.
Regards,
Paul
^ permalink raw reply
* Re: Suggested enhancement to udev script
From: Kay Sievers @ 2011-02-18 12:25 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20110217195043.160394d5@daddy.laptop>
On Thu, Feb 17, 2011 at 20:50, Paul Brewer <paul.brewer40@ntlworld.com> wrote:
> I'm running udev-161-8.fc14.x86_64 on Fedora 14.
> The script /etc/init.d/udev-post contains the boilerplate text:
> "Retrigger failed udev events".
>
> Whilst this is doubtless technically accurate, some may become a trifle
> alarmed to see the word "failed" in their logs when this is a perfectly
> normal state and all is working exactly as designed.
>
> Might I suggest that instead, at boot, something like:
> Â "Trigger outstanding udev events"
> might be more appropriate?
>
> If this is addressed to the wrong people, please accept my apologies.
Sysv init scripts are handled by the individual distributions not
upstream. But they will go away anyway with systemd, for which udev
ships the service files upstream.
Thanks,
Kay
^ permalink raw reply
* How to use Udev to restrict USB access only to particular set of USB sticks?
From: Vilius Benetis @ 2011-02-21 9:01 UTC (permalink / raw)
To: linux-hotplug
Hi Udev team,
The task I have: to restrict linux machine to be able to accept only a
set of particular usb keys (uniquely identified by brand and serial
numbers).
Google gave references that Udev might be helpful.
We tried to play with udev, but failed to achieve the goal.
Any ideas if this is possible, if not - maybe you know what tools to
use (non-commercial, or even commercial).
Thanks!
--
/Vilius
^ permalink raw reply
* Re: How to use Udev to restrict USB access only to particular set of
From: Andrey Borzenkov @ 2011-02-21 9:05 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTinqeg=o_bmdR0CKuVmP14x71kkrE3=zdaxx2AE=@mail.gmail.com>
On Mon, Feb 21, 2011 at 12:01 PM, Vilius Benetis
<vilius.benetis@gmail.com> wrote:
> Hi Udev team,
>
> The task I have: to restrict linux machine to be able to accept only a
> set of particular usb keys (uniquely identified by brand and serial
> numbers).
>
> Google gave references that Udev might be helpful.
>
> We tried to play with udev, but failed to achieve the goal.
>
> Any ideas if this is possible, if not - maybe you know what tools to
> use (non-commercial, or even commercial).
>
Please define "restrict". It could also be implemented on user level
by not allowing mounting e.g..
^ permalink raw reply
* Re: How to use Udev to restrict USB access only to particular set of
From: Vilius Benetis @ 2011-02-21 9:27 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTinqeg=o_bmdR0CKuVmP14x71kkrE3=zdaxx2AE=@mail.gmail.com>
Hi,
restrict - means that Linux users (non-root, to simplify the task)
could be able to access only a particular predefined set of USB
devices.
Devices:
Approved USB A (configured in the system), SN: XXX
Not approved USB B (not defined anywhere): SN: YYY
Scenario A:
USB A is plugged to the system, USB is allowed to be mounted
(automatically, or manually) for the users.
Scenario B:
USB B is plugged to the system, USB is not allowed to be mounted
(automatically, or manually) for the users.
Any ideas how to achieve this?
I looked at DLP solutions, but there is little Linux support. another
possible scope of tools - OS hardering tools, if udev would not be
able to handle.
Vilius
On Mon, Feb 21, 2011 at 11:05 AM, Andrey Borzenkov <arvidjaar@gmail.com> wrote:
> On Mon, Feb 21, 2011 at 12:01 PM, Vilius Benetis
> <vilius.benetis@gmail.com> wrote:
>> Hi Udev team,
>>
>> The task I have: to restrict linux machine to be able to accept only a
>> set of particular usb keys (uniquely identified by brand and serial
>> numbers).
>>
>> Google gave references that Udev might be helpful.
>>
>> We tried to play with udev, but failed to achieve the goal.
>>
>> Any ideas if this is possible, if not - maybe you know what tools to
>> use (non-commercial, or even commercial).
>>
>
> Please define "restrict". It could also be implemented on user level
> by not allowing mounting e.g..
>
--
/Vilius
^ permalink raw reply
* RE: fixed id for mouse and keyboard
From: MONDON Daniel @ 2011-02-21 9:47 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <D604D5FB4D200642AA2FAAE94E392586011146E8@CARAMBAR.lpg.priv>
Hi,
It looks like there is no solution ! :(
Daniel.
-----Message d'origine-----
De : linux-hotplug-owner@vger.kernel.org [mailto:linux-hotplug-owner@vger.kernel.org] De la part de MONDON Daniel
Envoyé : lundi 14 février 2011 09:54
À : linux-hotplug@vger.kernel.org
Objet : fixed id for mouse and keyboard
Hi,
For users, i have computers with TouchScreen, and application without
any mouse and keyboard.
(no access to system).
1 - There is a driver conflict between mouse and TouchScreen : multi
press and release.
I (or technicians) have to go on the machines to control them (plugging
keyboard).
2 - I want to help them to access to parts of systems by programming
shortchuts.
BUT
Hot plugged, Mouse or Keyboard are not identicaly identified (because
rarely the sames).
Both problems could be solved if i know how i can affect an unique ID
(and event) to all usb mouses and all keyboards.
How can i do that, or if i have to use an other solution ?
(For mouse, i've got the solution by eeti (eGalax driver).)
(For keyboard, i know how catching keyboard event.)
Thanks,
Daniel.
--
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: How to use Udev to restrict USB access only to particular set
From: Greg KH @ 2011-02-21 15:57 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTinqeg=o_bmdR0CKuVmP14x71kkrE3=zdaxx2AE=@mail.gmail.com>
A: No.
Q: Should I include quotations after my reply?
http://daringfireball.net/2007/07/on_top
On Mon, Feb 21, 2011 at 11:27:14AM +0200, Vilius Benetis wrote:
> Hi,
>
> restrict - means that Linux users (non-root, to simplify the task)
> could be able to access only a particular predefined set of USB
> devices.
>
> Devices:
> Approved USB A (configured in the system), SN: XXX
> Not approved USB B (not defined anywhere): SN: YYY
>
> Scenario A:
> USB A is plugged to the system, USB is allowed to be mounted
> (automatically, or manually) for the users.
>
> Scenario B:
> USB B is plugged to the system, USB is not allowed to be mounted
> (automatically, or manually) for the users.
>
> Any ideas how to achieve this?
Yes, add a udev rule to not "enable" any usb device that is a mass
storage device that does not fall in your list of "valid" devices.
There is a single sysfs file to write to which would prevent any access
to that device, use that.
Hope this helps,
greg k-h
^ permalink raw reply
* Re: [RESEND] ID_SERIAL for udev bluetooth joystick events
From: Antonio Ospite @ 2011-02-21 22:45 UTC (permalink / raw)
To: linux-hotplug; +Cc: linux-input, linux-bluetooth
In-Reply-To: <20110210114204.9639661d.ospite@studenti.unina.it>
[-- Attachment #1: Type: text/plain, Size: 7507 bytes --]
On Thu, 10 Feb 2011 11:42:04 +0100
Antonio Ospite <ospite@studenti.unina.it> wrote:
> Hi,
>
> I have a question about udev events generated by a bluetooth joystick:
> when udev generates the joystick event for a bt joystick, the ID_SERIAL
> property matches the one of the bt adapter not the one of the joystick.
>
Ok, now I have a clearer picture of what udev does when I connect the
joystick and I can pose better questions.
> For example (using "udevadm monitor --property"), when connecting the
> Sony Sixaxis via usb I get:
> ID_SERIAL=Sony_PLAYSTATION_R_3_Controller
> in the input and joystick events, but when I connect it via bt, I get:
> ID_SERIAL=Broadcom_Corp_ANYCOM_Blue_USB-200_250
> which matches my bluetooth adapter.
>
This happens because /lib/udev/usb_id goes up to the usb device when
creating the event for bt input devices connected to a btusb dongle.
> Some insight of what I am trying to achieve with udev:
> 1. Monitor new joystick devices.
> 2. If ID_SERIAL != Sony_PLAYSTATION_R_3_Controller, then STOP.
> 3. Get the associated hidraw device node navigating the event tree.
> 4. Set leds using the value from the ID_INPUT_JOYSTICK property.
This is wrong, /lib/udev/input_id hardcodes a '1' as value there, I
thought it was the index of the joystick like in:
1 -> js0
2 -> js1
but it is not, ID_INPUT_JOYSTICK=1 means just "this is a joystick", so
I think I have to parse the DEVNAME (dev/jsX) to get the actual index,
right?
> 5. If ID_USB_DRIVER=usbhid do the needed pairing.
>
> And with the current behaviour for ID_SERIAL I cannot enforce 2.
> I could listen for the (hid) event and use HID_NAME which seems to be a
> little more consistent:
> usb -> HID_NAME=Sony PLAYSTATION(R)3 Controller
> bt -> HID_NAME=PLAYSTATION(R)3 Controller
> and navigate the event hierarchy to get ID_INPUT_JOYSTICK, but that is
> slightly more complicated, and I am curious about the ID_SERIAL
> behavior anyways :)
>
Maybe I'd still better monitor the 'input' event and move up and down
from here to collect the joystick index and the hidraw device node, but
I wonder if a patch along these lines (this is just for the sake of
discussion) could have sense to prevent exposing the dongle properties
also for the input devices:
diff --git a/extras/usb_id/usb_id.c b/extras/usb_id/usb_id.c
index fabd092..8e6e20f 100644
--- a/extras/usb_id/usb_id.c
+++ b/extras/usb_id/usb_id.c
@@ -56,6 +56,7 @@ static char serial_str[UTIL_NAME_SIZE];
static char packed_if_str[UTIL_NAME_SIZE];
static char revision_str[64];
static char type_str[64];
+static char bustype_str[64];
static char instance_str[64];
static const char *ifnum;
static const char *driver;
@@ -147,6 +148,29 @@ static int set_usb_mass_storage_ifsubtype(char *to, const char *from, size_t len
return type_num;
}
+static int set_usb_input_bustype(char *to, const char *from, size_t len)
+{
+ int bustype_num = 0;
+ char *eptr;
+ char *type = "unknown";
+
+ bustype_num = strtoul(from, &eptr, 0);
+ if (eptr != from) {
+ switch (bustype_num) {
+ case 3:
+ type = "usb";
+ break;
+ case 5:
+ type = "bluetooth";
+ break;
+ default:
+ break;
+ }
+ }
+ util_strscpy(to, len, type);
+ return bustype_num;
+}
+
static void set_scsi_type(char *to, const char *from, size_t len)
{
int type_num;
@@ -312,8 +336,8 @@ static int usb_id(struct udev_device *dev)
set_usb_iftype(type_str, if_class_num, sizeof(type_str)-1);
}
- info(udev, "%s: if_class %d protocol %d\n",
- udev_device_get_syspath(dev_interface), if_class_num, protocol);
+ info(udev, "%s: if_class %d protocol %d type_str: %s\n",
+ udev_device_get_syspath(dev_interface), if_class_num, protocol, type_str);
/* usb device directory */
dev_usb = udev_device_get_parent_with_subsystem_devtype(dev_interface, "usb", "usb_device");
@@ -326,6 +350,57 @@ static int usb_id(struct udev_device *dev)
/* all interfaces of the device in a single string */
dev_if_packed_info(dev_usb, packed_if_str, sizeof(packed_if_str));
+ /* input device XXX this check is not right, we might use a dev_input
+ * as below */
+ if ((protocol == 0) && !use_usb_info) {
+ struct udev_device *dev_input;
+ const char *input_vendor, *input_model, *input_rev, *input_bustype;
+
+ /* get input device */
+ dev_input = udev_device_get_parent_with_subsystem_devtype(dev, "input", NULL);
+ if (dev_input == NULL) {
+ info(udev, "unable to find parent 'input' device of '%s'\n",
+ udev_device_get_syspath(dev));
+ goto fallback;
+ }
+
+ input_vendor = udev_device_get_sysattr_value(dev_input, "id/vendor");
+ if (!input_vendor) {
+ info(udev, "%s: cannot get input vendor attribute\n",
+ udev_device_get_sysname(dev_input));
+ goto fallback;
+ }
+ udev_util_encode_string(input_vendor, vendor_str_enc, sizeof(vendor_str_enc));
+ udev_util_replace_whitespace(input_vendor, vendor_str, sizeof(vendor_str)-1);
+ udev_util_replace_chars(vendor_str, NULL);
+
+ vendor_id = input_vendor;
+ product_id = udev_device_get_sysattr_value(dev_input, "id/product");
+
+ input_model = udev_device_get_sysattr_value(dev_input, "name");
+ if (!input_model) {
+ info(udev, "%s: cannot get input model attribute\n",
+ udev_device_get_sysname(dev_input));
+ goto fallback;
+ }
+ udev_util_encode_string(input_model, model_str_enc, sizeof(model_str_enc));
+ udev_util_replace_whitespace(input_model, model_str, sizeof(model_str)-1);
+ udev_util_replace_chars(model_str, NULL);
+
+ input_rev = udev_device_get_sysattr_value(dev_input, "id/version");
+ if (!input_rev) {
+ info(udev, "%s: cannot get input revision attribute\n",
+ udev_device_get_sysname(dev_input));
+ goto fallback;
+ }
+ udev_util_replace_whitespace(input_rev, revision_str, sizeof(revision_str)-1);
+ udev_util_replace_chars(revision_str, NULL);
+
+ /* get Bus type, see BUS_* in linux/input.h */
+ input_bustype = udev_device_get_sysattr_value(dev_input, "id/bustype");
+ set_usb_input_bustype(bustype_str, input_bustype, sizeof(bustype_str) - 1 );
+ }
+
/* mass storage : SCSI or ATAPI */
if ((protocol == 6 || protocol == 2) && !use_usb_info) {
struct udev_device *dev_scsi;
@@ -390,8 +465,12 @@ static int usb_id(struct udev_device *dev)
}
fallback:
- vendor_id = udev_device_get_sysattr_value(dev_usb, "idVendor");
- product_id = udev_device_get_sysattr_value(dev_usb, "idProduct");
+ if (vendor_id[0] == '\0') {
+ vendor_id = udev_device_get_sysattr_value(dev_usb, "idVendor");
+ }
+ if (product_id[0] == '\0') {
+ product_id = udev_device_get_sysattr_value(dev_usb, "idProduct");
+ }
/* fallback to USB vendor & device */
if (vendor_str[0] == '\0') {
@@ -559,7 +638,7 @@ int main(int argc, char **argv)
printf("ID_TYPE=%s\n", type_str);
if (instance_str[0] != '\0')
printf("ID_INSTANCE=%s\n", instance_str);
- printf("ID_BUS=usb\n");
+ printf("ID_BUS=%s\n", (bustype_str[0] == '\0') ? "usb" : bustype_str);
if (packed_if_str[0] != '\0')
printf("ID_USB_INTERFACES=:%s\n", packed_if_str);
if (ifnum != NULL)
Thanks,
Antonio
--
Antonio Ospite
http://ao2.it
PGP public key ID: 0x4553B001
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply related
* Re: How to use Udev to restrict USB access only to particular set of
From: Vilius Benetis @ 2011-02-22 13:46 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTinqeg=o_bmdR0CKuVmP14x71kkrE3=zdaxx2AE=@mail.gmail.com>
On Mon, Feb 21, 2011 at 5:57 PM, Greg KH <greg@kroah.com> wrote:
> Yes, add a udev rule to not "enable" any usb device that is a mass
> storage device that does not fall in your list of "valid" devices.
> There is a single sysfs file to write to which would prevent any access
> to that device, use that.
Greg,
by any chance you could draft the command structure, as I think we
tried this, but probably it did not work for some reason?
Thanks for the assistance,
Vilius
^ permalink raw reply
* Re: How to use Udev to restrict USB access only to particular set
From: Greg KH @ 2011-02-22 13:54 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTinqeg=o_bmdR0CKuVmP14x71kkrE3=zdaxx2AE=@mail.gmail.com>
On Tue, Feb 22, 2011 at 03:46:06PM +0200, Vilius Benetis wrote:
> On Mon, Feb 21, 2011 at 5:57 PM, Greg KH <greg@kroah.com> wrote:
> > Yes, add a udev rule to not "enable" any usb device that is a mass
> > storage device that does not fall in your list of "valid" devices.
> > There is a single sysfs file to write to which would prevent any access
> > to that device, use that.
>
> Greg,
>
> by any chance you could draft the command structure, as I think we
> tried this, but probably it did not work for some reason?
Can you post what you tried and the errors you got from that?
You should also look at the archives for this list, as this topic comes
up every 6 months or so, and has been solved numerous times in the past.
thanks,
greg k-h
^ permalink raw reply
* Re: How to use Udev to restrict USB access only to particular set of
From: Vilius Benetis @ 2011-02-22 14:01 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTinqeg=o_bmdR0CKuVmP14x71kkrE3=zdaxx2AE=@mail.gmail.com>
On Tue, Feb 22, 2011 at 3:54 PM, Greg KH <greg@kroah.com> wrote:
> Can you post what you tried and the errors you got from that?
> You should also look at the archives for this list, as this topic comes
> up every 6 months or so, and has been solved numerous times in the past.
ok, to save the ether, I will search the archives. I looked at them
initially - before posting my question, but could not spot the
mentioned discussions.
There are no errors, just functionality does not work, as we think it should.
Greetings,
vilius
^ 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