* Re: how to change mac address using udev
From: Sasha Alko @ 2011-10-18 9:49 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAMY8tishW7Dwn4ZMXw5te=3rX0Y+fLaBjuNkjM9ZAEGn-C79rw@mail.gmail.com>
Hi,
Does anybody have an example how to change MAC address using udev?
Kind regards,
S
2011/10/12 Sasha Alko <alkosasha@gmail.com>:
> Hi,
>
> I am trying to change mac address in this way:
>
> subsystem="usb", action="add", attrs{idvendor},
> attr{address}="00:11:22:33:44:55"
>
> But this generates the error "error opening
> ATTR{/sys/deivces/.../net/eth1/address} for writing: Permission denied
>
> I know that NetworkManager is able to change mac address and I guess
> NM uses udev to change mac.
>
> Could you please advice me how to change mac using udev.
>
> Kind regards,
> S
>
^ permalink raw reply
* Re: how to change mac address using udev
From: Kay Sievers @ 2011-10-18 10:59 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAMY8tishW7Dwn4ZMXw5te=3rX0Y+fLaBjuNkjM9ZAEGn-C79rw@mail.gmail.com>
On Tue, Oct 18, 2011 at 11:49, Sasha Alko <alkosasha@gmail.com> wrote:
> Does anybody have an example how to change MAC address using udev?
You can probably set it temporarily with the /sbin/ip tool.
Usually, MAC addresses are part of the hardware, burned into the ROM
of your network card. Udev itself has absolutely no idea about
specific hardware settings.
Kay
^ permalink raw reply
* Re: Samsung 90X3A Fn Keys
From: Greg KH @ 2011-10-18 14:12 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAD6YvxT8M6mR-2HuoetQ9BnowJgVSG2YXBRFhg-t1dAoR9TAyA@mail.gmail.com>
On Tue, Oct 18, 2011 at 09:41:17AM +0200, Victor Engmark wrote:
> On Tue, Oct 18, 2011 at 9:26 AM, Victor Engmark
> <victor.engmark@gmail.com> wrote:
> > On Tue, Oct 18, 2011 at 6:41 AM, Martin Pitt <martin.pitt@ubuntu.com> wrote:
> >> Victor Engmark [2011-10-17 20:55 +0200]:
> >>> > Are you using the proper kernel driver for this laptop (samsung-laptop)
> >>> > that provides the ability to change the backlight levels?
> >>> >
> >>> > If not, the keys themselves are not going to do anything on their own,
> >>> > sorry.
> >>>
> >>> Is there an Ubuntu package for this?
> >>
> >> No need for a package, that module just comes with the standard
> >> kernel. It should autoload as it seems to have proper modaliases
> >> (dmi*:svn*SAMSUNG...). Doesn't it appear in "lsmod | grep samsung"?
> >
> > Nope, nothing there. For reference, I'm running Ubuntu 11.10 64 bit
> > (and was running 11.04 a week ago, with the same problem).
> >
> > $ uname -a
> > Linux lup0 2.6.38-11-generic #50-Ubuntu SMP Mon Sep 12 21:18:14 UTC
> > 2011 i686 i686 i386 GNU/Linux
>
> Correction: Running Ubuntu 11.04 still (won't upgrade to the POS that
> 11.10 is after trying it on the desktop).
Then there's no way your brightness will work, unless your laptop
happens to use ACPI for brightness.
greg k-h
^ permalink raw reply
* Re: how to change mac address using udev
From: Sasha Alko @ 2011-10-18 14:46 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAMY8tishW7Dwn4ZMXw5te=3rX0Y+fLaBjuNkjM9ZAEGn-C79rw@mail.gmail.com>
Yes I can change MAC manually using ifconfig or other tools. But I
would like to change MAC automatically when network device is
attaching. The problem is that I have two RNDIS device which utilize
the same MAC address. The NetworkManager in Ubuntu is able to change
MAC automatically based on original MAC. But it is not the case
because I need to make some checks, e.g. change mac only if first card
is already attached and do not make anything if no card with RNDIS
driver is attached.
Udev is operate with MAC address through ATTRS{address} but I didn't
find how to rewrite this attribute:
error opening ATTR{/sys/devices/.../net/eth1/address} for writing:
Permission denied
It seems to me NetworkManager uses libudev to operate with mac, but I
can't realize how to operate with mac using udev rules.
BR,
Sasha
2011/10/18 Kay Sievers <kay.sievers@vrfy.org>:
> On Tue, Oct 18, 2011 at 11:49, Sasha Alko <alkosasha@gmail.com> wrote:
>> Does anybody have an example how to change MAC address using udev?
>
> You can probably set it temporarily with the /sbin/ip tool.
>
> Usually, MAC addresses are part of the hardware, burned into the ROM
> of your network card. Udev itself has absolutely no idea about
> specific hardware settings.
>
> Kay
>
^ permalink raw reply
* Re: how to change mac address using udev
From: Kay Sievers @ 2011-10-18 16:06 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAMY8tishW7Dwn4ZMXw5te=3rX0Y+fLaBjuNkjM9ZAEGn-C79rw@mail.gmail.com>
On Tue, Oct 18, 2011 at 16:46, Sasha Alko <alkosasha@gmail.com> wrote:
> Yes I can change MAC manually using ifconfig or other tools. But I
> would like to change MAC automatically when network device is
> attaching. The problem is that I have two RNDIS device which utilize
> the same MAC address. The NetworkManager in Ubuntu is able to change
> MAC automatically based on original MAC. But it is not the case
> because I need to make some checks, e.g. change mac only if first card
> is already attached and do not make anything if no card with RNDIS
> driver is attached.
>
> Udev is operate with MAC address through ATTRS{address} but I didn't
> find how to rewrite this attribute:
Most attributes are not writable. But that doesn't mean the underlying
stuff can't be changed with other interfaces. If calling /sbin/ip ....
works, just call it from udev.
> It seems to me NetworkManager uses libudev to operate with mac, but I
> can't realize how to operate with mac using udev rules.
No, udev is not involved in any specifics of network device setups, or
any other device classes. It can just gather data, create symlinks,
adjust permissions or rename network device names, and call tools it
is asked for to run.
Kay
^ permalink raw reply
* Camera does not register properly with udev?
From: Brad Hermanson @ 2011-10-20 1:30 UTC (permalink / raw)
To: linux-hotplug
Hello,
I'm trying to debug an issue with udev not registering my camera
properly on Slackware 13.37. When I run udevadm monitor --property, it
shows this when I plug in and then unplug the camera:
KERNEL[1319073984.353340] add
/devices/pci0000:00/0000:00:13.0/usb5/5-2 (usb)
UDEV_LOG=3
ACTIONd
DEVPATH=/devices/pci0000:00/0000:00:13.0/usb5/5-2
SUBSYSTEM=usb
DEVNAME=bus/usb/005/006
DEVTYPE=usb_device
DEVICE=/proc/bus/usb/005/006
PRODUCT@a/57b/100
TYPE=0/0/0
BUSNUM\05
DEVNUM\06
SEQNUM(47
MAJOR\x189
MINORQ7
KERNEL[1319073984.355239] add
/devices/pci0000:00/0000:00:13.0/usb5/5-2/5-2:1.0 (usb)
UDEV_LOG=3
ACTIONd
DEVPATH=/devices/pci0000:00/0000:00:13.0/usb5/5-2/5-2:1.0
SUBSYSTEM=usb
DEVTYPE=usb_interface
DEVICE=/proc/bus/usb/005/006
PRODUCT@a/57b/100
TYPE=0/0/0
INTERFACE=6/1/1
MODALIAS=usb:v040Ap057Bd0100dc00dsc00dp00ic06isc01ip01
SEQNUM(48
KERNEL[1319073984.355300] add
/devices/pci0000:00/0000:00:13.0/usb5/5-2/usb_device/usbdev5.6 (usb_device)
UDEV_LOG=3
ACTIONd
DEVPATH=/devices/pci0000:00/0000:00:13.0/usb5/5-2/usb_device/usbdev5.6
SUBSYSTEM=usb_device
DEVNAME=usbdev5.6
SEQNUM(49
MAJOR\x189
MINORQ7
UDEV [1319073984.367351] add
/devices/pci0000:00/0000:00:13.0/usb5/5-2 (usb)
UDEV_LOG=3
ACTIONd
DEVPATH=/devices/pci0000:00/0000:00:13.0/usb5/5-2
SUBSYSTEM=usb
DEVNAME=/dev/bus/usb/005/006
DEVTYPE=usb_device
DEVICE=/proc/bus/usb/005/006
PRODUCT@a/57b/100
TYPE=0/0/0
BUSNUM\05
DEVNUM\06
SEQNUM(47
ID_VENDORêstman_Kodak_Company
ID_VENDOR_ENCêstman\x20Kodak\x20Company
ID_VENDOR_ID\x040a
ID_MODEL=KODAK_EasyShare_CX7430_Zoom_Digital_Camera
ID_MODEL_ENC=KODAK\x20EasyShare\x20CX7430\x20Zoom\x20Digital\x20Camera
ID_MODEL_ID\x057b
ID_REVISION\x0100
ID_SERIALêstman_Kodak_Company_KODAK_EasyShare_CX7430_Zoom_Digital_Camera_KCKCY43014629
ID_SERIAL_SHORT=KCKCY43014629
ID_BUS=usb
ID_USB_INTERFACES=:060101:
ID_GPHOTO2=1
GPHOTO2_DRIVER=PTP
MAJOR\x189
MINORQ7
TAGS=:udev-acl:
UDEV [1319073984.372429] add
/devices/pci0000:00/0000:00:13.0/usb5/5-2/5-2:1.0 (usb)
UDEV_LOG=3
ACTIONd
DEVPATH=/devices/pci0000:00/0000:00:13.0/usb5/5-2/5-2:1.0
SUBSYSTEM=usb
DEVTYPE=usb_interface
DEVICE=/proc/bus/usb/005/006
PRODUCT@a/57b/100
TYPE=0/0/0
INTERFACE=6/1/1
MODALIAS=usb:v040Ap057Bd0100dc00dsc00dp00ic06isc01ip01
SEQNUM(48
UDEV [1319073984.379762] add
/devices/pci0000:00/0000:00:13.0/usb5/5-2/usb_device/usbdev5.6 (usb_device)
UDEV_LOG=3
ACTIONd
DEVPATH=/devices/pci0000:00/0000:00:13.0/usb5/5-2/usb_device/usbdev5.6
SUBSYSTEM=usb_device
DEVNAME=/dev/usbdev5.6
SEQNUM(49
MAJOR\x189
MINORQ7
KERNEL[1319073988.760514] remove
/devices/pci0000:00/0000:00:13.0/usb5/5-2/5-2:1.0 (usb)
UDEV_LOG=3
ACTION=remove
DEVPATH=/devices/pci0000:00/0000:00:13.0/usb5/5-2/5-2:1.0
SUBSYSTEM=usb
DEVTYPE=usb_interface
DEVICE=/proc/bus/usb/005/006
PRODUCT@a/57b/100
TYPE=0/0/0
INTERFACE=6/1/1
MODALIAS=usb:v040Ap057Bd0100dc00dsc00dp00ic06isc01ip01
SEQNUM(50
KERNEL[1319073988.760603] remove
/devices/pci0000:00/0000:00:13.0/usb5/5-2/usb_device/usbdev5.6 (usb_device)
UDEV_LOG=3
ACTION=remove
DEVPATH=/devices/pci0000:00/0000:00:13.0/usb5/5-2/usb_device/usbdev5.6
SUBSYSTEM=usb_device
DEVNAME=usbdev5.6
SEQNUM(51
MAJOR\x189
MINORQ7
KERNEL[1319073988.760624] remove
/devices/pci0000:00/0000:00:13.0/usb5/5-2 (usb)
UDEV_LOG=3
ACTION=remove
DEVPATH=/devices/pci0000:00/0000:00:13.0/usb5/5-2
SUBSYSTEM=usb
DEVNAME=bus/usb/005/006
DEVTYPE=usb_device
DEVICE=/proc/bus/usb/005/006
PRODUCT@a/57b/100
TYPE=0/0/0
BUSNUM\05
DEVNUM\06
SEQNUM(52
MAJOR\x189
MINORQ7
UDEV [1319073988.760792] remove
/devices/pci0000:00/0000:00:13.0/usb5/5-2/5-2:1.0 (usb)
UDEV_LOG=3
ACTION=remove
DEVPATH=/devices/pci0000:00/0000:00:13.0/usb5/5-2/5-2:1.0
SUBSYSTEM=usb
DEVTYPE=usb_interface
DEVICE=/proc/bus/usb/005/006
PRODUCT@a/57b/100
TYPE=0/0/0
INTERFACE=6/1/1
MODALIAS=usb:v040Ap057Bd0100dc00dsc00dp00ic06isc01ip01
SEQNUM(50
UDEV [1319073988.766314] remove
/devices/pci0000:00/0000:00:13.0/usb5/5-2/usb_device/usbdev5.6 (usb_device)
UDEV_LOG=3
ACTION=remove
DEVPATH=/devices/pci0000:00/0000:00:13.0/usb5/5-2/usb_device/usbdev5.6
SUBSYSTEM=usb_device
DEVNAME=/dev/usbdev5.6
SEQNUM(51
MAJOR\x189
MINORQ7
UDEV [1319073988.772662] remove
/devices/pci0000:00/0000:00:13.0/usb5/5-2 (usb)
UDEV_LOG=3
ACTION=remove
DEVPATH=/devices/pci0000:00/0000:00:13.0/usb5/5-2
SUBSYSTEM=usb
DEVNAME=/dev/bus/usb/005/006
DEVTYPE=usb_device
DEVICE=/proc/bus/usb/005/006
PRODUCT@a/57b/100
TYPE=0/0/0
BUSNUM\05
DEVNUM\06
SEQNUM(52
MAJOR\x189
MINORQ7
The fourth entry is the one that is the most descriptive and is the one
I want (I'm trying to get my camera working with Shotwell--a photo
manager). However, Shotwell's call to gudev never returns this device,
and I'm starting to suspect it's a problem with the way udev is set up.
When I unplug the camera, that same device (that has ID_VENDOR,
ID_GPHOTO2 and GPHOTO2_DRIVER) is not listed. However, there are 6
devices added and 6 removed, yet none of the ones removed have ID_VENDOR
set, etc. On Ubuntu, unplugging the camera, shows the same device when
it's removed, so I'm guessing it's something Slackware is doing with
udev. It's almost like it's clearing out ID_VENDOR and so right after
it's added..? This is way out of my comfort zone, so forgive me if some
of what I say doesn't make sense... but any ideas what could be causing
this?
Thank you,
Brad
^ permalink raw reply
* Re: [PATCH] Add mic mute keycode support for Lenovo Thinkpad USB
From: Martin Pitt @ 2011-10-20 5:49 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1318474465.3813.20.camel@Thinkpad-420s>
Hello Jerone,
Jerone Young [2011-10-12 22:31 -0500]:
> This patch adds mic mute keycode support for the Lenovo Thinkpad USB
> keyboard. Support for this keycode was introduced upstream, and will be
> defined in upcoming 3.1 Linux Kernel input.h header. See change set
> below:
Thanks! Applied.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* Re: Camera does not register properly with udev?
From: Brad Hermanson @ 2011-10-21 5:28 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4E9F799D.5040307@gmail.com>
I now think it's a problem with gvfs-gphoto2-volume-monitor not taking
control of the device, so nevermind. :) GVFS doesn't come standard with
Slackware, so something's not configured properly.
^ permalink raw reply
* make check
From: William Hubbs @ 2011-10-21 22:01 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 109 bytes --]
All,
is "make check" meant to be run on release tarballs, or just in the git
repository?
Thanks,
William
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: make check
From: Martin Pitt @ 2011-10-22 15:29 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20111021220133.GA8417@linux1>
[-- Attachment #1: Type: text/plain, Size: 353 bytes --]
William Hubbs [2011-10-21 17:01 -0500]:
> is "make check" meant to be run on release tarballs, or just in the git
> repository?
It's meant to work on both. That's what 'make distcheck' verifies, too.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: make check
From: Kay Sievers @ 2011-10-22 20:58 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20111021220133.GA8417@linux1>
On Sat, Oct 22, 2011 at 17:29, Martin Pitt <martin.pitt@ubuntu.com> wrote:
> William Hubbs [2011-10-21 17:01 -0500]:
>> is "make check" meant to be run on release tarballs, or just in the git
>> repository?
>
> It's meant to work on both. That's what 'make distcheck' verifies, too.
Seems the (huge) sysfs test tree is not packaged into the tarball. So
they work only in the git tree today.
These tests need to run as root (for mknod()), and are ignore if 'make
check' is called as non-root, that's why it's not fatal or visible in
the usual case or during make distcheck.
Kay
^ permalink raw reply
* Re: Samsung 90X3A Fn Keys
From: Tomasz Chmielewski @ 2011-10-24 17:20 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAD6YvxT8M6mR-2HuoetQ9BnowJgVSG2YXBRFhg-t1dAoR9TAyA@mail.gmail.com>
>> >> No need for a package, that module just comes with the standard
>> >> kernel. It should autoload as it seems to have proper modaliases
>> >> (dmi*:svn*SAMSUNG...). Doesn't it appear in "lsmod | grep samsung"?
>> >
>> > Nope, nothing there. For reference, I'm running Ubuntu 11.10 64 bit
>> > (and was running 11.04 a week ago, with the same problem).
>> >
>> > $ uname -a
>> > Linux lup0 2.6.38-11-generic #50-Ubuntu SMP Mon Sep 12 21:18:14 UTC
>> > 2011 i686 i686 i386 GNU/Linux
>>
>> Correction: Running Ubuntu 11.04 still (won't upgrade to the POS that
>> 11.10 is after trying it on the desktop).
>
> Then there's no way your brightness will work, unless your laptop
> happens to use ACPI for brightness.
FYI, it looks like samsung-laptop module doesn't like this Samsung laptop, even on the newest kernel (3.1.0):
root@s9:~# modprobe samsung-laptop
FATAL: Error inserting samsung_laptop (/lib/modules/3.1.0-030100-generic/kernel/drivers/platform/x86/samsung-laptop.ko): No such device
BIOS Information
Vendor: Phoenix Technologies Ltd.
Version: 07HL
Release Date: 09/26/2011
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: SAMSUNG ELECTRONICS CO., LTD.
Product Name: 90X3A
Version: 0.1
Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
Manufacturer: SAMSUNG ELECTRONICS CO., LTD.
Product Name: 90X3A
Version: FAB1
--
Tomasz Chmielewski
http://wpkg.org
^ permalink raw reply
* [PATCH] Fix micmute remap for Lenovo Thinkpads
From: Jerone Young @ 2011-10-25 5:22 UTC (permalink / raw)
To: linux-hotplug
Micmute keypress coming from Thinkpads via thinkpad-acpi are being
remapped to prog2 via udev.
Linux Kernel 3.1 now has proper support for a mic mute button:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h3009557bd
This patch resolves the issue.
Signed-off-by: Jerone Young <jyoung@redhat.com>
diff --git a/extras/keymap/keymaps/module-lenovo b/extras/keymap/keymaps/module-lenovo
index 81b8fea..8e38883 100644
--- a/extras/keymap/keymaps/module-lenovo
+++ b/extras/keymap/keymaps/module-lenovo
@@ -14,4 +14,4 @@
0x15 volumedown
0x16 mute
0x17 prog1 # ThinkPad/ThinkVantage button (high keycode: "vendor")
-0x1A prog2 # Microphone mute
+0x1A micmute # Microphone mute
^ permalink raw reply related
* findkeyboards - no device node found
From: John Serock @ 2011-10-25 23:09 UTC (permalink / raw)
To: linux-hotplug
I could use some help troubleshooting findkeyboards. It is not finding
my keyboard. I'm not sure if the issue is in the findkeyboards script
or if it is something else. Once the findkeyboards script failed, I
tried manually running the udevadm commands it uses. Here is what I am
seeing:
/lib/udev$ udevadm info --version
173
/lib/udev$ ./findkeyboards
AT keyboard: no device node found
/lib/udev$ echo $?
5
/lib/udev$ udevadm trigger --dry-run --verbose
--property-match=ID_INPUT_KEYBOARD=1
/sys/devices/platform/i8042/serio0/input/input4
/sys/devices/platform/i8042/serio0/input/input4/event4
/lib/udev$ udevadm info --query=name
--path=/sys/devices/platform/i8042/serio0/input/input4/
no device node found
/lib/udev$ udevadm info --query=name
--path=/sys/devices/platform/i8042/serio0/input/input4/event4/
input/event4
It looks like the findkeyboards script can't find the device node for
the first (input4) device, which causes the script to exit with status
5 before it checks the second (event4) device. I'm not sure whether
the input4 device should have a device node or not. Any
troubleshooting help would be appreciated.
Thanks.
^ permalink raw reply
* Re: [PATCH] Fix micmute remap for Lenovo Thinkpads
From: Martin Pitt @ 2011-10-26 5:40 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1319520150.9818.8.camel@Thinkpad-420s>
Hello Jerone,
Jerone Young [2011-10-25 0:22 -0500]:
> Micmute keypress coming from Thinkpads via thinkpad-acpi are being
> remapped to prog2 via udev.
>
> Linux Kernel 3.1 now has proper support for a mic mute button:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h3009557bd
Thanks, applied. This will cause "make distcheck" to fail on older
kernels, though, as KEY_MICMUTE does not exist there yet. But that
shouldn't hurt too much, I think.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* Re: findkeyboards - no device node found
From: Martin Pitt @ 2011-10-26 9:06 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAPjEYUK88gT=QDQAvObmdVcy1ERvL5AF5+mdtMsczKujotOTDA@mail.gmail.com>
Hello John,
John Serock [2011-10-25 19:09 -0400]:
> I could use some help troubleshooting findkeyboards. It is not finding
> my keyboard. I'm not sure if the issue is in the findkeyboards script
> or if it is something else. Once the findkeyboards script failed, I
> tried manually running the udevadm commands it uses. Here is what I am
> seeing:
What a weird coincidence, I also used findkeyboards again this morning
because I got a PM for a keymap fix, and noticed the very same
problem. I'm not sure when this got broken, or whether it's due to a
kernel or udev change, but this fixes it:
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;häb7a9be03441db21d459cbb9c08400377c3556d
Thanks,
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
--
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
* In regard of commit "gudev: Use strtoul to parse unsigned 64-bit
From: Rafał Mużyło @ 2011-10-31 20:13 UTC (permalink / raw)
To: linux-hotplug
Perhaps I'm simply misreading something, but won't going from strtoll to
strtoul break things for 32bit case ?
I do understand, that 32bit is becoming less and less supported every
day (given i.e. "daemon.c:1351:33: warning: cast to pointer from integer
of different size" warning during udisks 1.0.4 build - bug 24983), but
should it be broken on purpose ?
^ permalink raw reply
* Re: In regard of commit "gudev: Use strtoul to parse unsigned 64-bit integers"
From: David Zeuthen @ 2011-10-31 20:32 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20111031201318.GA2447@blackspire>
On Mon, Oct 31, 2011 at 4:13 PM, Rafał Mużyło <galtgendo@gmail.com> wrote:
> Perhaps I'm simply misreading something, but won't going from strtoll to
> strtoul break things for 32bit case ?
What do you think it would break? Or are you perhaps suggesting we
should be using strtoull() instead? Please be specific.
David
^ permalink raw reply
* Re: In regard of commit "gudev: Use strtoul to parse unsigned 64-bit integers"
From: David Zeuthen @ 2011-10-31 20:44 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20111031201318.GA2447@blackspire>
[-- Attachment #1: Type: text/plain, Size: 675 bytes --]
Hi,
I looked more into this and we should probably just use
g_ascii_strtoull() since that function always returns a guint64 no
matter whether you are on 32- or 64-bit. The attached patch does this.
Kay: please apply.
Thanks,
David
On Mon, Oct 31, 2011 at 4:32 PM, David Zeuthen <zeuthen@gmail.com> wrote:
> On Mon, Oct 31, 2011 at 4:13 PM, Rafał Mużyło <galtgendo@gmail.com> wrote:
>> Perhaps I'm simply misreading something, but won't going from strtoll to
>> strtoul break things for 32bit case ?
>
> What do you think it would break? Or are you perhaps suggesting we
> should be using strtoull() instead? Please be specific.
>
>
> David
>
[-- Attachment #2: 0001-gudev-Use-g_ascii_strtoull-instead-of-strtoul.patch --]
[-- Type: text/x-patch, Size: 1770 bytes --]
From 2a64773ac80432ca70aa747b55cfaadf3f8c55cb Mon Sep 17 00:00:00 2001
From: David Zeuthen <davidz@redhat.com>
Date: Mon, 31 Oct 2011 16:38:14 -0400
Subject: [PATCH] gudev: Use g_ascii_strtoull() instead of strtoul()
This ensures that we get the same behavior on both 32- and
64-bit. Pointed out on the mailing list:
http://permalink.gmane.org/gmane.linux.hotplug.devel/17145
Signed-off-by: David Zeuthen <davidz@redhat.com>
---
| 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
--git a/extras/gudev/gudevdevice.c b/extras/gudev/gudevdevice.c
index e77b34b..38d602c 100644
--- a/extras/gudev/gudevdevice.c
+++ b/extras/gudev/gudevdevice.c
@@ -538,7 +538,7 @@ out:
* @key: Name of property.
*
* Look up the value for @key on @device and convert it to an unsigned
- * 64-bit integer using strtoul().
+ * 64-bit integer using g_ascii_strtoull().
*
* Returns: The value for @key or 0 if @key doesn't exist or isn't a
* #guint64.
@@ -558,7 +558,7 @@ g_udev_device_get_property_as_uint64 (GUdevDevice *device,
if (s == NULL)
goto out;
- result = strtoul (s, NULL, 0);
+ result = g_ascii_strtoull (s, NULL, 0);
out:
return result;
}
@@ -756,7 +756,7 @@ out:
* @name: Name of the sysfs attribute.
*
* Look up the sysfs attribute with @name on @device and convert it to an unsigned
- * 64-bit integer using strtoul().
+ * 64-bit integer using g_ascii_strtoull().
*
* Returns: The value of the sysfs attribute or 0 if there is no such
* attribute.
@@ -776,7 +776,7 @@ g_udev_device_get_sysfs_attr_as_uint64 (GUdevDevice *device,
if (s == NULL)
goto out;
- result = strtoul (s, NULL, 0);
+ result = g_ascii_strtoull (s, NULL, 0);
out:
return result;
}
--
1.7.6.4
^ permalink raw reply related
* Re: In regard of commit "gudev: Use strtoul to parse unsigned 64-bit
From: Rafał Mużyło @ 2011-10-31 21:04 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20111031201318.GA2447@blackspire>
On Mon, Oct 31, 2011 at 04:32:07PM -0400, David Zeuthen wrote:
> On Mon, Oct 31, 2011 at 4:13 PM, Rafał Mużyło <galtgendo@gmail.com> wrote:
> > Perhaps I'm simply misreading something, but won't going from strtoll to
> > strtoul break things for 32bit case ?
>
> What do you think it would break? Or are you perhaps suggesting we
> should be using strtoull() instead? Please be specific.
>
Well, given on what happens on strtoul overflow according to the
manpage...
But, as you're the main author of udisks, would you mind looking at the
bug I've mentioned ?
Perhaps it doesn't matter there, but it would be good to do something
about the warnings.
^ permalink raw reply
* Re: In regard of commit "gudev: Use strtoul to parse unsigned 64-bit integers"
From: David Zeuthen @ 2011-10-31 21:18 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20111031201318.GA2447@blackspire>
On Mon, Oct 31, 2011 at 5:04 PM, Rafał Mużyło <galtgendo@gmail.com> wrote:
> On Mon, Oct 31, 2011 at 04:32:07PM -0400, David Zeuthen wrote:
>> On Mon, Oct 31, 2011 at 4:13 PM, Rafał Mużyło <galtgendo@gmail.com> wrote:
>> > Perhaps I'm simply misreading something, but won't going from strtoll to
>> > strtoul break things for 32bit case ?
>>
>> What do you think it would break? Or are you perhaps suggesting we
>> should be using strtoull() instead? Please be specific.
>>
> Well, given on what happens on strtoul overflow according to the
> manpage...
Well, the problem was simply that I just missed an 'l' in the initial
patch and that mistake breaks 32-bit as you tried to point out. The
patch I just sent fixes the problem. Sigh, this is what happens when
people try to make their function names as short as possible... never
a good idea.
David
^ permalink raw reply
* Re: In regard of commit "gudev: Use strtoul to parse unsigned 64-bit integers"
From: Kay Sievers @ 2011-10-31 21:22 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20111031201318.GA2447@blackspire>
On Mon, Oct 31, 2011 at 21:44, David Zeuthen <zeuthen@gmail.com> wrote:
> I looked more into this and we should probably just use
> g_ascii_strtoull() since that function always returns a guint64 no
> matter whether you are on 32- or 64-bit. The attached patch does this.
> Kay: please apply.
Done.
Thanks,
Kay
^ permalink raw reply
* kernel.org udev tarballs
From: @ 2011-11-02 14:05 UTC (permalink / raw)
To: linux-hotplug
Hi all,
Does anyone know if the udev tarballs will be put back on
http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev/
or should we rely only on git snapshots from now on?
Thanks in advance.
Best regards,
Benoî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
* Re: kernel.org udev tarballs
From: Greg KH @ 2011-11-02 14:35 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <7a04ec9f-f4d4-4214-b408-8419ed2125d1@zose-store-12>
On Wed, Nov 02, 2011 at 03:05:52PM +0100, Benoît THÉBAUDEAU wrote:
> Hi all,
>
> Does anyone know if the udev tarballs will be put back on
> http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev/
> or should we rely only on git snapshots from now on?
They will be put back there, please give us time.
greg k-h
^ permalink raw reply
* Re: kernel.org udev tarballs
From: Kay Sievers @ 2011-11-02 14:46 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <7a04ec9f-f4d4-4214-b408-8419ed2125d1@zose-store-12>
2011/11/2 Greg KH <greg@kroah.com>:
> On Wed, Nov 02, 2011 at 03:05:52PM +0100, Benoît THÉBAUDEAU wrote:
>> Does anyone know if the udev tarballs will be put back on
>> http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev/
The current release is just here:
http://people.freedesktop.org/~kay/
>> or should we rely only on git snapshots from now on?
You can always just check out a git tag and do:
./autogen
make
make distcheck
to get any tarball you need.
> They will be put back there, please give us time.
Not sure if all the old release tarballs will ever come back to kernel
org. Git is the better archive for that anyway.
The new releases will be there for sure when the infrastructure is
ready. In the meantime, you can just get old releases from any of the
distros archives who stored them in their build systems with proper
checksums.
Kay
^ 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