Linux Hotplug development
 help / color / mirror / Atom feed
* udev runtime data will move from /dev/.udev/ to /dev/.run/udev/
From: Kay Sievers @ 2011-03-15 17:25 UTC (permalink / raw)
  To: linux-hotplug

Just a heads-up, because some tools like to "look into" /dev/.udev/.
With udev 167 there will be no /dev/.udev/ directory anymore.

The maintainers of the commonly used early-boot tools agreed to use a
/dev/.run/<package>/ dir instead, which will be provided by initramfs
and systemd. After the basic bootup, the /dev/.run/ tmpfs mountpoint
will be available at /var/run/. The /dev/.run/ directory is at that
point just an "early-boot alias" for /var/run/, and all early-boot
tools will have their data in /var/run/, just like any other service.
In the end, there should be no custom .-dirs left in /dev, besides
this "alias".

The command 'udevadm info --convert-db' is also gone. The udev daemon
converts any old database if needed on startup:
  [    3.708616] systemd-fsck[344]: Root directory is writable, skipping check.
  [    3.796452] udev[359]: converting old udev database
  [    3.856218] udev[359]: starting version 167

The udev source change is here:
  http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h_59fa0900a5c127ce1a25d8ba3176f166662f96

If you support LVM, please make sure to conflict udev if neccessary
with older initramfs implementations, so that no new udev gets into an
old initramfs image, udev puts the data in /dev/.run/ which isn't its
own mountpoint, and the real root would overmount the udev directory.

Thanks,
Kay

^ permalink raw reply
* Re: kernel 2.6.38 has no linux/videodev.h
From: Martin Pitt @ 2011-03-15 11:03 UTC (permalink / raw)
  To: linux-hotplug
In-Reply-To: <AANLkTimKDYegZyghz1C0PhXsVSE=dXUd-qx_kHYuh2Ej@mail.gmail.com>

Hello xinglp,

This was already fixed a while ago:

  http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;hJce8a43ac2cbbd4d6f5c29fc461c3caa8f8545b

(and some followup cleanups)

Martin
-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

^ permalink raw reply
* kernel 2.6.38 has no linux/videodev.h
From: xinglp @ 2011-03-15 10:31 UTC (permalink / raw)
  To: linux-hotplug

[-- Attachment #1: Type: text/plain, Size: 36 bytes --]

-- 
code farmer from lanxiangjixiao

[-- Attachment #2: udev-166-disable-v4l.patch --]
[-- Type: application/octet-stream, Size: 1004 bytes --]

diff -Naurz udev-166.orig/extras/v4l_id/v4l_id.c udev-166/extras/v4l_id/v4l_id.c
--- udev-166.orig/extras/v4l_id/v4l_id.c
+++ udev-166/extras/v4l_id/v4l_id.c
@@ -28,7 +28,7 @@
 #include <sys/types.h>
 #include <sys/time.h>
 #include <sys/ioctl.h>
-#include <linux/videodev.h>
+//#include <linux/videodev.h>
 #include <linux/videodev2.h>
 
 int main (int argc, char *argv[])
@@ -39,7 +39,7 @@
 	};
 	int fd;
 	char *device;
-	struct video_capability v1cap;
+//	struct video_capability v1cap;
 	struct v4l2_capability v2cap;
 
 	while (1) {
@@ -82,7 +82,7 @@
 		if ((v2cap.capabilities & V4L2_CAP_RADIO) > 0)
 			printf("radio:");
 		printf("\n");
-	} else if (ioctl (fd, VIDIOCGCAP, &v1cap) == 0) {
+	}/* else if (ioctl (fd, VIDIOCGCAP, &v1cap) == 0) {
 		printf("ID_V4L_VERSION=1\n");
 		printf("ID_V4L_PRODUCT=%s\n", v1cap.name);
 		printf("ID_V4L_CAPABILITIES=:");
@@ -95,7 +95,7 @@
 		if ((v1cap.type & VID_TYPE_TUNER) > 0)
 			printf("tuner:");
 		printf("\n");
-	}
+	}*/
 
 	close (fd);
 	return 0;

^ permalink raw reply
* Re: [PATCH] add ACLs to /dev/sgX nodes for CD-ROM
From: Karl O. Pinc @ 2011-03-14 23:20 UTC (permalink / raw)
  To: linux-hotplug
In-Reply-To: <1299402082-4796-1-git-send-email-arvidjaar@mail.ru>

On 03/14/2011 11:41:09 AM, Kay Sievers wrote:
> On Mon, Mar 14, 2011 at 17:33, Harald Hoyer <harald@redhat.com> 
> > Oh! You don't want to do this... Won't this allow ordinary users to
> flash a new
> > firmware, opening some security issues here?

> Do we really don't want that? Locally logged-in users could put glue
> in the tray too. :)

Has this been thought through?

Glue in the tray is a simple denial of service attack,
and one that affects but a single system component.
Flashing firmware, in theory at least, opens the door to 
installing malware right into the firmware and enables
all sorts of ugly possibilities starting with malware that
runs before the boot process even gets going,
can't be detected by scanning the drive, and can't be removed by
wiping the hard drive and power cycling.   It sounds scary if
an ordinary user, especially one not sitting next to
the box, can install such malware without any other
sort of privilege escalation.


Karl <kop@meme.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein


^ permalink raw reply
* Re: [PATCH] add ACLs to /dev/sgX nodes for CD-ROM
From: Kay Sievers @ 2011-03-14 16:41 UTC (permalink / raw)
  To: linux-hotplug
In-Reply-To: <1299402082-4796-1-git-send-email-arvidjaar@mail.ru>

On Mon, Mar 14, 2011 at 17:33, Harald Hoyer <harald@redhat.com> wrote:
> Am 07.03.2011 16:23, schrieb Kay Sievers:
>> On Sun, Mar 6, 2011 at 10:01, Andrey Borzenkov <arvidjaar@mail.ru> wrote:
>>> Current wine is using /dev/sgX to access CD-ROM devices. Since
>>> distributions switched to using ACL instead of group membership
>>> to control device access, wine is not able to access them.
>>>
>>> Add ACL to device nodes that already get GROUP="cdrom".

