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 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.
Thanks-To: Tobias Klauser <tklauser@access.unizh.ch>
While crawling through the udev manpage I noticed some typos and other
grammatical errors. English is not my native language, so I'm not sure
if I fixed everything right. I would be glad if any English-speaking
person could check this patch before applying.
Initialize the defaults in udev_config.c instead of namedev.c.
Replace macro by expanded code. Switch to mode_t instead
of string value. Add and clarify some comments.
Remove udev.bus, cause it's currently unused and newer kernels will pass
it in the hotplug environment as PHYSDEVBUS.
Remove udev.action, cause it's unused.
Rename udev_set_values() to udev_init_device().
Add UDEV_LOG to the man udev man page. Remove mention of specific
variables from the udevd/udevsend man page as we changed to pass
the whole environment.
Correct printed Usage: of udevtest and udevinfo.
Init the config in udevtest earlier to accept input with and without
the sysfs mount point.
The /etc/dev.d/input/input.dev was called twice for /dev/input/mouse.
Skip the execution if we get a directory named after the subsystem.
Move UDEV_NO_DEVD where it belongs.
This cuts the size of the binaries, as only objects that
are actually used are linked into the binary:
45592 -> 43608 udev
4380 -> 4380 udevsend
10380 -> 4652 udevd
34732 -> 33100 udevinfo
45432 -> 37208 udevtest
I just noticed that the DEVNAME enviroment variable isn't being set anymore
in udev 0.046 on device removal, while it was being set in 0.042. We're using
the property tto do umount -l <devices> when a block device is removed. Afaik
there is no other way to associate a device with it's DEVNAME on removal ?
Also are there cases where doing umount -l on the removed devices is wrong?
I guess the device is gone, so there is no sense in keeping it mounted (it's
not like the filesystem is gonna come back in a sane state again)..
Attached (trivial) patch brings back the DEVNAME variable on device removal.
