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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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>
Instead of using multiple recursive Makefile.am files, use a single
Makefile.am that sets and builds all the basic suite of libraries and
binaries for udev. This reduces the number of files in the source tree, and
also reduces drastically the build time when using parallel-make.
With this setup, all the compile steps will be executed in parallel, and
just the linking stage will be (partially) serialised on the libraries
creation.
It did not work for the last couple of releases.
If RUN{record_failed}+="..." is given, a non-zero execution will mark
the event as failed. Recorded failed events can be re-triggered with:
udevadm trigger --type=failed
The failed tracking _might_ be useful for things which might not be
ready to be executed at early bootup, but a bit later when the needed
dependencies are available. In many cases though, it indicates that
something is used in a way it should not.
Exclude digitizers and similar devices from ID_CLASS joystick by
checking modalias for BTN_DIGI.
This was also done for linux kernel joydev interface in linux commit
d07a9cba6be5c0e947afc1014b5a62182a86f1f1.
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>
We need to call ata_id as the default for libata sd* devices. We
want ID_BUS=ata, and the ATA device proeprties, and be independent
of the SCSI emulation with the truncated values. The links
in /dev/disk/by-id/{ata-*,scsi-*} are still the same.
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>
Instead of of our own private monitor socket, we send the
processed event back to our netlink socket, to the multicast
group 2 -- so any number of users can listen to udev events,
just like they can listen to kernel emitted events on group 1.
md/array_state in case of partition doesn't exist, so all uevents
for partitions didn't execute any SYMLINK rules
Signed-off-by: Michal Soltys <soltys@ziu.info>
On Thu, Feb 5, 2009 at 08:43, Harald Hoyer <harald@redhat.com> wrote:
> Radek Vykydal <rvykydal@redhat.com> encountered a problem with md devices.
> If the raid is about to be removed a "change" and "remove" event is sent.
$env{ID_PATH} includes the "-nst" suffix anyway, so we shouldn't append
it a second time as part of the rule creating the device file symlink.
Signed-off-by: Lennart Poettering <lennart@poettering.net>
On Fri, Dec 26, 2008 at 01:26, Karel Zak <kzak@redhat.com> wrote:
> On Fri, Dec 26, 2008 at 12:39:16AM +0100, Kay Sievers wrote:
>> On Fri, Dec 26, 2008 at 00:26, Karel Zak <kzak@redhat.com> wrote:
>> > The upstream raw(8) command supports /dev/rawctl and also
>> > /dev/raw/rawctl. I think it makes more sense to use raw/rawctl when
>> > you have all your raw devices in raw/ subdirectory (e.g. /dev/raw/raw<N>).
>>
>> The raw tool looks for /dev/rawctl first and the fallback to
>> /dev/raw/rawctl is named DEVFS_*. Should we turn that order around and
>> remove the devfs notion from the raw tool and let udev create a
>> dev/raw/rawctl node?
>
> Yeah. Fixed, committed and pushed.
>
> $ strace -e open ./raw
> open("/dev/raw/rawctl", O_RDWR) = -1 ENOENT (No such file or directory)
> open("/dev/rawctl", O_RDWR) = -1 ENOENT (No such file or directory)
>
> I have also removed the #ifdef OLD_RAW_DEVS (/dev/raw<N>) junk.
A note on /dev/raw1394's security implications:
1. You cannot access local memory through raw1394, except
for ROMs and CSRs that are exposed to other nodes any way.
2. It is extremely hard to manipulate data on attached
SBP-2 devices (FireWire storage devices).
3. You can disturb operation of the FireWire bus, e.g.
creating a DoS situation for audio/video applications, for
SBP-2 devices, or eth1394 network interfaces.
4. If another PC is attached to the FireWire bus, it may be
possible to read or overwrite the entire RAM of that remote PC.
This depends on the PC's configuration. Most FireWire controllers
support this feature (yes, it's not a bug, or at least wasn't
intended to be one...) but not all OSs enable the feature.
Actually, a cheap setup to achieve #1 by #4 is to have two
FireWire controllers in the PC and connect them.
https://bugs.launchpad.net/ubuntu/+source/kino/+bug/6290/comments/21
specialix_rioctl: no kernel name symlink
specialix_sxctl: no kernel name symlink
bus/usb: 0644 -> 0664
ppdev: lp
dri: 0666 -> 0660
js: no kernel name symlink
In the interest of standardizing udev rules, please consider the
following patch that adds udev rules for the ATA over Ethernet character
and block devices. The aoe module has been a long-time member of the
kernel and needs inclusion in the standard udev rules.
[...] running the command
`make maintainer-clean' should not delete `configure' even if
`configure' can be remade using a rule in the Makefile. More
generally, `make maintainer-clean' should not delete anything that
needs to exist in order to run `configure' and then begin to build
the program. This is the only exception; `maintainer-clean' should
delete everything else that can be rebuilt.
On Tue, Dec 2, 2008 at 21:07, Matthias Schwarzott <zzam@gentoo.org> wrote:
> It seems that the rules related to capi devices are not correct:
>
> KERNEL=="capi", NAME="capi20", SYMLINK+="isdn/capi20"
> KERNEL=="capi*", NAME="capi/%n"
>
> Changing the second rule to match only on KERNEL=="capi[0-9]*" is reported to
> make it work.
> So I can only guess that the problem is the second rule overwriting the NAME
> set by the first one.
On Thu, Oct 30, 2008 at 03:55, Tejun Heo <tj@kernel.org> wrote:
The appropriate default timeout differs depending on the transport and
the type of the attached device, so the above two rules harm more than
help. The affect of the above two rules weren't visible for some
reason but with recent block layer timeout update, they actually work
and cause problems.
Opening an optical drive device node without O_NONBLOCK autocloses the
tray, we run vol_id on every media change by kernel emitted "change"
events, which can make it hard to change the media when the tray closes
immediatey again.:) We check for cdrom_id to indicate an existing track,
if no media is found, we will not open the device with vol_id.
Thanks to Christian Krause and DavidZ for debugging and testing.
None of these rules is supposed to be changed by users, so move
them out of /etc. Custom rules, and automatically generated rules
stay in /etc. All rules are still processed in lexical order,
regardless which directory they live in.