> Oh! You don't want to do this... Won't this allow ordinary users to flash a new
> firmware, opening some security issues here?
> Wasn't this, why cdrecord needed to be suid back in those days?
> Wasn't this the reason for the filter for /dev/sr* in the kernel?

Do we really don't want that? Locally logged-in users could put glue
in the tray too. :)

Kay

^ permalink raw reply
* Re: [PATCH] add ACLs to /dev/sgX nodes for CD-ROM
From: Harald Hoyer @ 2011-03-14 16:33 UTC (permalink / raw)
  To: linux-hotplug
In-Reply-To: <1299402082-4796-1-git-send-email-arvidjaar@mail.ru>

Am 07.03.2011 16:23, schrieb Kay Sievers:
> On Sun, Mar 6, 2011 at 10:01, Andrey Borzenkov <arvidjaar@mail.ru> wrote:
>> Current wine is using /dev/sgX to access CD-ROM devices. Since
>> distributions switched to using ACL instead of group membership
>> to control device access, wine is not able to access them.
>>
>> Add ACL to device nodes that already get GROUP="cdrom".
> 
> Applied.
> 
> Thanks,
> Kay

Oh! You don't want to do this... Won't this allow ordinary users to flash a new
firmware, opening some security issues here?
Wasn't this, why cdrecord needed to be suid back in those days?
Wasn't this the reason for the filter for /dev/sr* in the kernel?

^ permalink raw reply
* Bug 30972 - BenQ nScreen i221
From: njin @ 2011-03-13  8:32 UTC (permalink / raw)
  To: linux-hotplug

Hello here i copy the report closed as won't fix:

I installed Ubuntu 10.04 on BenQ nScreen i221, and most work well,
however,
when turn the volume control located in the lower right corner of the
monitor
is to suspend almost all of the panels. can't expand any menu and can't
enter
any data. blinking cursor and the mouse works, but writing is
impossible.

Pressing CTRL + ALT + F1 and then CTRL + ALT + F7 helps, but I don't
want to do
this every time.

*************************************************************************
Michael Grishin reply on Launchpad:
I managed to fix this with a patch to
linux-2.6.32/drivers/input/keyboard/atkbd.c as below:

--- atkbd.c_original 2010-07-11 11:08:31.748769000 +0200
+++ atkbd.c 2010-07-11 11:10:22.758768325 +0200
@@ -1603,6 +1603,15 @@
                .callback = atkbd_setup_forced_release,
                .driver_data = atkbd_hp_forced_release_keys,
        },
