IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
On Sun, Nov 6, 2011 at 21:45, William Hubbs <w.d.hubbs@gmail.com> wrote:
> someone on gentoo just reported to me that the following rule has been
> deleted from udev-174, which is leaving his optical devices in the
> standard "disk" group. He does not want to add his users to this group.
On Tue, Aug 2, 2011 at 10:56, Thomas Bächler <thomas@archlinux.org> wrote:
> Commit c49df20758 prevented udev from
> creating broken symlinks for bluetooth hid devices. Unfortunately,
> it also removed the ID_INPUT=1 and ID_INPUT_{KEY,MOUSE}=1 properties
> from those devices. Xorg relies on these properties for cold- and
> hotplugging of input devices.
1. IIDC cameras from Point Grey use the vendor OUI as Specifier_ID
instead of the 1394 TA's OUI but are otherwise fully compliant to the
IIDC spec. Their device files should be accessible like those of any
other IIDC cameras.
2. Originally, the Software_Version of devices that implement FCP
(IEC 61883-1 Function Control Protocol) was meant to be a bitmap of all
command sets that an FCP capable unit supports. Bitmap flags are
defined for AV/C, CAL, EHS, HAVi, and vendor unique command sets.
Software_Version was revised to be a simple identifier instead, and
devices that support several command sets were meant to instantiate one
unit directory for each command set. Still, some devices with the flags
for AV/C and vendor unique command sets combined were released (but
apparently no devices with any other flag combinations). These rare but
existing AV/C + vendor unique devices need to be accessible just like
plain AV/C devices.
Side notes:
- Many AV/C devices make use of the Vendor Dependent AV/C command, but
this is unrelated to vendor unique FCP command sets.
- Here are all standardized FireWire protocol identifiers that I know
of, listed as Specifier_ID:Software_Version | specifier | protocol.
0x00005e:0x000001 | IANA | IPv4 over 1394 (RFC 2734)
0x00005e:0x000002 | IANA | IPv6 over 1394 (RFC 3146)
0x00609e:0x010483 | INCITS | SBP-2 (or SCSI command sets over SBP-3)
0x00609e:0x0105bb | INCITS | AV/C over SBP-3
0x00a02d:0x010001 | 1394 TA | AV/C (over FCP)
0x00a02d:0x010002 | 1394 TA | CAL
0x00a02d:0x010004 | 1394 TA | EHS
0x00a02d:0x010008 | 1394 TA | HAVi
0x00a02d:0x014000 | 1394 TA | Vendor Unique
0x00a02d:0x014001 | 1394 TA | Vendor Unique and AV/C (over FCP)
0x00a02d:0x000100 | 1394 TA | IIDC 1.04
0x00a02d:0x000101 | 1394 TA | IIDC 1.20
0x00a02d:0x000102 | 1394 TA | IIDC 1.30
0x00a02d:0x0A6BE2 | 1394 TA | DPP 1.0
0x00a02d:0x4B661F | 1394 TA | IICP 1.0
For now we are only interested in udev rules for AV/C and IIDC.
Reported-by: Damien Douxchamps <ddsf@douxchamps.net> (Point Grey IIDC ID)
Reported-by: Clemens Ladisch <clemens@ladisch.de> (AV/C + vendor unique ID)
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Commit f61e72d89 failed to match for the case where an USB printer has multiple
interfaces, such as
ID_USB_INTERFACES=:ffffff:070102:
Thanks to Pablo Mazzini for spotting this!
virtio ports spawned by the virtio_console.c driver can have 'names'
assigned to them by hosts. The ports are distinguishable using these
names. Make a rule to create a symlink to the chardev associated for a
port with a name.
The symlink created is:
/dev/virtio-ports/org.libvirt.console0 -> /dev/vport0p0
if the first port for the first device was given a name of
'org.libvirt.console0'.
Signed-off-by: Amit Shah <amit.shah@redhat.com>
The kernel IDE drivers get deprecated now:
http://article.gmane.org/gmane.linux.ide/43151
Almost everybody has switched over to libata devices long ago.
Recent services do not work with the now deprecated IDE drivers
at all and require libata drivers and SCSI infrastructure.
Systems who care about the old stuff need to add the rules to the
compat rules.
Commit f61e72d8 made raw USB printers accessible for the lp group. However,
chmoding them to 0660 is a bit over-zealous, since by default raw USB devices
are world-readable. Not being so breaks lsusb unnecessarily. Now set
permissions to 0664.
With well defined and kernel-supplied node names, we no longer need
to support a possible stack of conflicting symlinks and node names.
Only symlinks with identical names can be claimed by multiple devices.
This shrinks the former /dev/.udev/names/ significantly.
Also the /dev/{block,char}/MAJ:MIN" links are excluded from the name
stack - they are unique and can not conflict.
Starting from version 1.4, cups now uses libusb and printer USB devices instead
of the usblp generated /dev/usb/lpX ones. In order to not require the cups USB
backend to run as root now, change raw USB printer devices to be root:lp 0660,
similar to usblpX devices.
This might also enable the hplip backend to not run as root, since this has
always used raw device nodes.
https://launchpad.net/bugs/420015
Fix spelling in docbook comments, code comments, and a local variable
name. Thanks to "ispell -h" for docbook HTML and "scspell" for source
code.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
The newer firewire-core driver exposes per-device character device files,
called /dev/fw[0-9]*, in contrast to the older raw1394, video1394, dv1394
drivers which created one global file or per-controller files.
This allows to set ownership, permissions, or/ and access control lists
for each device file based on device type markers obtained from sysfs.
The "units" attribute which is used for this purpose has become available
in Linux 2.6.31(-rc1) by commit 0210b66dd88a2a1e451901b00378a2068b6ccb35.
The added rules match identifiers of
- IIDC devices:
industrial cameras and some webcams,
- AV/C devices:
camcorders, set-top boxes, TV sets, audio devices, and similar
devices.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
On Fri, May 22, 2009 at 16:15, Alan Jenkins <alan-jenkins@tuffmail.co.uk> wrote:
> I've been looking at what is responsible for all the path lookup activity in
> coldplug. On my debian stable system, it looks like every device gets its
> parent looked up in sysfs. I think this is due to SUBSYSTEMS matches.
>
> I see the udev default rules are different, but it looks like they still
> test for SUBSYSTEMS on every single device. Should we add SUBSYSTEM="scsi_generic"
> to these three rules?
UDev follows the kernel given name, and re-uses the kernel created
device node. If the kernel and spcecified udev rules disagree, the
udev specified node node is created and the kernel-created on is
deleted.
I don't see any security implications, to be actually useful,
/dev/cpu/<n>/cpuid should be world readable. The cpuid instruction
can be called from userspace anyway, so there is nothing to hide.
The device does not support any write operation, so 0444 should
suffice.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
