| Age | Commit message (Collapse) | Author |
|---|
|
|
|
itself
|
|
We delay the execution of events if there is already an event running for
the same device, a parent or a child device. "add" events with a reference
to a physical device will also wait for the physical device to finish.
Here we fix the devpath comparison logic to return "busy" only if a complete
device names is matching. /block/sdaa will not longer block a /block/sda event.
|
|
|
|
Define an inititialization phase, where we delay the events only
for a short time to eventually recollect the event sequence instead
of delaying the very first events for 10 seconds, which breaks the
firmware loader.
|
|
If udevsend is called from the commandline the env may be too
big to fit in our buffer and we tag the message.
|
|
|
|
With the "permissions only rules" we can just place:
MODE="0660", OWNER="root", GROUP="root"
at the beginning of the rules file and get exactly the same behavior.
If no values are given the compiled-in defaults are used.
|
|
|
|
On Mon, 2004-12-20 at 15:03 +0100, Marco d'Itri wrote:
> +# all block devices
> > +SUBSYSTEM="block", NAME="%k", GROUP="disk"
> > +
> NAME="%k" here and in similar rules does not add any new information,
> what about making it optional, like it is for SYMLINK-only rules?
|
|
permissions
|
|
|
|
If we take over the hotplug call and manage the events we don't need
to call the event fake script in dev.d/. Just set all expected values
to the new network interface name and call hotplug.d/. This way the
device renaming is completely handled inside of udev and userspace
can't get confused.
|
|
On Sun, 2004-12-19 at 18:31 +0100, Marco d'Itri wrote:
> > On Dec 19, Kay Sievers <kay.sievers@vrfy.org> wrote:
>
> > (Feature request: would it be possible to extend the rules files parser
> > to support continuation lines? I'd like it to consider lines starting
> > with white space as part of the previous line.)
>
> How about the usual backslash at the end of the line. Here is a simple
> patch.
|
|
On Sun, 2004-12-19 at 17:36 +0000, Willem Riede wrote:
Would you mind adding OnStream tape drives?
>
> KERNEL="osst*", NAME="%k", GROUP="tape", MODE="0660"
> KERNEL="nosst*", NAME="%k", GROUP="tape", MODE="0660"
|
|
On Sun, 2004-12-19 at 18:31 +0100, Marco d'Itri wrote:
> It may be better to use default_mode="0660", I do not think that there
> are any mode 600 devices. This would allow setting only the group for
> most of them.
|
|
We have only one source of permissions now, so apply the default
permissions at udev init.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Patch-From: Tobias Klauser <tklauser@access.unizh.ch>
- Move the description of the environment variables to a new section
called "ENVIRONMENT" (as stated in man(7))
- Pointer to the "official" udev homepage
- Fixes for various typos and whitespace damages
|
|
bah, when will I remember to check the extras _before_ I do a release...
|
|
|
|
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=142713
/sbin/udevstart segfaults on an ATIIXP chipset which is not supported
well by the kernel yet. There, /proc/ide/hda/media can not be read
(EIO error) and udevstart seems to give a null-pointer to an SELinux
function checking the media-type.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A hour wrap during the test run does not work :) Just remove
all the useless date conversions as we are only interested in the
seconds it takes to process.
[root@pim udevd-test]# ./udevd-test.pl 9
...
device: /class/tty/console, action: remove
forking udev time: Sat Dec 11 18:59:57 2004
the delay time is: 3 s
device: /class/tty/ptmx, action: remove
forking udev time: Sat Dec 11 19:00:07 2004
the delay time is: 4013 s
the delay time is: 4013
udevd doesn't act properly.
|
|
|
|
|
|
|
|
On Sat, 2004-12-11 at 18:44 +0200, Martin Schlemmer [c] wrote:
>
> Any suggestions to determining the version of the installed udev?
> This is now during startup, to see if we can make use of using
> udevsend as hotplug agent. If the system was up, udevinfo could
> be used, but that is in /usr/bin that might be on a seperate /usr.
> I know we might move udevinfo to /bin, but that might be an issue
> for some, and adding a -V switch to /sbin/udev might be a better
> choice.
|
|
I've found a /dev/video4linux node and just realized, that libsysfs
searches all subdirs for an attribute name.
So it found /class/video4linux/video0/dev for the videodev class
creation event /class/video4linux and created a node.
Just ignore the SUBSYSTEM="class" events now.
|
|
Currently udevd delays only events for the same DEVPATH.
Example of an "add" event sequence:
/block/sda
/block/sda/sda1
With this change, we make sure, that the udev process handling
/block/sda has finished its work (waited for all attributes,
created the node) before we fork the udev event for /block/sda/sda1.
This way the event for sda1 can be sure, that the node for the
main device is already created (may be useful for disk labels).
It will not affect any parallel device handling, only the sequence
of the devices directory chain is serialized. The 10.000 disks
plugged in will still run as parallel events. :)
The main motivation to do this is the program execution of the
dev.d/ and hotplug.d/ directory. If we don't wait for the parent
event to exit, we can't be sure that the executed scripts are
run in the right order.
On Thu, Dec 09, 2004 at 09:18:28AM +0100, Kay Sievers wrote:
> On Wed, 2004-12-08 at 19:07 -0800, David Brownell wrote:
> > Could that argument apply to the underlying hardware, too?
> We now make sure that the sequence of events for a device
> is serialized for every device chain and the class/block
> devices which have a "device" link to a physical device are
> handled after the physical device is fully populated and
> notified to userspace. It will only work this way on kernels
> later than 2.6.10-rc1 cause it depends on the PHYSDEVPATH
> value in the hotplug environment.
|
|
|
|
cuts down the size from:
dynamically linked: 48.030 -> 45.187
statically linked: 149.177 -> 142.362
|
|
|
|
|