+ {
+ .ident = "BenQ nScreen e221",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "BenQ"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "nScreen"),
+ },
+ .callback = atkbd_setup_forced_release,
+ .driver_data = atkbd_volume_forced_release_keys,
+ },
        {
                .ident = "HP Pavilion ZV6100",
                .matches = {

You will need to recompile kernel image
(https://help.ubuntu.com/community/Kernel/Compile)
Tested with linux-image-2.6.35-24-generic_2.6.35-24.42_amd64

*************************************************************

Comment #1 From Dmitry Torokhov 2011-03-13 04:44:41 (-) [reply]

The force-release quirk should be applied via UDEV which now has needed
facilities, see /lib/udev/rules.d/95-keyboard-force-release.rules

If you could also report this issue to udev maintainers that would be
great.


Links:
https://bugzilla.kernel.org/show_bug.cgi?id0972
https://bugs.launchpad.net/ubuntu/+source/udev/+bug/606599

Thanks
Fabio



^ permalink raw reply
* RE: [PATCH V4] Export ACPI _DSM provided firmware instance number
From: Shyam_Iyer @ 2011-03-10 22:17 UTC (permalink / raw)
  To: Narendra_K, greg
  Cc: a.beregalov, linux-next, jbarnes, linux-pci, linux-hotplug,
	netdev, mjg, Matt_Domsch, Charles_Rose, Jordan_Hargrave, sfr
In-Reply-To: <20110307211552.GA11016@fedora14-r610.oslab.blr.amer.dell.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 3422 bytes --]


> -----Original Message-----
> From: K, Narendra
> Sent: Monday, March 07, 2011 3:56 PM
> To: Greg KH
> Cc: a.beregalov@gmail.com; linux-next@vger.kernel.org;
> jbarnes@virtuousgeek.org; linux-pci@vger.kernel.org; linux-
> hotplug@vger.kernel.org; netdev@vger.kernel.org; mjg@redhat.com;
> Domsch, Matt; Rose, Charles; Hargrave, Jordan; Iyer, Shyam;
> sfr@canb.auug.org.au
> Subject: Re: [PATCH V4] Export ACPI _DSM provided firmware instance
> number and string name to sysfs
> 
> On Tue, Mar 08, 2011 at 01:26:16AM +0530, Greg KH wrote:
> > On Mon, Mar 07, 2011 at 11:44:52AM -0800, Narendra_K@Dell.com wrote:
> > > --- a/drivers/pci/pci-label.c
> > > +++ b/drivers/pci/pci-label.c
> > > @@ -29,7 +29,9 @@
> > >  #include <linux/nls.h>
> > >  #include <linux/acpi.h>
> > >  #include <linux/pci-acpi.h>
> > > +#ifdef CONFIG_ACPI
> > >  #include <acpi/acpi_drivers.h>
> > > +#endif
> >
> > You should never need a #ifdef in a .c file for an include file.  If
> so,
> > something is really wrong.
> 
> I agree. Also, i realized that the include was not required to address
> the
> reported error. Please find the revised patch here.
> 
> From: Narendra K <narendra_k@dell.com>
> Subject: [PATCH] Fix compilation error when CONFIG_ACPI is unset
> 
> This patch fixes compilation error descibed below introduced by
> the commit 6058989bad05b82e78baacce69ec14f27a11b5fd
> 
> drivers/pci/pci-label.c: In function ‘pci_create_firmware_label_files’:
> drivers/pci/pci-label.c:366:2: error: implicit declaration of function
> ‘device_has_dsm’
> 
> Signed-off-by: Narendra K <narendra_k@dell.com>
> ---
>  drivers/pci/pci-label.c |    6 ++++++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/pci/pci-label.c b/drivers/pci/pci-label.c
> index 824e247..8c80138 100644
> --- a/drivers/pci/pci-label.c
> +++ b/drivers/pci/pci-label.c
> @@ -174,6 +174,12 @@ pci_remove_acpi_index_label_files(struct pci_dev
> *pdev)
>  	return -1;
>  }
> 
> +static inline bool
> +device_has_dsm(struct device *dev)
> +{
> +	return false;
> +}
> +
>  #else
> 
>  static const char device_label_dsm_uuid[] = {
> --
> 1.7.3.1
> 
> With regards,
> Narendra K

So this works and fixes the additional build failure.

I tested with CONFIG_ACPI set/unset and with "make allmodconfig"

Additionally I found that including acpi/apci_drivers.h is not necessary and introduces these warnings..

The below patch fixes the additional warnigs..

In file included from drivers/pci/pci-label.c:32:
include/acpi/acpi_drivers.h:103: warning: ‘struct acpi_device’ declared inside parameter list
include/acpi/acpi_drivers.h:103: warning: its scope is only this definition or declaration, which is probably not what you want
include/acpi/acpi_drivers.h:107: warning: ‘struct acpi_pci_root’ declared inside parameter list

Signed-off-by: Shyam Iyer <shyam_iyer@dell.com>
---
 drivers/pci/pci-label.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/pci/pci-label.c b/drivers/pci/pci-label.c
index bf4ebee..488b0ce 100644
--- a/drivers/pci/pci-label.c
+++ b/drivers/pci/pci-label.c
@@ -29,7 +29,6 @@
 #include <linux/nls.h>
 #include <linux/acpi.h>
 #include <linux/pci-acpi.h>
-#include <acpi/acpi_drivers.h>
 #include <acpi/acpi_bus.h>
 #include "pci.h"

-- 
1.7.1
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þ\x1a-¦[ þ)í…æèw*\x1fjg¬±¨\x1e¶‰šŽŠÝ¢jÿ¾\a«þG«éÿ¢¸\f¢·¦j:+v‰¨ŠwèjØm¶Ÿÿþø\x1e¯ù\x1e®w¥þŠàþf£¢·hšâúÿ†Ù¥

^ permalink raw reply related
* Re: [PATCH] Remap MSI Laptop touchpad on/off key to F22 and F23
From: Martin Pitt @ 2011-03-10  7:59 UTC (permalink / raw)
  To: linux-hotplug
In-Reply-To: <1299723432-15709-1-git-send-email-jlee@novell.com>

[-- Attachment #1: Type: text/plain, Size: 1330 bytes --]

Hello Lee,

Lee, Chun-Yi [2011-03-10 10:17 +0800]:
> MSI Laptop driver will query the real touchpad state then emit
> KEY_TOUCHPAD_ON/OFF key.
> 
> Currently, X has defined F22 for touchpad on and F23 for touchpad
> off. This patch aligns MSI Laptop driver's key with F22 and F23.

Thanks! I pushed this part to trunk.

> This patch also merge ID_INPUT_KEY=1 key to msi-laptop input device
> for workaround the input_id doesn't support keycode large then 256.

I skipped this part, though, as I'd much rather fix the actual bug in
id_input. I don't see anything off-hand there which would limit the
key bitmask scanning (the capabilities/key attribute) to 255. It
reserves a bitmask array of KEY_MAX bits, which
/usr/include/linux/input.h defines as 0x2ff, so the keys you define
(0x213 and 0x214) should be well within that range.

Can you please give me the capabilities/ev and capabilities/key
contents of that input device, and also the "udevadm info --export-db"
parts of that keyboard module (both /event and /input), or just attach
the full output when in doubt? With that information I should be able
to reproduce the problem locally.

Thank you,

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
* [PATCH] Remap MSI Laptop touchpad on/off key to F22 and F23
From: Lee, Chun-Yi @ 2011-03-10  2:17 UTC (permalink / raw)
  To: linux-hotplug

MSI Laptop driver will query the real touchpad state then emit
KEY_TOUCHPAD_ON/OFF key.

Currently, X has defined F22 for touchpad on and F23 for touchpad
off. This patch aligns MSI Laptop driver's key with F22 and F23.

This patch also merge ID_INPUT_KEY=1 key to msi-laptop input device
for workaround the input_id doesn't support keycode large then 256.

Tested on MSI U160 netbook using msi-laptop driver.

Cc: Martin Pitt <martin.pitt@ubuntu.com>
Cc: Kay Sievers <kay.sievers@suse.de>
Signed-off-by: Lee, Chun-Yi <jlee@novell.com>
---
 extras/keymap/95-keymap.rules |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/extras/keymap/95-keymap.rules b/extras/keymap/95-keymap.rules
index 7f849d3..00462f7 100644
--- a/extras/keymap/95-keymap.rules
+++ b/extras/keymap/95-keymap.rules
@@ -47,6 +47,7 @@ ENV{DMI_VENDOR}="Sony*", KERNELS="input*", ATTRS{name}="Sony Vaio Keys", RUN+
 ENV{DMI_VENDOR}="ASUS*", KERNELS="input*", ATTRS{name}="Eee PC WMI hotkeys", RUN+="keymap $name 0x6B f21"
 ENV{DMI_VENDOR}="ASUS*", KERNELS="input*", ATTRS{name}="Eee PC Hotkey Driver", RUN+="keymap $name 0x37 f21"
 ENV{DMI_VENDOR}="Acer*", KERNELS="input*", ATTRS{name}="Acer WMI hotkeys", RUN+="keymap $name 0x82 f21"
+ENV{DMI_VENDOR}="MICRO-STAR*|Micro-Star*", KERNELS="input*", ATTRS{name}="MSI Laptop hotkeys", ENV{ID_INPUT_KEY}="1", RUN+="keymap $name 0x213 f22 0x214 f23"
 
 # Older Vaios have some different keys
 ENV{DMI_VENDOR}="Sony*", ATTR{[dmi/id]product_name}="*PCG-C1*|*PCG-K25*|*PCG-F1*|*PCG-F2*|*PCG-F3*|*PCG-F4*|*PCG-F5*|*PCG-F6*|*PCG-FX*|*PCG-FRV*|*PCG-GR*|*PCG-TR*|*PCG-NV*|*PCG-Z*|*VGN-S360*", ATTRS{name}="Sony Vaio Keys", RUN+="keymap $name module-sony-old"
-- 
1.6.0.2


^ permalink raw reply related
* RE: [PATCH V4] Export ACPI _DSM provided firmware instance number
From: Jordan_Hargrave @ 2011-03-10  0:35 UTC (permalink / raw)
  To: greg, Narendra_K
  Cc: a.beregalov, linux-next, jbarnes, linux-pci, linux-hotplug,
	netdev, mjg, Matt_Domsch, Charles_Rose, Shyam_Iyer, sfr
In-Reply-To: <20110307195616.GA14888@kroah.com>

That happens though for CONFIG_XXXX, though usually the include file is further down in the #ifdef region.


--jordan hargrave
Dell Enterprise Linux Engineering

-----Original Message-----
From: Greg KH [mailto:greg@kroah.com] 
Sent: Monday, March 07, 2011 1:56 PM
To: K, Narendra
Cc: a.beregalov@gmail.com; linux-next@vger.kernel.org; jbarnes@virtuousgeek.org; linux-pci@vger.kernel.org; linux-hotplug@vger.kernel.org; netdev@vger.kernel.org; mjg@redhat.com; Domsch, Matt; Rose, Charles; Hargrave, Jordan; Iyer, Shyam; sfr@canb.auug.org.au
Subject: Re: [PATCH V4] Export ACPI _DSM provided firmware instance number and string name to sysfs

On Mon, Mar 07, 2011 at 11:44:52AM -0800, Narendra_K@Dell.com wrote:
> --- a/drivers/pci/pci-label.c
> +++ b/drivers/pci/pci-label.c
> @@ -29,7 +29,9 @@
>  #include <linux/nls.h>
>  #include <linux/acpi.h>
>  #include <linux/pci-acpi.h>
> +#ifdef CONFIG_ACPI
>  #include <acpi/acpi_drivers.h>
> +#endif

You should never need a #ifdef in a .c file for an include file.  If so,
something is really wrong.

thanks,

greg k-h

^ permalink raw reply
* Re: Why udevadm-info result doesn't sync with input_id
From: Joey Lee @ 2011-03-09 10:56 UTC (permalink / raw)
  To: linux-hotplug
In-Reply-To: <4D76AD3E0200002300029880@novprvlin0050.provo.novell.com>

於 二，2011-03-08 於 11:27 +0000，joeyli(Joey Lee) 提到：
> Hi all,
> 
> Found udevadmin info result for ID_INPUT_KEY not sync with input_id,
> this issue happen on udev v157 and v166.
> 
> I generated a new patch for msi-laptop driver to send out
> KEY_TOUCHPAD_ON, KEY_TOUCHPAD_OFF key:
> 
> http://www.spinics.net/lists/platform-driver-x86/msg01543.html
> 
> I only added the KEY_TOUCHPAD_ON and KEY_TOUCHPAD_OFF in keymap in
> msi-laptop driver.
> Then, I add a statement to /lib/udev/rules.d/95-keymap.rules:
> 
> ENV{DMI_VENDOR}="MICRO-STAR*", KERNELS="input*", ATTRS{name}="MSI
> Laptop hotkeys", RUN+="keymap $name 0x213 f22 0x214 f23"
> 
> The above rule transfer the 0x213 scancode to F22, and 0x214 to F23 for
> KEY_TOUCHPAD_ON AND KEY_TOUCHPAD_OFF.
> 
> I found X-window always didn't pick out msi-laptop's input device to a
> keyboard device by evdev driver, because there have no ID_INPUT_KEY for
> this event node:
> 
> linux-xlzb:~ # udevadm info --q all -n /dev/input/event7
> P: /devices/virtual/input/input7/event7
> N: input/event7
> S: char/13:71
> E: UDEV_LOG=3
> E: DEVPATH=/devices/virtual/input/input7/event7
> E: SUBSYSTEM=input
> E: DEVNAME=input/event7
> E: ID_INPUT=1
> E: DMI_VENDOR=MICRO-STAR INTERNATIONAL CO., LTD
> E: MAJOR\x13
> E: MINORq
> E: DEVLINKS=/dev/char/13:71
> 
> But, 
> found there have ID_INPUT_KEY in input_id's result:
> 
> linux-xlzb:~ # /lib/udev/input_id /devices/virtual/input/input7
> ID_INPUT=1
> ID_INPUT_KEY=1
> 
> On udev v157, there have no ID_INPUT_KEY property in udev database:
> 
> linux-xlzb:~ # cat /dev/.udev/db/input\:event7 
> N:input/event7
> S:char/13:71
> E:ID_INPUT=1
> E:DMI_VENDOR=MICRO-STAR INTERNATIONAL CO., LTD
> 
> 
> The question is: 
> 
> Why there have ID_INPUT_KEY from input_id's result, but have no
> ID_INPUT_KEY from udevadm-info? Does that
> mean /dev/.udev/db/input/event7 not sync with /input7/capabilities/key ?
> 
> 
> Appreciate for any kindly response.
> 
> 

I thought I know what happen, because the input_id not support the 256.
The new KEY_TOUCHPAD_* define in input.h are all larger then 255, 
I direct add a rule to merge ID_INPUT_KEY=1 to MSI hotkeys device, can
workaround the problem. Will send out patch to 95-keymap.rules.

Just wonder why input_id only support keycode to 255 but not support to
KEY_MAX.


Thank's a lot!
Joey Lee


^ permalink raw reply
* Re: [PATCH] Make attribute array static and const
From: Kay Sievers @ 2011-03-08 12:15 UTC (permalink / raw)
  To: linux-hotplug
In-Reply-To: <4D75EF6D.5090702@secunet.com>

On Tue, Mar 8, 2011 at 09:57, Thomas Egerer <thomas.egerer@secunet.com> wrote:
> ---
>  udev/udevadm-info.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)

Applied.

Thanks,
Kay

^ permalink raw reply
* Why udevadm-info result doesn't sync with input_id
From: Joey Lee @ 2011-03-08 11:27 UTC (permalink / raw)
  To: linux-hotplug

Hi all,

Found udevadmin info result for ID_INPUT_KEY not sync with input_id,
this issue happen on udev v157 and v166.

I generated a new patch for msi-laptop driver to send out
KEY_TOUCHPAD_ON, KEY_TOUCHPAD_OFF key:

http://www.spinics.net/lists/platform-driver-x86/msg01543.html

I only added the KEY_TOUCHPAD_ON and KEY_TOUCHPAD_OFF in keymap in
msi-laptop driver.
Then, I add a statement to /lib/udev/rules.d/95-keymap.rules:

ENV{DMI_VENDOR}="MICRO-STAR*", KERNELS="input*", ATTRS{name}="MSI
Laptop hotkeys", RUN+="keymap $name 0x213 f22 0x214 f23"

The above rule transfer the 0x213 scancode to F22, and 0x214 to F23 for
KEY_TOUCHPAD_ON AND KEY_TOUCHPAD_OFF.

I found X-window always didn't pick out msi-laptop's input device to a
keyboard device by evdev driver, because there have no ID_INPUT_KEY for
this event node:

linux-xlzb:~ # udevadm info --q all -n /dev/input/event7
P: /devices/virtual/input/input7/event7
N: input/event7
S: char/13:71
E: UDEV_LOG=3
E: DEVPATH=/devices/virtual/input/input7/event7
E: SUBSYSTEM=input
E: DEVNAME=input/event7
E: ID_INPUT=1
E: DMI_VENDOR=MICRO-STAR INTERNATIONAL CO., LTD
E: MAJOR\x13
E: MINORq
E: DEVLINKS=/dev/char/13:71

But, 
found there have ID_INPUT_KEY in input_id's result:

linux-xlzb:~ # /lib/udev/input_id /devices/virtual/input/input7
ID_INPUT=1
ID_INPUT_KEY=1

On udev v157, there have no ID_INPUT_KEY property in udev database:

linux-xlzb:~ # cat /dev/.udev/db/input\:event7 
N:input/event7
S:char/13:71
E:ID_INPUT=1
E:DMI_VENDOR=MICRO-STAR INTERNATIONAL CO., LTD


The question is: 

Why there have ID_INPUT_KEY from input_id's result, but have no
ID_INPUT_KEY from udevadm-info? Does that
mean /dev/.udev/db/input/event7 not sync with /input7/capabilities/key ?


Appreciate for any kindly response.


Thank's a lot!
Joey Lee


^ permalink raw reply
* [PATCH] Make attribute array static and const
From: Thomas Egerer @ 2011-03-08  8:57 UTC (permalink / raw)
  To: linux-hotplug

---
 udev/udevadm-info.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/udev/udevadm-info.c b/udev/udevadm-info.c
index a231fd8..187e74d 100644
--- a/udev/udevadm-info.c
+++ b/udev/udevadm-info.c
@@ -33,7 +33,7 @@

 static bool skip_attribute(const char *name)
 {
-	char *skip[] = {
+	static const char const *skip[] = {
 		"uevent",
 		"dev",
 		"modalias",
-- 1.7.2.2

^ permalink raw reply related
* Re: [PATCH V4] Export ACPI _DSM provided firmware instance number
From: Narendra_K @ 2011-03-07 20:55 UTC (permalink / raw)
  To: greg
  Cc: a.beregalov, linux-next, jbarnes, linux-pci, linux-hotplug,
	netdev, mjg, Matt_Domsch, Charles_Rose, Jordan_Hargrave,
	Shyam_Iyer, sfr
In-Reply-To: <20110307195616.GA14888@kroah.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 1700 bytes --]

On Tue, Mar 08, 2011 at 01:26:16AM +0530, Greg KH wrote:
> On Mon, Mar 07, 2011 at 11:44:52AM -0800, Narendra_K@Dell.com wrote:
> > --- a/drivers/pci/pci-label.c
> > +++ b/drivers/pci/pci-label.c
> > @@ -29,7 +29,9 @@
> >  #include <linux/nls.h>
> >  #include <linux/acpi.h>
> >  #include <linux/pci-acpi.h>
> > +#ifdef CONFIG_ACPI
> >  #include <acpi/acpi_drivers.h>
> > +#endif
> 
> You should never need a #ifdef in a .c file for an include file.  If so,
> something is really wrong.

I agree. Also, i realized that the include was not required to address the
reported error. Please find the revised patch here.

From: Narendra K <narendra_k@dell.com>
Subject: [PATCH] Fix compilation error when CONFIG_ACPI is unset

This patch fixes compilation error descibed below introduced by
the commit 6058989bad05b82e78baacce69ec14f27a11b5fd

drivers/pci/pci-label.c: In function ‘pci_create_firmware_label_files’:
drivers/pci/pci-label.c:366:2: error: implicit declaration of function ‘device_has_dsm’

Signed-off-by: Narendra K <narendra_k@dell.com>
---
 drivers/pci/pci-label.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/pci/pci-label.c b/drivers/pci/pci-label.c
index 824e247..8c80138 100644
--- a/drivers/pci/pci-label.c
+++ b/drivers/pci/pci-label.c
@@ -174,6 +174,12 @@ pci_remove_acpi_index_label_files(struct pci_dev *pdev)
 	return -1;
 }
 
+static inline bool
+device_has_dsm(struct device *dev)
+{
+	return false;
+}
+
 #else
 
 static const char device_label_dsm_uuid[] = {
-- 
1.7.3.1

With regards,
Narendra Kÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þ\x1a-¦[ þ)í…æèw*\x1fjg¬±¨\x1e¶‰šŽŠÝ¢jÿ¾\a«þG«éÿ¢¸\f¢·¦j:+v‰¨ŠwèjØm¶Ÿÿþø\x1e¯ù\x1e®w¥þŠàþf£¢·hšâúÿ†Ù¥

^ permalink raw reply related
* Re: [PATCH V4] Export ACPI _DSM provided firmware instance number
From: Greg KH @ 2011-03-07 19:56 UTC (permalink / raw)
  To: Narendra_K
  Cc: a.beregalov, linux-next, jbarnes, linux-pci, linux-hotplug,
	netdev, mjg, Matt_Domsch, Charles_Rose, Jordan_Hargrave,
	Shyam_Iyer, sfr
In-Reply-To: <20110307200512.GA22450@fedora14-r610.oslab.blr.amer.dell.com>

On Mon, Mar 07, 2011 at 11:44:52AM -0800, Narendra_K@Dell.com wrote:
> --- a/drivers/pci/pci-label.c
> +++ b/drivers/pci/pci-label.c
> @@ -29,7 +29,9 @@
>  #include <linux/nls.h>
>  #include <linux/acpi.h>
>  #include <linux/pci-acpi.h>
> +#ifdef CONFIG_ACPI
>  #include <acpi/acpi_drivers.h>
> +#endif

You should never need a #ifdef in a .c file for an include file.  If so,
something is really wrong.

thanks,

greg k-h

^ permalink raw reply
* Re: [PATCH V4] Export ACPI _DSM provided firmware instance number
From: Narendra_K @ 2011-03-07 19:44 UTC (permalink / raw)
  To: a.beregalov, linux-next
  Cc: jbarnes, linux-pci, linux-hotplug, netdev, mjg, Matt_Domsch,
	Charles_Rose, Jordan_Hargrave, Shyam_Iyer, sfr
In-Reply-To: <AANLkTimz662+L6eYJm2gh0NwWOxxzQV3503bcs-GMFGu@mail.gmail.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 2733 bytes --]

On Mon, Mar 07, 2011 at 11:34:05PM +0530, Alexander Beregalov wrote:
> On 4 March 2011 21:43, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > On Wed, 2 Mar 2011 22:34:17 +0530
> > <Narendra_K@Dell.com> wrote:
> >
> >> On Wed, Feb 23, 2011 at 06:06:42PM +0530, K, Narendra wrote:
> >> > Hello,
> >> >
> >> > This patch exports ACPI _DSM provided firmware instance number and
> >> > string name to sysfs.
> >> >
> >> > V1 -> V2:
> >> > The attribute 'index' is changed to 'acpi_index' as the semantics of
> >> > SMBIOS provided device type instance and ACPI _DSM provided firmware
> >> > instance number are different.
> >> >
> >> > V2 -> V3:
> >> > Matthew Garrett pointed out that 'sysfs_create_groups' does return an
> >> > error when there are no ACPI _DSM attributes available and because of
> >> > that the fallback to SMBIOS will not happen. As a result SMBIOS provided
> >> > attributes are not created. This version of the patch addresses the issue.
> >> >
> >>
> >> V3 -> V4:
> >> Select NLS if (DMI || ACPI) in drivers/pci/Kconfig to prevent build
> >> breakage from an 'allmodconfig'
> >
> > Applied, fingers crossed this time. :)
> >
> 
> Hi,
> 
> It cannot be compiled if CONFIG_ACPI is not set.
> 
> drivers/pci/pci-label.c: In function 'pci_create_firmware_label_files':
> drivers/pci/pci-label.c:366:2: error: implicit declaration of function
> 'device_has_dsm'

Hello,

Sorry for the inconvenience. Please find the fix here -

From: Narendra K <narendra_k@dell.com>
Subject: [PATCH] Fix compilation error when CONFIG_ACPI unset

This patch fixes compilation error descibed below introduced by
the commit 6058989bad05b82e78baacce69ec14f27a11b5fd

drivers/pci/pci-label.c: In function ‘pci_create_firmware_label_files’:
drivers/pci/pci-label.c:366:2: error: implicit declaration of function ‘device_has_dsm’

Signed-off-by: Narendra K <narendra_k@dell.com>
---
 drivers/pci/pci-label.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/pci/pci-label.c b/drivers/pci/pci-label.c
index 824e247..82fd73d 100644
--- a/drivers/pci/pci-label.c
+++ b/drivers/pci/pci-label.c
@@ -29,7 +29,9 @@
 #include <linux/nls.h>
 #include <linux/acpi.h>
 #include <linux/pci-acpi.h>
+#ifdef CONFIG_ACPI
 #include <acpi/acpi_drivers.h>
+#endif
 #include <acpi/acpi_bus.h>
 #include "pci.h"
 
@@ -174,6 +176,12 @@ pci_remove_acpi_index_label_files(struct pci_dev *pdev)
 	return -1;
 }
 
+static inline bool
+device_has_dsm(struct device *dev)
+{
+	return false;
+}
+
 #else
 
 static const char device_label_dsm_uuid[] = {
-- 
1.7.3.1

With regards,
Narendra Kÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þ\x1a-¦[ þ)í…æèw*\x1fjg¬±¨\x1e¶‰šŽŠÝ¢jÿ¾\a«þG«éÿ¢¸\f¢·¦j:+v‰¨ŠwèjØm¶Ÿÿþø\x1e¯ù\x1e®w¥þŠàþf£¢·hšâúÿ†Ù¥

^ permalink raw reply related
* Re: [PATCH V4] Export ACPI _DSM provided firmware instance number and
From: Alexander Beregalov @ 2011-03-07 18:04 UTC (permalink / raw)
  To: Jesse Barnes
  Cc: Narendra_K, linux-pci, linux-hotplug, netdev, mjg, Matt_Domsch,
	Charles_Rose, Jordan_Hargrave, Shyam_Iyer, sfr
In-Reply-To: <20110304104314.26265021@jbarnes-desktop>

On 4 March 2011 21:43, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Wed, 2 Mar 2011 22:34:17 +0530
> <Narendra_K@Dell.com> wrote:
>
>> On Wed, Feb 23, 2011 at 06:06:42PM +0530, K, Narendra wrote:
>> > Hello,
>> >
>> > This patch exports ACPI _DSM provided firmware instance number and
>> > string name to sysfs.
>> >
>> > V1 -> V2:
>> > The attribute 'index' is changed to 'acpi_index' as the semantics of
>> > SMBIOS provided device type instance and ACPI _DSM provided firmware
>> > instance number are different.
>> >
>> > V2 -> V3:
>> > Matthew Garrett pointed out that 'sysfs_create_groups' does return an
>> > error when there are no ACPI _DSM attributes available and because of
>> > that the fallback to SMBIOS will not happen. As a result SMBIOS provided
>> > attributes are not created. This version of the patch addresses the issue.
>> >
>>
>> V3 -> V4:
>> Select NLS if (DMI || ACPI) in drivers/pci/Kconfig to prevent build
>> breakage from an 'allmodconfig'
>
> Applied, fingers crossed this time. :)
>

Hi,

It cannot be compiled if CONFIG_ACPI is not set.

drivers/pci/pci-label.c: In function 'pci_create_firmware_label_files':
drivers/pci/pci-label.c:366:2: error: implicit declaration of function
'device_has_dsm'

^ permalink raw reply
* Re: libudev, a question about the enumerate API.
From: Kay Sievers @ 2011-03-07 16:11 UTC (permalink / raw)
  To: Alan Ott; +Cc: Antonio Ospite, linux-hotplug, linux-input
In-Reply-To: <4D750151.7070904@signal11.us>

On Mon, Mar 7, 2011 at 17:01, Alan Ott <alan@signal11.us> wrote:
> On 03/07/2011 10:27 AM, Kay Sievers wrote:
>>
>> The usual enumeration in udev never uses the device tree in
>> /sys/devices/, only the subsystem lists /sys/{class,bus}/. We could
>> have something to enumerate all child devices of a given device. It's
>> not simple, but could be made working.

> The documentation in Documentation/sysfs-rules.txt seems to warn against
> using /sys/class and sys/bus:
>
> - devices are only "devices"
>  There is no such thing like class-, bus-, physical devices,
>  interfaces, and such that you can rely on in userspace. Everything is
>  just simply a "device". Class-, bus-, physical, ... types are just
>  kernel implementation details which should not be expected by
>  applications that look for devices in sysfs.
>
> ...
>      - all elements of a devpath must be real directories. Symlinks
>        pointing to /sys/devices must always be resolved to their real
>        target and the target path must be used to access the device.
>        That way the devpath to the device matches the devpath of the
>        kernel used at event time.
>      - using or exposing symlink values as elements in a devpath string
>        is a bug in the application
>
> ...
>
>      - accessing attributes reached by a symlink pointing to another device,
>        like the "device"-link, is a bug in the application
>
> ...
>
> - Hierarchy in a single device tree
>  There is only one valid place in sysfs where hierarchy can be examined
>  and this is below: /sys/devices.
>
> and more...
>
> I figured that this document was probably out of date, since even libudev
> uses /sys/class. What's your take on this document?

I wrote that document. :) It's partly out-of-date, but this is still true.

