* Re: [PATCH] udev-acl: really fix ACL assignment in CK events
From: Kay Sievers @ 2010-08-04 10:03 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100804115325.6599879e@hammerfall>
On Wed, Aug 4, 2010 at 11:53, Michal Schmidt <mschmidt@redhat.com> wrote:
> The previous fix for udev-acl was incomplete. The ACL were not properly
> assigned to the new user when switching from root's session because of
> the test for 'uid != 0'.
Applied.
Thanks,
Kay
^ permalink raw reply
* [PATCH] udev-acl: really fix ACL assignment in CK events
From: Michal Schmidt @ 2010-08-04 9:53 UTC (permalink / raw)
To: linux-hotplug
The previous fix for udev-acl was incomplete. The ACL were not properly
assigned to the new user when switching from root's session because of
the test for 'uid != 0'.
Centralize the special handling of root to a single place (in set_facl).
(Also remove repeated #includes.)
https://bugzilla.redhat.com/show_bug.cgi?id`8712
---
| 37 +++++++++++++++++++------------------
1 files changed, 19 insertions(+), 18 deletions(-)
--git a/extras/udev-acl/udev-acl.c b/extras/udev-acl/udev-acl.c
index f2b5005..31e9991 100644
--- a/extras/udev-acl/udev-acl.c
+++ b/extras/udev-acl/udev-acl.c
@@ -12,20 +12,18 @@
* General Public License for more details:
*/
-#include <stdio.h>
-#include <errno.h>
-#include <string.h>
-#include <inttypes.h>
-#include <unistd.h>
-#include <stdlib.h>
-#include <stdio.h>
-#include <string.h>
+#include <acl/libacl.h>
+#include <sys/stat.h>
#include <errno.h>
#include <getopt.h>
-#include <sys/stat.h>
#include <glib.h>
-#include <acl/libacl.h>
+#include <inttypes.h>
#include <libudev.h>
+#include <stdbool.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
static int debug;
@@ -45,6 +43,10 @@ static int set_facl(const char* filename, uid_t uid, int add)
acl_permset_t permset;
int ret;
+ /* don't touch ACLs for root */
+ if (uid = 0)
+ return 0;
+
/* read current record */
acl = acl_get_file(filename, ACL_TYPE_ACCESS);
if (!acl)
@@ -190,8 +192,6 @@ static int consolekit_called(const char *ck_action, uid_t *uid, uid_t *uid2, con
if (s = NULL)
return -1;
u = strtoul(s, NULL, 10);
- if (u = 0)
- return 0;
s = getenv("CK_SEAT_SESSION_IS_LOCAL");
if (s = NULL)
@@ -205,8 +205,6 @@ static int consolekit_called(const char *ck_action, uid_t *uid, uid_t *uid2, con
if (s = NULL)
return -1;
u = strtoul(s, NULL, 10);
- if (u = 0)
- return 0;
s = getenv("CK_SEAT_OLD_SESSION_IS_LOCAL");
if (s = NULL)
@@ -331,6 +329,7 @@ int main (int argc, char* argv[])
};
int action = -1;
const char *device = NULL;
+ bool uid_given = false;
uid_t uid = 0;
uid_t uid2 = 0;
const char* remove_session_id = NULL;
@@ -357,6 +356,7 @@ int main (int argc, char* argv[])
device = optarg;
break;
case 'u':
+ uid_given = true;
uid = strtoul(optarg, NULL, 10);
break;
case 'd':
@@ -369,8 +369,9 @@ int main (int argc, char* argv[])
}
}
- if (action < 0 && device = NULL && uid = 0)
- consolekit_called(argv[optind], &uid, &uid2, &remove_session_id, &action);
+ if (action < 0 && device = NULL && !uid_given)
+ if (!consolekit_called(argv[optind], &uid, &uid2, &remove_session_id, &action))
+ uid_given = true;
if (action < 0) {
fprintf(stderr, "missing action\n\n");
@@ -378,13 +379,13 @@ int main (int argc, char* argv[])
goto out;
}
- if (device != NULL && uid != 0) {
+ if (device != NULL && uid_given) {
fprintf(stderr, "only one option, --deviceÞVICEFILE or --user=UID expected\n\n");
rc = 3;
goto out;
}
- if (uid != 0) {
+ if (uid_given) {
switch (action) {
case ACTION_ADD:
/* Add ACL for given uid to all matching devices. */
--
1.7.2
^ permalink raw reply related
* Re: Figuring out devnodes from a usb device
From: Felipe Balbi @ 2010-08-04 5:09 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4C55D1CF.5090206@felipebalbi.com>
Hi,
On 08/03/2010 11:32 PM, Greg KH wrote:
> How do you know what a vendor-specific device is doing? Are you going
> to be able to parse the HID descriptors to know what type of input
> device(s) are present?
we can start simple. USBCV only runs the chapter 9 tests (which are
pretty much verifying if the device responds to standard requests
accordingly) which any device, and runs a set of MSC tests on MSC devices.
We can start with only that and improve later on.
--
balbi
^ permalink raw reply
* Re: Figuring out devnodes from a usb device
From: Greg KH @ 2010-08-03 20:32 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4C55D1CF.5090206@felipebalbi.com>
On Tue, Aug 03, 2010 at 11:20:41PM +0300, Felipe Balbi wrote:
> Hi,
>
> On 08/03/2010 10:53 PM, Greg KH wrote:
> > "USBCV"?
>
> USB Command Verifier. The tool used on USB Certification, well of them.
Good luck with that. We tried to offer something like that many years
ago, but the effort fizzled out when the amount of work required was
determined. But don't let me stop you from trying :)
> > It's not impossible, just not something you can do without knowing the
> > type of device you are looking at.
>
> as long as I can believe on the USB Descriptors that shouldn't be so
> difficult. Just check device descriptor and interface descriptors to
> figure out which kind of device(s) are we dealing with.
How do you know what a vendor-specific device is doing? Are you going
to be able to parse the HID descriptors to know what type of input
device(s) are present?
Look at what Kay provided, that will get you what you need.
good luck,
greg k-h
^ permalink raw reply
* Re: Figuring out devnodes from a usb device
From: Felipe Balbi @ 2010-08-03 20:20 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4C55D1CF.5090206@felipebalbi.com>
Hi,
On 08/03/2010 10:53 PM, Greg KH wrote:
> "USBCV"?
USB Command Verifier. The tool used on USB Certification, well of them.
> It's not impossible, just not something you can do without knowing the
> type of device you are looking at.
as long as I can believe on the USB Descriptors that shouldn't be so
difficult. Just check device descriptor and interface descriptors to
figure out which kind of device(s) are we dealing with.
--
balbi
^ permalink raw reply
* Re: Figuring out devnodes from a usb device
From: Greg KH @ 2010-08-03 19:53 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4C55D1CF.5090206@felipebalbi.com>
On Tue, Aug 03, 2010 at 10:28:18AM +0300, Felipe Balbi wrote:
> On 08/03/2010 01:29 AM, Greg KH wrote:
> Hi,
>
> Thanks for you reply Greg
>
> > On Sun, Aug 01, 2010 at 10:58:07PM +0300, Felipe Balbi wrote:
> >> Hi all,
> >>
> >> I'm trying to figure out how I could find all devnodes related to a USB
> >> device.
> >
> > That's hard, as there are lots of different types of USB devices.
> >
> > It's like saying, "I want to find all devnodes for a PCI device" :)
> >
> >> For example, if I attach a usb mass storage device I want to
> >> figure out which /dev/sdXX I'm supposed to use when trying to read/write
> >> to that particular device. Similarly for ACM, Network and all other devices.
> >
> > For each type of device, you are going to have to do it differently.
> > And note that network devices don't have device nodes, so that makes it
> > harder to make a "general" case here.
> >
> >> Is there any way to achieve that with libudev ?
> >
> > Yes, but it's going to have to be type (i.e. class) specific.
> >
> >> I tried using
> >> udev_device_get_devlinks_list_entry() but that didn't help.
> >
> > You might not be looking at the "right" device. You will have to go up
> > and down the device tree to find the correct one, depending on the type.
> > And what about devices with multiple interfaces, with different device
> > nodes (like the famous disk drive with a button on it, mass-storage and
> > a HID device).
>
> those are the cases I was actually looking for. It's, then, practically
> impossible to have a USBCV tool written for linux.
"USBCV"?
> There are missing pieces on the kernel and even if the missing on the
> kernel is implemented, it's gonna be difficult to find the devices we
> have o talk to anyway. Unless we do the entire class implementation
> with pure libusb or usbfs when e.g. testing MSC devices.
It's not impossible, just not something you can do without knowing the
type of device you are looking at.
thanks,
greg k-h
^ permalink raw reply
* Re: Figuring out devnodes from a usb device
From: Kay Sievers @ 2010-08-03 9:13 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4C55D1CF.5090206@felipebalbi.com>
On Tue, Aug 3, 2010 at 09:28, Felipe Balbi <me@felipebalbi.com> wrote:
>>> For example, if I attach a usb mass storage device I want to
>>> figure out which /dev/sdXX I'm supposed to use when trying to read/write
>>> to that particular device. Similarly for ACM, Network and all other devices.
>>
>> For each type of device, you are going to have to do it differently.
>> And note that network devices don't have device nodes, so that makes it
>> harder to make a "general" case here.
>>
>>> Is there any way to achieve that with libudev ?
That's not provided by libudev, but would be possible to do.
It would need an 'udev enumerator' that starts at a given device,
and returns a list of all the children, which can be investigated
individually. All current 'enumerators' only operate on specific
properties of a device, not on parent-child relations.
All devices belonging to a specific USB device are sysfs child devices of
it. It's a simple tree you can walk. The child devices may have their own
device nodes (here: mouse2, event10), and may also belong to different
subsystems (here: input, hid).
That should work for all interfaces a device provides and which is
currently bound by a kernel driver. Note, that not all drivers use a device
node as the interface. No device node does never mean, that there is no
active driver.
$ tree -d /sys/bus/usb/devices/5-2.1.2
/sys/bus/usb/devices/5-2.1.2
├── 5-2.1.2:1.0
│ ├── 0003:046D:C045.0009
│ │ ├── driver -> ../../../../../../../../../bus/hid/drivers/generic-usb
│ │ ├── power
│ │ └── subsystem -> ../../../../../../../../../bus/hid
│ ├── driver -> ../../../../../../../../bus/usb/drivers/usbhid
│ ├── ep_81
│ │ └── power
│ ├── input
│ │ └── input16
│ │ ├── capabilities
│ │ ├── device -> ../../../5-2.1.2:1.0
│ │ ├── event10
│ │ │ ├── device -> ../../input16
│ │ │ ├── power
│ │ │ └── subsystem -> ../../../../../../../../../../../class/input
│ │ ├── id
│ │ ├── mouse2
│ │ │ ├── device -> ../../input16
│ │ │ ├── power
│ │ │ └── subsystem -> ../../../../../../../../../../../class/input
│ │ ├── power
│ │ └── subsystem -> ../../../../../../../../../../class/input
│ ├── power
│ └── subsystem -> ../../../../../../../../bus/usb
├── driver -> ../../../../../../../bus/usb/drivers/usb
├── ep_00
│ └── power
├── power
└── subsystem -> ../../../../../../../bus/usb
Kay
^ permalink raw reply
* Re: Figuring out devnodes from a usb device
From: Felipe Balbi @ 2010-08-03 7:28 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4C55D1CF.5090206@felipebalbi.com>
On 08/03/2010 01:29 AM, Greg KH wrote:
Hi,
Thanks for you reply Greg
> On Sun, Aug 01, 2010 at 10:58:07PM +0300, Felipe Balbi wrote:
>> Hi all,
>>
>> I'm trying to figure out how I could find all devnodes related to a USB
>> device.
>
> That's hard, as there are lots of different types of USB devices.
>
> It's like saying, "I want to find all devnodes for a PCI device" :)
>
>> For example, if I attach a usb mass storage device I want to
>> figure out which /dev/sdXX I'm supposed to use when trying to read/write
>> to that particular device. Similarly for ACM, Network and all other devices.
>
> For each type of device, you are going to have to do it differently.
> And note that network devices don't have device nodes, so that makes it
> harder to make a "general" case here.
>
>> Is there any way to achieve that with libudev ?
>
> Yes, but it's going to have to be type (i.e. class) specific.
>
>> I tried using
>> udev_device_get_devlinks_list_entry() but that didn't help.
>
> You might not be looking at the "right" device. You will have to go up
> and down the device tree to find the correct one, depending on the type.
> And what about devices with multiple interfaces, with different device
> nodes (like the famous disk drive with a button on it, mass-storage and
> a HID device).
those are the cases I was actually looking for. It's, then, practically
impossible to have a USBCV tool written for linux. There are missing
pieces on the kernel and even if the missing on the kernel is
implemented, it's gonna be difficult to find the devices we have o talk
to anyway. Unless we do the entire class implementation with pure libusb
or usbfs when e.g. testing MSC devices.
--
balbi
^ permalink raw reply
* Re: Figuring out devnodes from a usb device
From: Greg KH @ 2010-08-02 22:29 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4C55D1CF.5090206@felipebalbi.com>
On Sun, Aug 01, 2010 at 10:58:07PM +0300, Felipe Balbi wrote:
> Hi all,
>
> I'm trying to figure out how I could find all devnodes related to a USB
> device.
That's hard, as there are lots of different types of USB devices.
It's like saying, "I want to find all devnodes for a PCI device" :)
> For example, if I attach a usb mass storage device I want to
> figure out which /dev/sdXX I'm supposed to use when trying to read/write
> to that particular device. Similarly for ACM, Network and all other devices.
For each type of device, you are going to have to do it differently.
And note that network devices don't have device nodes, so that makes it
harder to make a "general" case here.
> Is there any way to achieve that with libudev ?
Yes, but it's going to have to be type (i.e. class) specific.
> I tried using
> udev_device_get_devlinks_list_entry() but that didn't help.
You might not be looking at the "right" device. You will have to go up
and down the device tree to find the correct one, depending on the type.
And what about devices with multiple interfaces, with different device
nodes (like the famous disk drive with a button on it, mass-storage and
a HID device).
good luck,
greg k-h
^ permalink raw reply
* Re: [PATCH 2/2 V2] fix some memory leaks.
From: Kay Sievers @ 2010-08-02 10:36 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100802103118.GM29131@kai-debian>
On Mon, Aug 2, 2010 at 12:31, Yin Kangkai <kangkai.yin@linux.intel.com> wrote:
> V2 for this patch, only the memory leaks fix. Thanks Kay.
Applied.
I think the malloc()+memset() -> calloc conversion you did was fine
and we should do that. Only the calloc() where it is not needed we
should drop. :)
Thanks,
Kay
^ permalink raw reply
* [PATCH 2/2 V2] fix some memory leaks.
From: Yin Kangkai @ 2010-08-02 10:31 UTC (permalink / raw)
To: linux-hotplug
V2 for this patch, only the memory leaks fix. Thanks Kay.
From e550d7b79b7a8b1b4037d063e9630b3130005d80 Mon Sep 17 00:00:00 2001
From: Yin Kangkai <kangkai.yin@intel.com>
Date: Mon, 2 Aug 2010 18:25:32 +0800
Subject: [PATCH] Fix some memory leaks.
Signed-off-by: Yin Kangkai <kangkai.yin@intel.com>
---
udev/udev-rules.c | 15 ++++++++++++---
udev/udevd.c | 4 +++-
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/udev/udev-rules.c b/udev/udev-rules.c
index 6d32e73..4b81a50 100644
--- a/udev/udev-rules.c
+++ b/udev/udev-rules.c
@@ -1761,13 +1761,18 @@ struct udev_rules *udev_rules_new(struct udev *udev, int resolve_names)
/* init token array and string buffer */
rules->tokens = malloc(PREALLOC_TOKEN * sizeof(struct token));
- if (rules->tokens = NULL)
+ if (rules->tokens = NULL) {
+ free(rules);
return NULL;
+ }
rules->token_max = PREALLOC_TOKEN;
rules->buf = malloc(PREALLOC_STRBUF);
- if (rules->buf = NULL)
+ if (rules->buf = NULL) {
+ free(rules->tokens);
+ free(rules);
return NULL;
+ }
rules->buf_max = PREALLOC_STRBUF;
/* offset 0 is always '\0' */
rules->buf[0] = '\0';
@@ -1776,8 +1781,12 @@ struct udev_rules *udev_rules_new(struct udev *udev, int resolve_names)
rules->token_max * sizeof(struct token), rules->token_max, sizeof(struct token), rules->buf_max);
rules->trie_nodes = malloc(PREALLOC_TRIE * sizeof(struct trie_node));
- if (rules->trie_nodes = NULL)
+ if (rules->trie_nodes = NULL) {
+ free(rules->buf);
+ free(rules->tokens);
+ free(rules);
return NULL;
+ }
rules->trie_nodes_max = PREALLOC_TRIE;
/* offset 0 is the trie root, with an empty string */
memset(rules->trie_nodes, 0x00, sizeof(struct trie_node));
diff --git a/udev/udevd.c b/udev/udevd.c
index 95d4ad8..a7e4c8f 100644
--- a/udev/udevd.c
+++ b/udev/udevd.c
@@ -227,8 +227,10 @@ static void worker_new(struct event *event)
udev_monitor_enable_receiving(worker_monitor);
worker = calloc(1, sizeof(struct worker));
- if (worker = NULL)
+ if (worker = NULL) {
+ udev_monitor_unref(worker_monitor);
return;
+ }
/* worker + event reference */
worker->refcount = 2;
worker->udev = event->udev;
--
1.6.5
^ permalink raw reply related
* Re: [PATCH 2/2] malloc -> calloc and fix some memory leaks.
From: Kay Sievers @ 2010-08-02 10:13 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100802034353.GK29131@kai-debian>
On Mon, Aug 2, 2010 at 12:00, Yin Kangkai <kangkai.yin@linux.intel.com> wrote:
> On 2010-08-02, 11:00 +0200, Kay Sievers wrote:
>> On Mon, Aug 2, 2010 at 05:43, Yin Kangkai <kangkai.yin@linux.intel.com> wrote:
>> > From fd81bea16d3e1e93aebc8cb80ec16ae9c20c6e41 Mon Sep 17 00:00:00 2001
>> > From: Yin Kangkai <kangkai.yin@intel.com>
>> > Date: Mon, 2 Aug 2010 11:22:49 +0800
>> > Subject: [PATCH 2/2] malloc -> calloc and fix some memory leaks.
>> >
>> > calloc so that we do not need to memset each of them.
>>
>> Any reason to change things to calloc() where no memset() is done or needed?
>
> I changed the malloc and memset pair of udev_rules allocation, and for
> consistence, I finished the others :)
>
> Maybe it's only my personal taste that I like to memset memory once I
> malloc success. If this is not necessary, I can split the patch.
Nah, I mean memset(), and calloc() is only necessary if the memory is
read, and not always overwritten anyway by the next operation, like
read() or similar. I don't think that needs to be 'fixed'.
Kay
^ permalink raw reply
* Re: [PATCH 2/2] malloc -> calloc and fix some memory leaks.
From: Yin Kangkai @ 2010-08-02 10:00 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100802034353.GK29131@kai-debian>
On 2010-08-02, 11:00 +0200, Kay Sievers wrote:
> On Mon, Aug 2, 2010 at 05:43, Yin Kangkai <kangkai.yin@linux.intel.com> wrote:
> > From fd81bea16d3e1e93aebc8cb80ec16ae9c20c6e41 Mon Sep 17 00:00:00 2001
> > From: Yin Kangkai <kangkai.yin@intel.com>
> > Date: Mon, 2 Aug 2010 11:22:49 +0800
> > Subject: [PATCH 2/2] malloc -> calloc and fix some memory leaks.
> >
> > calloc so that we do not need to memset each of them.
>
> Any reason to change things to calloc() where no memset() is done or needed?
I changed the malloc and memset pair of udev_rules allocation, and for
consistence, I finished the others :)
Maybe it's only my personal taste that I like to memset memory once I
malloc success. If this is not necessary, I can split the patch.
Thanks,
Kangkai
^ permalink raw reply
* Re: [PATCH 2/2] malloc -> calloc and fix some memory leaks.
From: Kay Sievers @ 2010-08-02 9:00 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100802034353.GK29131@kai-debian>
On Mon, Aug 2, 2010 at 05:43, Yin Kangkai <kangkai.yin@linux.intel.com> wrote:
> From fd81bea16d3e1e93aebc8cb80ec16ae9c20c6e41 Mon Sep 17 00:00:00 2001
> From: Yin Kangkai <kangkai.yin@intel.com>
> Date: Mon, 2 Aug 2010 11:22:49 +0800
> Subject: [PATCH 2/2] malloc -> calloc and fix some memory leaks.
>
> calloc so that we do not need to memset each of them.
Any reason to change things to calloc() where no memset() is done or needed?
Kay
^ permalink raw reply
* [PATCH 2/2] malloc -> calloc and fix some memory leaks.
From: Yin Kangkai @ 2010-08-02 3:43 UTC (permalink / raw)
To: linux-hotplug
From fd81bea16d3e1e93aebc8cb80ec16ae9c20c6e41 Mon Sep 17 00:00:00 2001
From: Yin Kangkai <kangkai.yin@intel.com>
Date: Mon, 2 Aug 2010 11:22:49 +0800
Subject: [PATCH 2/2] malloc -> calloc and fix some memory leaks.
calloc so that we do not need to memset each of them.
Signed-off-by: Yin Kangkai <kangkai.yin@intel.com>
---
udev/udev-rules.c | 24 ++++++++++++++++--------
udev/udevd.c | 6 ++++--
2 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/udev/udev-rules.c b/udev/udev-rules.c
index 6d32e73..072b31b 100644
--- a/udev/udev-rules.c
+++ b/udev/udev-rules.c
@@ -1751,23 +1751,27 @@ struct udev_rules *udev_rules_new(struct udev *udev, int resolve_names)
struct udev_list_entry *file_loop, *file_tmp;
struct token end_token;
- rules = malloc(sizeof(struct udev_rules));
+ rules = calloc(1, sizeof(struct udev_rules));
if (rules = NULL)
return NULL;
- memset(rules, 0x00, sizeof(struct udev_rules));
rules->udev = udev;
rules->resolve_names = resolve_names;
udev_list_init(&file_list);
/* init token array and string buffer */
- rules->tokens = malloc(PREALLOC_TOKEN * sizeof(struct token));
- if (rules->tokens = NULL)
+ rules->tokens = calloc(PREALLOC_TOKEN, sizeof(struct token));
+ if (rules->tokens = NULL) {
+ free(rules);
return NULL;
+ }
rules->token_max = PREALLOC_TOKEN;
- rules->buf = malloc(PREALLOC_STRBUF);
- if (rules->buf = NULL)
+ rules->buf = calloc(1, PREALLOC_STRBUF);
+ if (rules->buf = NULL) {
+ free(rules->tokens);
+ free(rules);
return NULL;
+ }
rules->buf_max = PREALLOC_STRBUF;
/* offset 0 is always '\0' */
rules->buf[0] = '\0';
@@ -1775,9 +1779,13 @@ struct udev_rules *udev_rules_new(struct udev *udev, int resolve_names)
dbg(udev, "prealloc %zu bytes tokens (%u * %zu bytes), %zu bytes buffer\n",
rules->token_max * sizeof(struct token), rules->token_max, sizeof(struct token), rules->buf_max);
- rules->trie_nodes = malloc(PREALLOC_TRIE * sizeof(struct trie_node));
- if (rules->trie_nodes = NULL)
+ rules->trie_nodes = calloc(PREALLOC_TRIE, sizeof(struct trie_node));
+ if (rules->trie_nodes = NULL) {
+ free(rules->buf);
+ free(rules->tokens);
+ free(rules);
return NULL;
+ }
rules->trie_nodes_max = PREALLOC_TRIE;
/* offset 0 is the trie root, with an empty string */
memset(rules->trie_nodes, 0x00, sizeof(struct trie_node));
diff --git a/udev/udevd.c b/udev/udevd.c
index 95d4ad8..b882479 100644
--- a/udev/udevd.c
+++ b/udev/udevd.c
@@ -227,8 +227,10 @@ static void worker_new(struct event *event)
udev_monitor_enable_receiving(worker_monitor);
worker = calloc(1, sizeof(struct worker));
- if (worker = NULL)
+ if (worker = NULL) {
+ udev_monitor_unref(worker_monitor);
return;
+ }
/* worker + event reference */
worker->refcount = 2;
worker->udev = event->udev;
@@ -655,7 +657,7 @@ static int handle_inotify(struct udev *udev)
if ((ioctl(pfd[FD_INOTIFY].fd, FIONREAD, &nbytes) < 0) || (nbytes <= 0))
return 0;
- buf = malloc(nbytes);
+ buf = calloc(1, nbytes);
if (buf = NULL) {
err(udev, "error getting buffer for inotify\n");
return -1;
--
1.6.5
^ permalink raw reply related
* [PATCH 1/2] udevd: fix short options in getopt()
From: Yin Kangkai @ 2010-08-02 3:40 UTC (permalink / raw)
To: linux-hotplug
From 7fca3141aaf365a630b0a730fc0ee3ad1514d420 Mon Sep 17 00:00:00 2001
From: Yin Kangkai <kangkai.yin@intel.com>
Date: Thu, 29 Jul 2010 10:47:54 +0800
Subject: [PATCH 1/2] udevd: fix short options in getopt()
Otherwise, run udevd like "udevd -c" will seg fault.
Signed-off-by: Yin Kangkai <kangkai.yin@intel.com>
---
udev/udevd.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/udev/udevd.c b/udev/udevd.c
index 873634f..95d4ad8 100644
--- a/udev/udevd.c
+++ b/udev/udevd.c
@@ -1060,7 +1060,7 @@ int main(int argc, char *argv[])
for (;;) {
int option;
- option = getopt_long(argc, argv, "cdeDthV", options, NULL);
+ option = getopt_long(argc, argv, "c:de:DhVN:", options, NULL);
if (option = -1)
break;
--
1.6.5
^ permalink raw reply related
* Figuring out devnodes from a usb device
From: Felipe Balbi @ 2010-08-01 19:58 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 576 bytes --]
Hi all,
I'm trying to figure out how I could find all devnodes related to a USB
device. For example, if I attach a usb mass storage device I want to
figure out which /dev/sdXX I'm supposed to use when trying to read/write
to that particular device. Similarly for ACM, Network and all other devices.
Is there any way to achieve that with libudev ? I tried using
udev_device_get_devlinks_list_entry() but that didn't help.
I'm attaching my current code which is a modifed version of a tutorial
from Alan Ott available at [1].
[1] http://www.signal11.us/oss/udev/
--
balbi
[-- Attachment #2: udev.c --]
[-- Type: text/x-c, Size: 1765 bytes --]
#include <libudev.h>
#include <stdio.h>
#include <stdlib.h>
#include <locale.h>
#include <unistd.h>
int main (void)
{
struct udev *udev;
struct udev_enumerate *enumerate;
struct udev_list_entry *devices, *dev_list_entry;
struct udev_device *dev;
/* Create the udev object */
udev = udev_new();
if (!udev) {
printf("Can't create udev\n");
exit(1);
}
/* Create a list of the devices in the 'hidraw' subsystem. */
enumerate = udev_enumerate_new(udev);
udev_enumerate_add_match_subsystem(enumerate, "usb");
udev_enumerate_scan_devices(enumerate);
devices = udev_enumerate_get_list_entry(enumerate);
/* For each item enumerated, print out its information.
* udev_list_entry_foreach is a macro which expands to
* a loop. The loop will be executed for each member in
* devices, setting dev_list_entry to a list entry
* which contains the device's path in /sys. */
udev_list_entry_foreach(dev_list_entry, devices) {
struct udev_list_entry *links, *more_devs;
const char *path;
unsigned count = 0;
/* Get the filename of the /sys entry for the device
* and create a udev_device object (dev) representing it */
path = udev_list_entry_get_name(dev_list_entry);
dev = udev_device_new_from_syspath(udev, path);
links = udev_device_get_devlinks_list_entry(dev);
udev_list_entry_foreach(more_devs, links) {
struct udev_device *other_dev;
const char *path;
printf("dev #%d\n", count);
count++;
path = udev_list_entry_get_name(links);
other_dev = udev_device_new_from_syspath(udev, path);
printf("Device node path: %s\n", udev_device_get_devnode(other_dev));
}
udev_device_unref(dev);
}
/* Free the enumerator object */
udev_enumerate_unref(enumerate);
udev_unref(udev);
return 0;
}
^ permalink raw reply
* Re: [PATCH V4] Export SMBIOS provided firmware instance and label
From: Jesse Barnes @ 2010-07-30 16:36 UTC (permalink / raw)
To: Narendra K
Cc: netdev, linux-hotplug, linux-pci, matt_domsch, charles_rose,
jordan_hargrave, vijay_nijhawan
In-Reply-To: <20100726105650.GA19738@auslistsprd01.us.dell.com>
On Mon, 26 Jul 2010 05:56:50 -0500
Narendra K <Narendra_K@dell.com> wrote:
> Hello,
>
> V3 -> V4:
>
> Updated the contact field in Documentation/ABI directory.
>
> Please consider for inclusion -
>
> From: Narendra K <narendra_k@dell.com>
> Subject: [PATCH] Export SMBIOS provided firmware instance and label to sysfs
>
> This patch exports SMBIOS provided firmware instance and label
> of onboard pci devices to sysfs
>
Applied to linux-next, thanks.
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* RE: [PATCH V4] Export SMBIOS provided firmware instance and label to sysfs
From: Narendra_K @ 2010-07-29 18:58 UTC (permalink / raw)
To: netdev, linux-hotplug, linux-pci
Cc: Matt_Domsch, Charles_Rose, Jordan_Hargrave, Vijay_Nijhawan,
jbarnes
In-Reply-To: <20100726105650.GA19738@auslistsprd01.us.dell.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Narendra K
> Sent: Monday, July 26, 2010 4:27 PM
> To: netdev@vger.kernel.org; linux-hotplug@vger.kernel.org; linux-
> pci@vger.kernel.org
> Cc: Domsch, Matt; Rose, Charles; Hargrave, Jordan; Nijhawan, Vijay
> Subject: [PATCH V4] Export SMBIOS provided firmware instance and label
> to sysfs
>
> Hello,
>
> V3 -> V4:
>
> Updated the contact field in Documentation/ABI directory.
>
> Please consider for inclusion -
>
> From: Narendra K <narendra_k@dell.com>
> Subject: [PATCH] Export SMBIOS provided firmware instance and label to
> sysfs
>
> This patch exports SMBIOS provided firmware instance and label
> of onboard pci devices to sysfs
>
> Signed-off-by: Jordan Hargrave <jordan_hargrave@dell.com>
> Signed-off-by: Narendra K <narendra_k@dell.com>
Jesse,
Please let us know if there are any concerns with this patch. If the
patch is acceptable,
please consider it for inclusion.
With regards,
Narendra K
^ permalink raw reply
* Re: [PATCH 0/9] udevadm sub commands adding short options in usage
From: Kay Sievers @ 2010-07-28 4:57 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100728031004.GB28920@kai-debian>
On Wed, Jul 28, 2010 at 06:48, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Wed, Jul 28, 2010 at 05:10, Yin Kangkai <kangkai.yin@linux.intel.com> wrote:
>> This patchset adds short options in usage, also correct two short
>> options in getopt_long.
>>
>> I can't not figure out the short options, neither from the "udevadm
>> subcommand -h", nor the man pages, except I looking into the code.
>>
>> Hopefully this can be applied. Thanks.
>
> Short options are intentionally not part of the ABI, they are not
> documented on purpose. We only export long options, the short versions
> (besides the very few we had in man pages years ago, and can not
> change) may change without notice.
I've applied the bug fixes.
Thanks,
Kay
^ permalink raw reply
* Re: [PATCH 0/9] udevadm sub commands adding short options in usage
From: Kay Sievers @ 2010-07-28 4:48 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100728031004.GB28920@kai-debian>
On Wed, Jul 28, 2010 at 05:10, Yin Kangkai <kangkai.yin@linux.intel.com> wrote:
> This patchset adds short options in usage, also correct two short
> options in getopt_long.
>
> I can't not figure out the short options, neither from the "udevadm
> subcommand -h", nor the man pages, except I looking into the code.
>
> Hopefully this can be applied. Thanks.
Short options are intentionally not part of the ABI, they are not
documented on purpose. We only export long options, the short versions
(besides the very few we had in man pages years ago, and can not
change) may change without notice.
Kay
^ permalink raw reply
* [PATCH 9/9] udevadm-trigger: fix the short options that require
From: Yin Kangkai @ 2010-07-28 3:18 UTC (permalink / raw)
To: linux-hotplug
From c0a486cfce12f0c8b33e13adfcf2c2289627b169 Mon Sep 17 00:00:00 2001
From: Yin Kangkai <kangkai.yin@intel.com>
Date: Wed, 28 Jul 2010 10:25:33 +0800
Subject: [PATCH 9/9] udevadm-trigger: fix the short options that require argument
Signed-off-by: Yin Kangkai <kangkai.yin@intel.com>
---
udev/udevadm-trigger.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/udev/udevadm-trigger.c b/udev/udevadm-trigger.c
index 0d82606..c752116 100644
--- a/udev/udevadm-trigger.c
+++ b/udev/udevadm-trigger.c
@@ -128,7 +128,7 @@ int udevadm_trigger(struct udev *udev, int argc, char *argv[])
const char *val;
char buf[UTIL_PATH_SIZE];
- option = getopt_long(argc, argv, "vng:o:t:hcp:s:S:a:A:y:", options, NULL);
+ option = getopt_long(argc, argv, "vng:o:t:hc:p:s:S:a:A:y:", options, NULL);
if (option = -1)
break;
--
1.6.5
^ permalink raw reply related
* [PATCH 8/9] udevadm-trigger: add short options in Usage
From: Yin Kangkai @ 2010-07-28 3:17 UTC (permalink / raw)
To: linux-hotplug
From 16c72cce078464ba2f62ecf3297c6d6aae78a1cd Mon Sep 17 00:00:00 2001
From: Yin Kangkai <kangkai.yin@intel.com>
Date: Wed, 28 Jul 2010 10:24:48 +0800
Subject: [PATCH 8/9] udevadm-trigger: add short options in Usage
Signed-off-by: Yin Kangkai <kangkai.yin@intel.com>
---
udev/udevadm-trigger.c | 32 ++++++++++++++++----------------
1 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/udev/udevadm-trigger.c b/udev/udevadm-trigger.c
index 481e9cf..0d82606 100644
--- a/udev/udevadm-trigger.c
+++ b/udev/udevadm-trigger.c
@@ -181,22 +181,22 @@ int udevadm_trigger(struct udev *udev, int argc, char *argv[])
break;
case 'h':
printf("Usage: udevadm trigger OPTIONS\n"
- " --verbose print the list of devices while running\n"
- " --dry-run do not actually trigger the events\n"
- " --type= type of events to trigger\n"
- " devices sys devices (default)\n"
- " subsystems sys subsystems and drivers\n"
- " failed trigger only the events which have been\n"
- " marked as failed during a previous run\n"
- " --action=<action> event action value, default is \"change\"\n"
- " --subsystem-match=<subsystem> trigger devices from a matching subsystem\n"
- " --subsystem-nomatch=<subsystem> exclude devices from a matching subsystem\n"
- " --attr-match=<file[=<value>]> trigger devices with a matching attribute\n"
- " --attr-nomatch=<file[=<value>]> exclude devices with a matching attribute\n"
- " --property-match=<key>=<value> trigger devices with a matching property\n"
- " --tag-match=<key>=<value> trigger devices with a matching property\n"
- " --sysname-match=<name> trigger devices with a matching name\n"
- " --help\n\n");
+ " -v, --verbose print the list of devices while running\n"
+ " -n, --dry-run do not actually trigger the events\n"
+ " -t, --type= type of events to trigger\n"
+ " devices sys devices (default)\n"
+ " subsystems sys subsystems and drivers\n"
+ " failed trigger only the events which have been\n"
+ " marked as failed during a previous run\n"
+ " -c, --action=<action> event action value, default is \"change\"\n"
+ " -s, --subsystem-match=<subsystem> trigger devices from a matching subsystem\n"
+ " -S, --subsystem-nomatch=<subsystem> exclude devices from a matching subsystem\n"
+ " -a, --attr-match=<file[=<value>]> trigger devices with a matching attribute\n"
+ " -A, --attr-nomatch=<file[=<value>]> exclude devices with a matching attribute\n"
+ " -p, --property-match=<key>=<value> trigger devices with a matching property\n"
+ " -g, --tag-match=<key>=<value> trigger devices with a matching property\n"
+ " -y, --sysname-match=<name> trigger devices with a matching name\n"
+ " -h, --help\n\n");
goto exit;
default:
goto exit;
--
1.6.5
^ permalink raw reply related
* [PATCH 7/9] udevadm-settle: add short options in Usage
From: Yin Kangkai @ 2010-07-28 3:16 UTC (permalink / raw)
To: linux-hotplug
From 859a0b8efef10c7de7afb3d6af9110c04b450525 Mon Sep 17 00:00:00 2001
From: Yin Kangkai <kangkai.yin@intel.com>
Date: Wed, 28 Jul 2010 10:16:44 +0800
Subject: [PATCH 7/9] udevadm-settle: add short options in Usage
Signed-off-by: Yin Kangkai <kangkai.yin@intel.com>
---
udev/udevadm-settle.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/udev/udevadm-settle.c b/udev/udevadm-settle.c
index 1423cec..5db0ede 100644
--- a/udev/udevadm-settle.c
+++ b/udev/udevadm-settle.c
@@ -115,12 +115,12 @@ int udevadm_settle(struct udev *udev, int argc, char *argv[])
break;
case 'h':
printf("Usage: udevadm settle OPTIONS\n"
- " --timeout=<seconds> maximum time to wait for events\n"
- " --seq-start=<seqnum> first seqnum to wait for\n"
- " --seq-end=<seqnum> last seqnum to wait for\n"
- " --exit-if-exists=<file> stop waiting if file exists\n"
- " --quiet do not print list after timeout\n"
- " --help\n\n");
+ " -t, --timeout=<seconds> maximum time to wait for events\n"
+ " -s, --seq-start=<seqnum> first seqnum to wait for\n"
+ " -e, --seq-end=<seqnum> last seqnum to wait for\n"
+ " -E, --exit-if-exists=<file> stop waiting if file exists\n"
+ " -q, --quiet do not print list after timeout\n"
+ " -h, --help\n\n");
exit(0);
}
}
--
1.6.5
^ permalink raw reply related
* [PATCH 6/9] udevadm-control: add short options in Usage
From: Yin Kangkai @ 2010-07-28 3:16 UTC (permalink / raw)
To: linux-hotplug
From b0bb14092c150b3a17587b1a69aa1c35e3173e41 Mon Sep 17 00:00:00 2001
From: Yin Kangkai <kangkai.yin@intel.com>
Date: Tue, 27 Jul 2010 16:36:23 +0800
Subject: [PATCH 6/9] udevadm-control: add short options in Usage
Signed-off-by: Yin Kangkai <kangkai.yin@intel.com>
---
udev/udevadm-control.c | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/udev/udevadm-control.c b/udev/udevadm-control.c
index 8b90829..8520b8b 100644
--- a/udev/udevadm-control.c
+++ b/udev/udevadm-control.c
@@ -29,14 +29,14 @@
static void print_help(void)
{
- printf("Usage: udevadm control COMMAND\n"
- " --log-priority=<level> set the udev log level for the daemon\n"
- " --stop-exec-queue keep udevd from executing events, queue only\n"
- " --start-exec-queue execute events, flush queue\n"
- " --reload-rules reloads the rules files\n"
- " --property=<KEY>=<value> set a global property for all events\n"
- " --children-max=<N> maximum number of children\n"
- " --help print this help text\n\n");
+ printf("Usage: udevadm control OPTIONS\n"
+ " -l, --log-priority=<level> set the udev log level for the daemon\n"
+ " -s, --stop-exec-queue keep udevd from executing events, queue only\n"
+ " -S, --start-exec-queue execute events, flush queue\n"
+ " -R, --reload-rules reloads the rules files\n"
+ " -p, --property=<KEY>=<value> set a global property for all events\n"
+ " -m, --children-max=<N> maximum number of children\n"
+ " -h, --help print this help text\n\n");
}
int udevadm_control(struct udev *udev, int argc, char *argv[])
--
1.6.5
^ permalink raw reply related
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