Kay Sievers [Thu, 5 Feb 2009 13:03:17 +0000 (14:03 +0100)]
rules: fix md "change"/"remove" handling
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.
Karel Zak [Fri, 23 Jan 2009 23:37:22 +0000 (00:37 +0100)]
vol_id: fix ddf version string
The version string in DDF suberblock does not include the null terminator
and the snprintf() function writes at most "size" bytes *including* the
null byte.
old version:
ID_FS_VERSION=02.00.0
new version:
ID_FS_VERSION=02.00.00
Kay Sievers [Thu, 22 Jan 2009 18:23:33 +0000 (19:23 +0100)]
usb_id: handle ATAPI devices like SCSI devices
Some weird mass storage devices identify the disks as ATAPI/cdrom
devices, and all disks in such enclusure get the same ids which
overwrite each other, in such cases, get the typ of device from the
scsi device, which has more knowledge what kind of device it really
is.
Olaf Kirch [Wed, 21 Jan 2009 10:17:11 +0000 (11:17 +0100)]
reap children faster
udevd's event_queue_manager loop is pretty sensitive to the
delays of exiting child processes. I found that it helps boot
times if we try to reap children as quickly as possible.
This patch changes event_queue_manager to call sigchilds_waiting
if it finds a signal has been received.
In certain cut-down situations such as an installer or inside the
initramfs, we simply don't have any kind of name service. While we
could use rules without OWNER or GROUP, it's better to have the same
rules as a full system and have udevd ignore those parts of the rules.
Adds a --resolve-names=never switch to udevd that has this effect.
Olaf Kirch [Tue, 20 Jan 2009 11:49:20 +0000 (12:49 +0100)]
udevd: use ppoll instead of signal pipes
udevd uses a rather old-fashioned way of handling signals
while waiting for input through select (ie by using an unnamed
pipe, to which the signal handler writes one byte for every signal
received). This is rather awkward and may potentially even block
if we receive more signals than the kernel's pipe buffer.
This patch replaces all of that with ppoll, which was designed
for this purpose.
It also removes the SA_RESTART flag from all installed signal
handlers, because otherwise the ppoll call would just be restarted
after handling eg a SIGCHLD.
Kay Sievers [Fri, 16 Jan 2009 20:15:53 +0000 (21:15 +0100)]
cleanup old names before creating the new names
Scott found that the node /dev/pktcdvd can not be replaced by
/dev/pktcdvd/control by changing the rules, and re-trigger the
event. We used to create the new names before we cleaned up the
old ones, which can not work if we need to create subdir with
the same name.
Kay Sievers [Thu, 15 Jan 2009 19:20:16 +0000 (20:20 +0100)]
udevadm: test - remove --force option
Since a while we change the database with a "test" run, but do not update
the node and symlinks. We need to "force" all the time, to keep things
in sync.
Kay Sievers [Fri, 26 Dec 2008 00:41:36 +0000 (01:41 +0100)]
rules: provide /dev/raw/rawctl
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.
Kay Sievers [Mon, 22 Dec 2008 13:58:11 +0000 (14:58 +0100)]
rules: do not put raw1394 in "video" group
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.
Kay Sievers [Sun, 21 Dec 2008 12:01:40 +0000 (13:01 +0100)]
rules: more changes toward Ubuntu rules merge
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
Ryan Thomas [Tue, 9 Dec 2008 00:10:03 +0000 (19:10 -0500)]
rules: add rules for AoE devices
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.
Kay Sievers [Sat, 6 Dec 2008 03:03:08 +0000 (04:03 +0100)]
make: do not delete autotools generated file with distclean
[...] 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.
Kay Sievers [Wed, 3 Dec 2008 00:32:00 +0000 (01:32 +0100)]
rules: fix isdn rules
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.
projects / systemd / log