Udev, since quite some years, even the old and dead HAL supports
/sys/subsystem/ already, which is not in the kernel today, but might
be soon.

If that directory is available, /sys/{class,bus}/ will not be looked at:
  http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=libudev/libudev-enumerate.c;h\x128813c7d618717690f79d0eca82776a6c4fa011;hb=HEAD#l776

Kay

^ permalink raw reply
* Re: libudev, a question about the enumerate API.
From: Alan Ott @ 2011-03-07 16:01 UTC (permalink / raw)
  To: Kay Sievers; +Cc: Antonio Ospite, linux-hotplug, linux-input
In-Reply-To: <AANLkTik7pPUYou9OwD0E5r-Wr3a67kQZPToDepZH8pLu@mail.gmail.com>

On 03/07/2011 10:27 AM, Kay Sievers wrote:
> The usual enumeration in udev never uses the device tree in
> /sys/devices/, only the subsystem lists /sys/{class,bus}/. We could
> have something to enumerate all child devices of a given device. It's
> not simple, but could be made working.
>    

Hi Kay,

The documentation in Documentation/sysfs-rules.txt seems to warn against 
using /sys/class and sys/bus:

- devices are only "devices"
   There is no such thing like class-, bus-, physical devices,
   interfaces, and such that you can rely on in userspace. Everything is
   just simply a "device". Class-, bus-, physical, ... types are just
   kernel implementation details which should not be expected by
   applications that look for devices in sysfs.

...
       - all elements of a devpath must be real directories. Symlinks
         pointing to /sys/devices must always be resolved to their real
         target and the target path must be used to access the device.
         That way the devpath to the device matches the devpath of the
         kernel used at event time.
       - using or exposing symlink values as elements in a devpath string
         is a bug in the application

...

       - accessing attributes reached by a symlink pointing to another 
device,
         like the "device"-link, is a bug in the application

...

- Hierarchy in a single device tree
   There is only one valid place in sysfs where hierarchy can be examined
   and this is below: /sys/devices.

and more...

I figured that this document was probably out of date, since even 
libudev uses /sys/class. What's your take on this document?

Alan.



^ permalink raw reply
* Re: libudev, a question about the enumerate API.
From: Kay Sievers @ 2011-03-07 15:27 UTC (permalink / raw)
  To: Antonio Ospite; +Cc: linux-hotplug, linux-input, Alan Ott
In-Reply-To: <20110223235053.ae9d6b0a.ospite@studenti.unina.it>

On Wed, Feb 23, 2011 at 23:50, Antonio Ospite <ospite@studenti.unina.it> wrote:
> Hi,
>
> in my attempts to handle leds setting and usb pairing for the Sixaxis
> controller I had to fight with libudev a little bit, eventually I
> succeeded in what I wanted to achieve but I still have some questions
> about the libudev API, so here I am.
>
> This is basically the layout for the device:
>
> 4-1:1.0/
> |-- 0003:054C:0268.000C  (hid device)
> |   |-- hidraw
> |   |   `-- hidraw1
> |   `-- uevent  (which tells me HID_PHYS)
> |
> `-- input
>    `-- input17
>        |-- js0
>        `-- phys
>
> I needed to get the hidraw device node, and the js device number, the
> two sibling devices (from hid and input subsystem) can be matched using
> the 'phys' property.
>
> This is what I do now:
>  0. Monitor with a filter matching the "hidraw" subsystem.
>  1. When a matching device is connected we get the "hidraw" device.
>  2. Go up to its "hid" parent device and check it is actually a
>    Sixaxis (using HID_NAME), if not GOTO 1.
>  3. Store the hidraw device node for later use
>  4. Store the HID_PHYS value in order to look for the matching joystick.
>  5. Enumerate the joystick devices with the sysname filter "js*"
>  6. For each joystick:
>    a. Go up to its input parent device
>    b. Check that the phys attribute matches HID_PHYS,
>       if so, store the joystick device number.
>  7. Set leds
>  8. If the Sixaxis is connected via USB do the cable pairing.
>
> My doubt is about 5. and 6a.: I have go deep in the hierarchy down to
> the js0 leaf device and then I have to go up one level to get the
> input device, naively I would have done the contrary:
>  5'. Enumerate the input devices such that phys = HID_PHYS
>  6'. Enumerate the devices _below_ the input device from 5'. looking
>     for the jsX device.
>
> But this is not possible because the enumerate API is designed to start
> always from the root of /sys.
>
> Finally the question: why the enumerate API in libudev does not allow
> enumerating only from a _subtree_? Has that been designed this way to
> keep the API simple, or because it is not considered useful?

The usual enumeration in udev never uses the device tree in
/sys/devices/, only the subsystem lists /sys/{class,bus}/. We could
have something to enumerate all child devices of a given device. It's
not simple, but could be made working.

Kay

^ permalink raw reply
* Re: [PATCH] add ACLs to /dev/sgX nodes for CD-ROM
From: Kay Sievers @ 2011-03-07 15:23 UTC (permalink / raw)
  To: linux-hotplug
In-Reply-To: <1299402082-4796-1-git-send-email-arvidjaar@mail.ru>

On Sun, Mar 6, 2011 at 10:01, Andrey Borzenkov <arvidjaar@mail.ru> wrote:
> Current wine is using /dev/sgX to access CD-ROM devices. Since
> distributions switched to using ACL instead of group membership
> to control device access, wine is not able to access them.
>
> Add ACL to device nodes that already get GROUP="cdrom".

Applied.

Thanks,
Kay

^ permalink raw reply
* Re: [PATCH V6 0/2] tracing, perf: cpu hotplug trace events
From: Amit Kucheria @ 2011-03-07 11:25 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Thomas Renninger, Vincent Guittot, Ingo Molnar, linux-kernel,
	linux-hotplug, fweisbec, rusty, tglx, Arjan van de Ven, Alan Cox,
	Peter Zijlstra, H. Peter Anvin, Andrew Morton, linux-perf-users
In-Reply-To: <1299192176.6376.47.camel@gandalf.stny.rr.com>

On Fri, Mar 4, 2011 at 12:42 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Wed, 2011-03-02 at 23:07 +0100, Thomas Renninger wrote:
>
>> I doubt cpu offlining is the proper instrument to save power.
>> You want to prevent the CPU of being used by ripping it out from scheduler decisions and
>> make sure it doesn't get interrupts by offlining. But the (latency) price is high.
>
> I could imagine that a server could use this for power savings to take
> down all but 1 CPU on off hours. When it knows its not going to get much
> action but still needs to remain online. Then just before peak times
> begin, online the other CPUs.
>
> But anything more dynamic than that, I can't see it really worth it. As
> the latency to bring the other CPU online, may miss a peak when it was
> needed.
>

ARM SoCs require both cores to be idle to hit the really low power
retention/off states. Hoping for both cores to go idle at the same
instant causes several low power opportunities to be lost. Hence the
experiments with hotplug to improve the idle characteristics of the
system. On our wiki page[1], you can see some results under "Idle
improvement" section.

But sched_mc does seem like a more appropriate way to help nudge all
the workload onto a single core.

Regards,
Amit


[1] https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/Hotplug

^ permalink raw reply
* Re: [PATCH] add ACLs to /dev/sgX nodes for CD-ROM
From: Nicolas Pomarède @ 2011-03-06 17:21 UTC (permalink / raw)
  To: linux-hotplug
In-Reply-To: <1299402082-4796-1-git-send-email-arvidjaar@mail.ru>

Le 06/03/2011 16:33, Kay Sievers a écrit :
> On Sun, Mar 6, 2011 at 10:01, Andrey Borzenkov<arvidjaar@mail.ru>  wrote:
>> Current wine is using /dev/sgX to access CD-ROM devices. Since
>> distributions switched to using ACL instead of group membership
>> to control device access, wine is not able to access them.
>>
>> Add ACL to device nodes that already get GROUP="cdrom".
>
> sg is kind of deprecated and should really not be used anymore by
> anything. Ideally we would start no even loading the module.
>
> Who exactly depends on it and can not be fixed? Why does Fedora and
> SUSE does not seem to have any problem the last couple of years?
>
> Kay

Other distribs are also having problem with this :

gentoo : http://bugs.gentoo.org/321007

fedora 13 : http://bugs.winehq.org/show_bug.cgi?id#313

Wine's code is using /dev/sgX, I don't know if there're some patches 
around to change this.

It seems an usual fix is to add oneself to the cdrom group, but this is 
hardly an out of the box solution for a non technical user that would 
just install his linux distro of choice.

The fact that this problem is often related to users wanting to run 
protected games under Wine is certainly another reason why it didn't get 
much attention or fixes so far (in my case I want to access low level 
scsi functions with EAC).

Using acl in udev would provide a solution that automatically enables 
access to /dev/sgX for any logged user, without having to change /etc/group.

Nicolas

^ permalink raw reply
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox