udev 070 not create dvb device

udev 070 not create dvb device

[lukkinosat]

Hi

I have installed udev-070, but the devices (/dev/dvb*)
you do not come created...

kern.log:
Oct 15 15:32:23 vdrbox kernel: saa7146: register
extension 'dvb'.
Oct 15 15:32:23 vdrbox kernel: dvb-ttpci: could not
load firmware, file not found: dvb-ttpci-01.fw
Oct 15 15:32:23 vdrbox kernel: dvb-ttpci: usually this
should be in /usr/lib/hotplug/firmware
Oct 15 15:32:23 vdrbox kernel: dvb-ttpci: and can be
downloaded here
http://www.linuxtv.org/download/dvb/firmware/

The file dvb-ttpci-01.fw exist in /lib/firmware and in
/usr/lib/hotplug/firmware.

I have kernel 2.6.12-5

How I can make?


Tank, Luca


	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev 070 not create dvb device

[Greg KH]

On Sat, Oct 15, 2005 at 04:18:00PM +0200, lukkinosat wrote:
> Hi
> 
> I have installed udev-070, but the devices (/dev/dvb*)
> you do not come created...

Is this on Debian?  What is your standard shell set to?

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev 070 not create dvb device

[lukkinosat]

--- Greg KH <greg@kroah.com> ha scritto: 
> 
> Is this on Debian?  What is your standard shell set
> to?

Hi

I have LFS.
With udev-058 works very well but if I install
udev-070, the dvb devices do not come created....

Tanks, Luca



	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev 070 not create dvb device

[Alexander E. Patrakov]

lukkinosat wrote:

>Hi
>
>I have LFS.
>With udev-058 works very well but if I install
>udev-070, the dvb devices do not come created....
>  
>
Upgrade the kernel if you want to use new versions of udev.

-- 
Alexander E. Patrakov


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev 070 not create dvb device

[lukkinosat]

--- "Alexander E. Patrakov" <patrakov@ums.usu.ru> ha
scritto: 
> lukkinosat wrote:
> Upgrade the kernel if you want to use new versions
> of udev.

Hi

I have upgrade the kernel to 2.6.13.4 version, but
with udev > 058 not create dvb devices...

It can depend on the compiler? I use gcc-4.0.1

Tanks, Luca


	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev 070 not create dvb device

[Alexander E. Patrakov]

lukkinosat wrote:

>--- "Alexander E. Patrakov" <patrakov@ums.usu.ru> ha
>scritto: 
>  
>
>>lukkinosat wrote:
>>Upgrade the kernel if you want to use new versions
>>of udev.
>>    
>>
>
>Hi
>
>I have upgraded the kernel to 2.6.13.4 version, but
>udev > 058 does not create dvb devices...
>  
>
Do the devices appear if you manually modprobe the relevant kernel 
modules and then run the "udevstart" command?

>Can it depend on the compiler? I use gcc-4.0.1
>  
>
It shouldn't.

-- 
Alexander E. Patrakov


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev 070 not create dvb device

[lukkinosat]

--- "Alexander E. Patrakov" <patrakov@ums.usu.ru>
wrote: 

> Do the devices appear if you manually modprobe the
> relevant kernel 
> modules and then run the "udevstart" command?

Nothing devices is creating...


vdrbox#: modprobe dvb-ttpci
vdrbox#: cat /var/log/sys.log

Oct 23 08:48:12 vdrbox udevd[865]: msg_queue_insert:
seq 961 queued, 'add' '/module/ttpci_eeprom'
Oct 23 08:48:12 vdrbox udevd[865]: udev_event_run: seq
961 forked, pid [2904], 'add' 'module', 0 seconds old
Oct 23 08:48:12 vdrbox udevd[865]: udev_done: seq 961,
pid [2904] exit, 0 seconds old
Oct 23 08:48:12 vdrbox udevd[865]: get_udevd_msg:
udevd event message received
Oct 23 08:48:12 vdrbox udevd[865]: main: skip
uevent_helper message with SEQNUM, netlink is active
Oct 23 08:48:12 vdrbox udevd[865]: msg_queue_insert:
seq 962 queued, 'add' '/module/ves1x93'
Oct 23 08:48:12 vdrbox udevd[865]: udev_event_run: seq
962 forked, pid [2906], 'add' 'module', 0 seconds old
Oct 23 08:48:12 vdrbox udevd[865]: udev_done: seq 962,
pid [2906] exit, 0 seconds old
Oct 23 08:48:12 vdrbox udevd[865]: get_udevd_msg:
udevd event message received
Oct 23 08:48:12 vdrbox udevd[865]: main: skip
uevent_helper message with SEQNUM, netlink is active
Oct 23 08:48:12 vdrbox udevd[865]: msg_queue_insert:
seq 963 queued, 'add' '/module/sp8870'
Oct 23 08:48:12 vdrbox udevd[865]: udev_event_run: seq
963 forked, pid [2908], 'add' 'module', 0 seconds old
Oct 23 08:48:12 vdrbox udevd[865]: get_udevd_msg:
udevd event message received
Oct 23 08:48:12 vdrbox udevd[865]: main: skip
uevent_helper message with SEQNUM, netlink is active
Oct 23 08:48:12 vdrbox udevd[865]: msg_queue_insert:
seq 964 queued, 'add' '/module/stv0297'
Oct 23 08:48:12 vdrbox udevd[865]: udev_done: seq 963,
pid [2908] exit, 0 seconds old
Oct 23 08:48:12 vdrbox udevd[865]: udev_event_run: seq
964 forked, pid [2922], 'add' 'module', 0 seconds old
Oct 23 08:48:12 vdrbox udevd[865]: get_udevd_msg:
udevd event message received
Oct 23 08:48:12 vdrbox udevd[865]: main: skip
uevent_helper message with SEQNUM, netlink is active
Oct 23 08:48:12 vdrbox udevd[865]: msg_queue_insert:
seq 965 queued, 'add' '/module/tda8083'
Oct 23 08:48:12 vdrbox udevd[865]: udev_done: seq 964,
pid [2922] exit, 0 seconds old
Oct 23 08:48:12 vdrbox udevd[865]: udev_event_run: seq
965 forked, pid [2923], 'add' 'module', 0 seconds old
Oct 23 08:48:12 vdrbox udevd[865]: get_udevd_msg:
udevd event message received
Oct 23 08:48:12 vdrbox udevd[865]: main: skip
uevent_helper message with SEQNUM, netlink is active
Oct 23 08:48:12 vdrbox udevd[865]: msg_queue_insert:
seq 966 queued, 'add' '/module/stv0299'
Oct 23 08:48:12 vdrbox udevd[865]: udev_done: seq 965,
pid [2923] exit, 0 seconds old
Oct 23 08:48:12 vdrbox udevd[865]: udev_event_run: seq
966 forked, pid [2924], 'add' 'module', 0 seconds old
Oct 23 08:48:12 vdrbox udevd[865]: get_udevd_msg:
udevd event message received
Oct 23 08:48:12 vdrbox udevd[865]: main: skip
uevent_helper message with SEQNUM, netlink is active
Oct 23 08:48:12 vdrbox udevd[865]: msg_queue_insert:
seq 967 queued, 'add' '/module/ves1820'
Oct 23 08:48:12 vdrbox udevd[865]: udev_done: seq 966,
pid [2924] exit, 0 seconds old
Oct 23 08:48:12 vdrbox udevd[865]: udev_event_run: seq
967 forked, pid [2925], 'add' 'module', 0 seconds old
Oct 23 08:48:12 vdrbox udevd[865]: get_udevd_msg:
udevd event message received
Oct 23 08:48:12 vdrbox udevd[865]: main: skip
uevent_helper message with SEQNUM, netlink is active
Oct 23 08:48:12 vdrbox udevd[865]: msg_queue_insert:
seq 968 queued, 'add' '/module/saa7146'
Oct 23 08:48:12 vdrbox udevd[865]: udev_done: seq 967,
pid [2925] exit, 0 seconds old
Oct 23 08:48:12 vdrbox udevd[865]: udev_event_run: seq
968 forked, pid [2926], 'add' 'module', 0 seconds old
Oct 23 08:48:12 vdrbox udevd[865]: get_udevd_msg:
udevd event message received
Oct 23 08:48:12 vdrbox udevd[865]: main: skip
uevent_helper message with SEQNUM, netlink is active
Oct 23 08:48:12 vdrbox udevd[865]: msg_queue_insert:
seq 969 queued, 'add' '/module/video_buf'
Oct 23 08:48:12 vdrbox udevd[865]: udev_done: seq 968,
pid [2926] exit, 0 seconds old
Oct 23 08:48:12 vdrbox udevd[865]: udev_event_run: seq
969 forked, pid [2927], 'add' 'module', 0 seconds old
Oct 23 08:48:12 vdrbox udevd[865]: get_udevd_msg:
udevd event message received
Oct 23 08:48:12 vdrbox udevd[865]: main: skip
uevent_helper message with SEQNUM, netlink is active
Oct 23 08:48:12 vdrbox udevd[865]: msg_queue_insert:
seq 970 queued, 'add' '/module/saa7146_vv'
Oct 23 08:48:12 vdrbox udevd[865]: udev_done: seq 969,
pid [2927] exit, 0 seconds old
Oct 23 08:48:12 vdrbox udevd[865]: udev_event_run: seq
970 forked, pid [2928], 'add' 'module', 0 seconds old
Oct 23 08:48:12 vdrbox udevd[865]: get_udevd_msg:
udevd event message received
Oct 23 08:48:12 vdrbox udevd[865]: main: skip
uevent_helper message with SEQNUM, netlink is active
Oct 23 08:48:12 vdrbox udevd[865]: msg_queue_insert:
seq 971 queued, 'add' '/module/l64781'
Oct 23 08:48:12 vdrbox udevd[865]: udev_done: seq 970,
pid [2928] exit, 0 seconds old
Oct 23 08:48:12 vdrbox udevd[865]: udev_event_run: seq
971 forked, pid [2929], 'add' 'module', 0 seconds old
Oct 23 08:48:12 vdrbox udevd[865]: get_udevd_msg:
udevd event message received
Oct 23 08:48:12 vdrbox udevd[865]: main: skip
uevent_helper message with SEQNUM, netlink is active
Oct 23 08:48:12 vdrbox udevd[865]: msg_queue_insert:
seq 972 queued, 'add' '/module/dvb_core'
Oct 23 08:48:12 vdrbox udevd[865]: udev_done: seq 971,
pid [2929] exit, 0 seconds old
Oct 23 08:48:12 vdrbox udevd[865]: udev_event_run: seq
972 forked, pid [2930], 'add' 'module', 0 seconds old
Oct 23 08:48:12 vdrbox udevd[865]: get_udevd_msg:
udevd event message received
Oct 23 08:48:12 vdrbox udevd[865]: main: skip
uevent_helper message with SEQNUM, netlink is active
Oct 23 08:48:12 vdrbox udevd[865]: msg_queue_insert:
seq 973 queued, 'add' '/module/dvb_ttpci'
Oct 23 08:48:12 vdrbox udevd[865]: udev_done: seq 972,
pid [2930] exit, 0 seconds old
Oct 23 08:48:12 vdrbox udevd[865]: udev_event_run: seq
973 forked, pid [2931], 'add' 'module', 0 seconds old
Oct 23 08:48:12 vdrbox udevd[865]: get_udevd_msg:
udevd event message received
Oct 23 08:48:12 vdrbox udevd[865]: main: skip
uevent_helper message with SEQNUM, netlink is active
Oct 23 08:48:12 vdrbox udevd[865]: msg_queue_insert:
seq 974 queued, 'add' '/bus/pci/drivers/dvb'
Oct 23 08:48:12 vdrbox udevd[865]: udev_done: seq 973,
pid [2931] exit, 0 seconds old
Oct 23 08:48:12 vdrbox udevd[865]: udev_event_run: seq
974 forked, pid [2932], 'add' 'drivers', 0 seconds old
Oct 23 08:48:12 vdrbox udevd[865]: get_udevd_msg:
udevd event message received
Oct 23 08:48:12 vdrbox udevd[865]: main: skip
uevent_helper message with SEQNUM, netlink is active
Oct 23 08:48:12 vdrbox udevd[865]: msg_queue_insert:
seq 975 queued, 'add' '/class/firmware/0000:02:07.0'
Oct 23 08:48:12 vdrbox udevd[865]: udev_done: seq 974,
pid [2932] exit, 0 seconds old
Oct 23 08:48:12 vdrbox udevd[865]: udev_event_run: seq
975 forked, pid [2933], 'add' 'firmware', 0 seconds
old
Oct 23 08:48:12 vdrbox udevd[865]: get_udevd_msg:
udevd event message received
Oct 23 08:48:12 vdrbox udevd[865]: main: skip
uevent_helper message with SEQNUM, netlink is active
Oct 23 08:48:12 vdrbox udevd[865]: udev_done: seq 975,
pid [2933] exit, 0 seconds old
Oct 23 08:48:12 vdrbox kernel: saa7146: register
extension 'dvb'.
Oct 23 08:48:12 vdrbox kernel: ACPI: PCI Interrupt
0000:02:07.0[A] -> Link [LNK4] -> GSI 5 (level, low)
-> IRQ 5
Oct 23 08:48:12 vdrbox kernel: saa7146: found saa7146
@ mem d0936000 (revision 1, irq 5) (0x13c2,0x0003).
Oct 23 08:48:22 vdrbox udevd[865]: msg_queue_insert:
seq 976 queued, 'remove'
'/class/firmware/0000:02:07.0'
Oct 23 08:48:22 vdrbox udevd[865]: udev_event_run: seq
976 forked, pid [2934], 'remove' 'firmware', 0 seconds
old
Oct 23 08:48:22 vdrbox udevd[865]: udev_done: seq 976,
pid [2934] exit, 0 seconds old
Oct 23 08:48:22 vdrbox udevd[865]: get_udevd_msg:
udevd event message received
Oct 23 08:48:22 vdrbox udevd[865]: main: skip
uevent_helper message with SEQNUM, netlink is active
Oct 23 08:48:22 vdrbox kernel: dvb-ttpci: could not
load firmware, file not found: dvb-ttpci-01.fw
Oct 23 08:48:22 vdrbox kernel: dvb-ttpci: usually this
should be in /usr/lib/hotplug/firmware
Oct 23 08:48:22 vdrbox kernel: dvb-ttpci: and can be
downloaded here
http://www.linuxtv.org/download/dvb/firmware/
Oct 23 08:48:22 vdrbox kernel: ACPI: PCI interrupt for
device 0000:02:07.0 disabled


This is the log with udev 071... you it even can be
than aid..

Hi, Luca
Tanks



	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev 070 not create dvb device

[Kay Sievers]

On Sun, Oct 23, 2005 at 09:01:09AM +0200, lukkinosat wrote:
> --- "Alexander E. Patrakov" <patrakov@ums.usu.ru>
> wrote: 
> 
> > Do the devices appear if you manually modprobe the
> > relevant kernel 
> > modules and then run the "udevstart" command?
> 
> Nothing devices is creating...
> Oct 23 08:48:22 vdrbox kernel: dvb-ttpci: could not
> load firmware, file not found: dvb-ttpci-01.fw
> Oct 23 08:48:22 vdrbox kernel: dvb-ttpci: usually this
> should be in /usr/lib/hotplug/firmware
> Oct 23 08:48:22 vdrbox kernel: dvb-ttpci: and can be
> downloaded here
> http://www.linuxtv.org/download/dvb/firmware/

Seems you miss the firmware for the device.
Just put all firmware files in /lib/firmware/.

Kay


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev 070 not create dvb device

[lukkinosat]

--- Kay Sievers <kay.sievers@vrfy.org> wrote: 
> Seems you miss the firmware for the device.
> Just put all firmware files in /lib/firmware/.

Hi

In /lib/firmware there is the file dvb-ttpci-01.fw and
with udev-058 it works, but with udev > 058 nothing
:-(

Thanks to all for the aid.

Luca


		
___________________________________ 
Yahoo! Messenger: chiamate gratuite in tutto il mondo 
http://it.messenger.yahoo.com


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev 070 not create dvb device

[Kay Sievers]

On Mon, Oct 24, 2005 at 08:31:29AM +0200, lukkinosat wrote:
> --- Kay Sievers <kay.sievers@vrfy.org> wrote: 
> > Seems you miss the firmware for the device.
> > Just put all firmware files in /lib/firmware/.
> 
> Hi
> 
> In /lib/firmware there is the file dvb-ttpci-01.fw and
> with udev-058 it works, but with udev > 058 nothing
> :-(

Then the firmware loading program/script may be broken, not to
look there or not to run at all.

How does your distro handle firmware loading? Is there a udev
rule for it? What is run at firmware events?

Kay


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev 070 not create dvb device

[Alexander E. Patrakov]

lukkinosat wrote:

>--- Kay Sievers <kay.sievers@vrfy.org> wrote: 
>  
>
>>Seems you miss the firmware for the device.
>>Just put all firmware files in /lib/firmware/.
>>    
>>
>
>Hi
>
>In /lib/firmware there is the file dvb-ttpci-01.fw and
>with udev-058 it works, but with udev > 058 nothing
>:-(
>  
>
LFS udev/hotplug setup is horribly broken wrt running handlers for 
firmware/module loading for at least three weeks since my report:

http://www.mail-archive.com/lfs-dev@linuxfromscratch.org/msg03236.html

I seriously recommend forgetting the distro that doesn't fix its current 
known bugs with known fix but instead plans (without much understanding 
of the underlying mechanisms) to remove the hotplug package. IMHO that 
would be too early before upstream provides a patchless way to do so, 
approves it in the documentation and doesn't mark it as obsolete for at 
least a month. In the meanwhile, you can fix it by rebuilding udev with 
the following instructions:

# udev-071 required because of the bug in 070 Makefile

make EXTRAS=extras/run_directory/
make EXTRAS=extras/run_directory/ install
cp ../udev-config-4.rules /etc/udev/rules.d/25-lfs.rules
echo 'ENV{UDEVD_EVENT}="1", RUN+="/sbin/udev_run_hotplugd"' >>/etc/udev/rules.d/25-lfs.rules
echo 'RUN+="/sbin/udev_run_devd"' >>/etc/udev/rules.d/25-lfs.rules
install -m644 -D docs/writing_udev_rules/index.html \
         /usr/share/doc/udev-071/index.html


The setup above is known obsolete but works. You can use a more modern 
approach for firmware loading,

make EXTRAS=extras/firmware/
make EXTRAmake EXTRAS=extras/firmware/ install
cp ../udev-config-4.rules /etc/udev/rules.d/25-lfs.rules
echo 'ACTION="add", SUBSYSTEM="firmware", ENV{FIRMWARE}="*", RUN+="/sbin/firmware_helper"' >>/etc/udev/rules.d/25-lfs.rules
install -m644 -D docs/writing_udev_rules/index.html \
         /usr/share/doc/udev-071/index.html


That will not load modules for hotplug events out of the box. See 
examples that contain the "MODALIAS" and "modprobe" words in the example 
RedHat udev rules distributed with the udev package. But that's far 
ahead of what LFS does now :)

-- 
Alexander E. Patrakov


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev 070 not create dvb device

[Matthew Burgess]

Alexander E. Patrakov wrote:

> LFS udev/hotplug setup is horribly broken wrt running handlers for 
> firmware/module loading for at least three weeks since my report:
> 
> http://www.mail-archive.com/lfs-dev@linuxfromscratch.org/msg03236.html
> 
> I seriously recommend forgetting the distro that doesn't fix its current 
> known bugs with known fix but instead plans (without much understanding 
> of the underlying mechanisms) to remove the hotplug package.

Alexander, I'd prefer you refrain from berating the LFS project on a 
non-LFS list (obviously I'd rather you don't berate the project at all, 
but at least if you're going to do it, do it where the LFS community can 
be reasonably expected to see and comment on it).

Secondly, as with any open source project, it's a *voluntary* effort. 
I've already made some efforts to outline the general direction I want 
to see LFS head with regards to device and module handling.  The fact 
that I don't understand all (perhaps any?) of how this stuff works is 
completely excusable - the current documentation for hotplugless setup 
is non-existent as far as I can tell.  It relies on searching mailing 
list archives and such like, and doing so is fraught with the 
difficulties of stumbling across out of date or otherwise inaccurate 
information.

However, as you obviously have all the requisite knowledge about this, 
how about *you* document it, submit that as a patch to the udev project, 
then LFS (and other distros too) can act based on the information it 
provides?  If the documentation could provide examples of both an initrd 
and initrd-less configuration (if that is in fact possible, bugs 
notwithstanding), that'd be great.

Regards,

Matt.


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev 070 not create dvb device

[Alexander E. Patrakov]

Matthew Burgess wrote:
> Secondly, as with any open source project, it's a *voluntary* effort.
> I've already made some efforts to outline the general direction I want
> to see LFS head with regards to device and module handling.  The fact
> that I don't understand all (perhaps any?) of how this stuff works is
> completely excusable - the current documentation for hotplugless setup
> is non-existent as far as I can tell.  It relies on searching mailing
> list archives and such like, and doing so is fraught with the
> difficulties of stumbling across out of date or otherwise inaccurate
> information.

That's because such ready-made initramfs-free hotplug-less setup doesn't exist 
yet. Debian uses patched usevsynthesize, but Kay Sievers said that he won't 
continue this direction (because it is impossible to reproduce environment 
variables from real hotplug events 100% accurately based on sysfs information 
only).

> However, as you obviously have all the requisite knowledge about this,
> how about *you* document it, submit that as a patch to the udev project,
> then LFS (and other distros too) can act based on the information it
> provides?  If the documentation could provide examples of both an initrd
> and initrd-less configuration (if that is in fact possible, bugs
> notwithstanding), that'd be great.

I will do so only if upstream welcomes that. I am not going to document what 
will vanish or completely change in a month. Upstream is in the process of 
finding a really good solution.

For initramfs-less part, the basic setup is very simple:

1) Apply kernel patch from 
http://marc.theaimsgroup.com/?l=linux-hotplug-devel&m\x112828738301128&w=2

Caveat: this patch is AFAIK not even in -mm.

2) Remove udevstart and coldplug initscripts, replace it with the shell script 
from the top of the same message.

3) Optionally, upgrade module-init-tools if you want blacklist support.

4) Add MODALIAS and firmware rules similar to those from RedHat example file.

5) (BUG) make sure that /dev/hda1 is created before a bootscript attempts to 
check the filesystem. There is some file in sysfs (forgot its name and this 
mail writing from 2.4 so can't check) that holds the sequence number of the 
last hotplug event. Maybe this file should be polled and the boot process 
should continue only if there were no changes in 5 seconds.

-- 
Alexander E. Patrakov


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev 070 not create dvb device

[lukkinosat]

--- "Alexander E. Patrakov" <patrakov@ums.usu.ru>
wrote: 
> # udev-071 required because of the bug in 070
> Makefile
> 
> make EXTRAS=extras/run_directory/
> make EXTRAS=extras/run_directory/ install
> cp ../udev-config-4.rules
> /etc/udev/rules.d/25-lfs.rules
> echo 'ENV{UDEVD_EVENT}="1",
> RUN+="/sbin/udev_run_hotplugd"'
> >>/etc/udev/rules.d/25-lfs.rules
> echo 'RUN+="/sbin/udev_run_devd"'
> >>/etc/udev/rules.d/25-lfs.rules
> install -m644 -D docs/writing_udev_rules/index.html
> \
>          /usr/share/doc/udev-071/index.html


Now it works :-)))

Thanks to all

Luca


	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev 070 not create dvb device

[Alexander E. Patrakov]

I wrote:

>5) (BUG) make sure that /dev/hda1 is created before a bootscript attempts to 
>check the filesystem. There is some file in sysfs (forgot its name and this 
>mail writing from 2.4 so can't check) that holds the sequence number of the 
>last hotplug event. Maybe this file should be polled and the boot process 
>should continue only if there were no changes in 5 seconds.
>  
>
5a) The file is /sys/kernel/hotplug_seqnum
5b) Polling it doesn't really help because it only tells when the kernel 
gave the hotplug event to udev, but not when udev finished processing 
this event.

So I know no workarount for this bug except an unconditional long sleep 
(preferrably with configurable length for compatibility with bochs and 
qemu).
-- 
Alexander E. Patrakov



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev 070 not create dvb device

[Greg KH]

On Wed, Oct 26, 2005 at 01:46:40PM +0600, Alexander E. Patrakov wrote:
> 1) Apply kernel patch from 
> http://marc.theaimsgroup.com/?l=linux-hotplug-devel&m\x112828738301128&w=2
> 
> Caveat: this patch is AFAIK not even in -mm.

Yes it is in -mm, and will be in 2.6.15.

The main thing you are forgetting is the fact that the kernel's input
subsystem doesn't properly interact with the hotplug system.  There are
patches in -mm for that too, but you will need them in order to
fully switch over to using udev for all hotplug stuff.  If you don't
have that, it will not work properly.

good luck,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev 070 not create dvb device

[Greg KH]

On Wed, Oct 26, 2005 at 01:46:40PM +0600, Alexander E. Patrakov wrote:
> 5) (BUG) make sure that /dev/hda1 is created before a bootscript attempts to 
> check the filesystem. There is some file in sysfs (forgot its name and this 
> mail writing from 2.4 so can't check) that holds the sequence number of the 
> last hotplug event. Maybe this file should be polled and the boot process 
> should continue only if there were no changes in 5 seconds.

Heh, that will not work.  What about the drivers that wait 5 seconds in
their probe functions before doing device discovery?  Seriously, we have
them...

Only thing waiting 5 seconds would tell you is that nothing has changed
in 5 seconds, not that you are finished doing anything.

Why not just do what every other distro does and do the udevstart-like
stuff before checking any filesystems...

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev 070 not create dvb device

[Kay Sievers]

On Wed, Oct 26, 2005 at 06:32:54PM +0600, Alexander E. Patrakov wrote:
> I wrote:
> 
> >5) (BUG) make sure that /dev/hda1 is created before a bootscript attempts 
> >to check the filesystem. There is some file in sysfs (forgot its name and 
> >this mail writing from 2.4 so can't check) that holds the sequence number 
> >of the last hotplug event. Maybe this file should be polled and the boot 
> >process should continue only if there were no changes in 5 seconds.
> > 
> >
> 5a) The file is /sys/kernel/hotplug_seqnum
> 5b) Polling it doesn't really help because it only tells when the kernel 
> gave the hotplug event to udev, but not when udev finished processing 
> this event.

You may try something stupid like this:

  while [ $(cat /proc/*/status 2> /dev/null | grep -c -E '^Name:.udevd?$') -gt 1 ]; do
      sleep 0.1
  done

Good luck,
Kay


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev 070 not create dvb device

[Olivier Blin]

Matthew Burgess <matthew@linuxfromscratch.org> writes:

> Secondly, as with any open source project, it's a *voluntary* effort. 
> I've already made some efforts to outline the general direction I want 
> to see LFS head with regards to device and module handling.  The fact 
> that I don't understand all (perhaps any?) of how this stuff works is 
> completely excusable - the current documentation for hotplugless setup 
> is non-existent as far as I can tell.  It relies on searching mailing 
> list archives and such like, and doing so is fraught with the 
> difficulties of stumbling across out of date or otherwise inaccurate 
> information.

I've written a summary of the migration process to udev in Mandriva
2006: http://qa.mandriva.com/twiki/bin/view/Main/Udev
Most of the tweaks are quite specific (coldplug patches in udevstart),
but you may find some hints.

Regards

-- 
Olivier Blin
Mandriva



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev 070 not create dvb device

[Alexander E. Patrakov]

Kay Sievers wrote:

>You may try something stupid like this:
>
>  while [ $(cat /proc/*/status 2> /dev/null | grep -c -E '^Name:.udevd?$') -gt 1 ]; do
>      sleep 0.1
>  done
>  
>
1) This can be simplified to:

while pidof udevd | grep -q " " ; do
      sleep 0.1
done


2) Greg KH said to stick with (synchronous) udevstart for now, and I 
agree with him here. But there's your comment at 
http://bugs.debian.org/329226

>That's one of the problems with a synchronous udevstart. It should go
>away for a lot of other reasons too and I refused all the "coldplug"
>patches for udevstart for that reason.
>  
>
That seems to be in disagreement with Greg's words. Is that viewpoint 
obsolete? Or are there still plans to drop synchronous udevstart and 
make this "pidof" hack (or something equivalent) the official 
recommended solution?

-- 
Alexander E. Patrakov


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev 070 not create dvb device

[Kay Sievers]

On Thu, Oct 27, 2005 at 10:28:54AM +0600, Alexander E. Patrakov wrote:
> Kay Sievers wrote:
> 
> >You may try something stupid like this:
> >
> > while [ $(cat /proc/*/status 2> /dev/null | grep -c -E '^Name:.udevd?$') 
> > -gt 1 ]; do
> >     sleep 0.1
> > done
> > 
> >
> 1) This can be simplified to:
> 
> while pidof udevd | grep -q " " ; do
>      sleep 0.1
> done

No, that will not catch the "udev" processes. We need to catch both,
cause only the "rules-in-daemon" patch forks "udevd" processes.

> 2) Greg KH said to stick with (synchronous) udevstart for now, and I 
> agree with him here. But there's your comment at 
> http://bugs.debian.org/329226
> 
> >That's one of the problems with a synchronous udevstart. It should go
> >away for a lot of other reasons too and I refused all the "coldplug"
> >patches for udevstart for that reason.
> > 
> >
> That seems to be in disagreement with Greg's words. Is that viewpoint 
> obsolete?

No, thats fine. It depends on how you set-up your booting and it's a safe way
to do it for now.

> Or are there still plans to drop synchronous udevstart

Sure, I'm currently working on a sysfs triggered, kernel based hotplug:
  http://www.kernel.org/git/?p=linux/kernel/git/gregkh/patches.git;a=blob;hb=HEAD;f=driver/coldplug-emit-hotplug-events-from-sysfs.patch

> and make this "pidof" hack (or something equivalent) the official 
> recommended solution?

We'll see ...

Kay


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev 070 not create dvb device

[Alexander E. Patrakov]

Kay Sievers wrote:

>On Thu, Oct 27, 2005 at 10:28:54AM +0600, Alexander E. Patrakov wrote:
>  
>
>>Kay Sievers wrote:
>>
>>    
>>
>>>You may try something stupid like this:
>>>
>>>while [ $(cat /proc/*/status 2> /dev/null | grep -c -E '^Name:.udevd?$') 
>>>-gt 1 ]; do
>>>    sleep 0.1
>>>done
>>>
>>>
>>>      
>>>
>>1) This can be simplified to:
>>
>>while pidof udevd | grep -q " " ; do
>>     sleep 0.1
>>done
>>    
>>
>
>No, that will not catch the "udev" processes. We need to catch both,
>cause only the "rules-in-daemon" patch forks "udevd" processes.
>  
>
Then:

while pidof udev udevd | grep -q " " ; do
     sleep 0.1
done

:)

>>2) Greg KH said to stick with (synchronous) udevstart for now, and I 
>>agree with him here. But there's your comment at 
>>http://bugs.debian.org/329226
>>
>>    
>>
>>>That's one of the problems with a synchronous udevstart. It should go
>>>away for a lot of other reasons too and I refused all the "coldplug"
>>>patches for udevstart for that reason.
>>>
>>>
>>>      
>>>
>>That seems to be in disagreement with Greg's words. Is that viewpoint 
>>obsolete?
>>    
>>
>
>No, thats fine. It depends on how you set-up your booting and it's a safe way
>to do it for now.
>  
>
OK. I see: for now, the recommended and safe way to populate /dev is to 
run udevstart.

>>Or are there still plans to drop synchronous udevstart
>>    
>>
>
>Sure, I'm currently working on a sysfs triggered, kernel based hotplug:
>  http://www.kernel.org/git/?p=linux/kernel/git/gregkh/patches.git;a=blob;hb=HEAD;f=driver/coldplug-emit-hotplug-events-from-sysfs.patch
>
>  
>
Thanks, now I know where to get the latest version of this patch.

>>and make this "pidof" hack (or something equivalent) the official 
>>recommended solution?
>>    
>>
>
>We'll see ...
>  
>
I interpret that as "nothing better has been invented yet for use with 
that patch but this situation may change". Am I right?

Anyway, I think that the following will work safely enough if one 
ignores the input subsystem:

1. Apply that kernel patch, add udev rules for modaliases and firmware, 
build the relevant extras. Install updated module-init-tools for 
blacklist support. Do not install hotplug.
2. In S00mountkernfs initscript, mount /proc and /sys as usual.
3. In S10udev initscript, mount tmpfs on /dev, run "UDEV_RUN=0 
/sbin/udevstart" and create additional directories and symlimks in /dev. 
For Matthew: it is the same as the default udev initscript in LFS does, 
but with UDEV_RUN=0.
4. In S40mountfs initscript, mount /usr and the rest of filesystems, as 
usual.
5. In the new S55coldplug-emit initscript (to be used instead of 
S55hotplug), do those echoes to "uevent" files in sysfs. Thus, modules 
will be loaded, devices will be created (yes, udevstart's work 
duplicated) and RUN rules will be also applied.

Benefit for BLFS: those RUN rules will be applied with /usr certainly 
mounted, thus there's no longer any need to wait for /usr in the alsa 
RUN helper.

Kay, could you please look at this and tell if anything is certainly 
wrong/unsafe/bad except for the input subsystem?

-- 
Alexander E. Patrakov


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev 070 not create dvb device

[Marco d'Itri]

On Oct 27, "Alexander E. Patrakov" <patrakov@ums.usu.ru> wrote:

> Anyway, I think that the following will work safely enough if one 
> ignores the input subsystem:
For a fully working recipe, look at the debian package.
It currently uses a patched udevsynthesize, but it will be trivial to
switch later to the kernel-based coldplugging method.

> Benefit for BLFS: those RUN rules will be applied with /usr certainly 
> mounted, thus there's no longer any need to wait for /usr in the alsa 
> RUN helper.
Not worth the trouble IMO, it's easier to wait for /usr.

-- 
ciao,
Marco


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev 070 not create dvb device

[Alexander E. Patrakov]

I wrote:

> Anyway, I think that the following will work safely enough if one 
> ignores the input subsystem:
>
> 1. Apply that kernel patch, add udev rules for modaliases and 
> firmware, build the relevant extras. Install updated module-init-tools 
> for blacklist support. Do not install hotplug.
> 2. In S00mountkernfs initscript, mount /proc and /sys as usual.
> 3. In S10udev initscript, mount tmpfs on /dev, run "UDEV_RUN=0 
> /sbin/udevstart" and create additional directories and symlimks in 
> /dev. For Matthew: it is the same as the default udev initscript in 
> LFS does, but with UDEV_RUN=0.
> 4. In S40mountfs initscript, mount /usr and the rest of filesystems, 
> as usual.
> 5. In the new S55coldplug-emit initscript (to be used instead of 
> S55hotplug), do those echoes to "uevent" files in sysfs. Thus, modules 
> will be loaded, devices will be created (yes, udevstart's work 
> duplicated) and RUN rules will be also applied.
>
> Benefit for BLFS: those RUN rules will be applied with /usr certainly 
> mounted, thus there's no longer any need to wait for /usr in the alsa 
> RUN helper.
>
> Kay, could you please look at this and tell if anything is certainly 
> wrong/unsafe/bad except for the input subsystem?

Already found, sorry for the noise: eth0 fails to be brought up. No way 
around this proc/pidof hack.

-- 
Alexander E. Patrakov



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev 070 not create dvb device

[Alexander E. Patrakov]

Marco d'Itri wrote:

>On Oct 27, "Alexander E. Patrakov" <patrakov@ums.usu.ru> wrote:
>  
>
>>Anyway, I think that the following will work safely enough if one 
>>ignores the input subsystem:
>>    
>>
>For a fully working recipe, look at the debian package.
>  
>
Done, thanks.

>It currently uses a patched udevsynthesize, but it will be trivial to
>switch later to the kernel-based coldplugging method.
>  
>
I see that you essentially use the same shell script that Kay pasted: 
the script waits for the time when there remains only one instance of 
udevd and no "udev". Note taken, it only remains to compare that with 
Greg's words.

Is there any rationale for choosing a 8-seconds value for the default 
timeout?

As for input, I see that you just unconditionally modprobe the most 
frequently used "undetectable" modules (evdev and mousedev).

>>Benefit for BLFS: those RUN rules will be applied with /usr certainly 
>>mounted, thus there's no longer any need to wait for /usr in the alsa 
>>RUN helper.
>>    
>>
>Not worth the trouble IMO, it's easier to wait for /usr.
>  
>
Here one of the editors specifically requested that comments about what 
is going on are added to the loop (because the whole concept of waiting 
for /usr is new and non-obvious), you can see them at 
http://www.linuxfromscratch.org/blfs/view/svn/multimedia/alsa-utils.html

And as you see, that page is still incorrect now (i.e. waiting for /usr 
is hard to get right). Of course when the "sleep at the top" and 
"/usr/bin/expr" bugs are fixed, this will be a good template for other 
BLFS packages, should they need a RUN+=... rule.

So I think I should let people decide (maybe vote) in (B)LFS for themselves.

-- 
Alexander E. Patrakov


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev 070 not create dvb device

[Marco d'Itri]

On Oct 27, "Alexander E. Patrakov" <patrakov@ums.usu.ru> wrote:

> I see that you essentially use the same shell script that Kay pasted: 
Guess where he did get it... :-)

> the script waits for the time when there remains only one instance of 
> udevd and no "udev". Note taken, it only remains to compare that with 
No, check again the regexp: it waits for udev too.

> Is there any rationale for choosing a 8-seconds value for the default 
> timeout?
I did some tests and looked at the bug reports from users, it should be
enough for all but the slowest systems.

> And as you see, that page is still incorrect now (i.e. waiting for /usr 
> is hard to get right). Of course when the "sleep at the top" and 
I can't see why it would be hard. I even provide the code in
hotplug.functions.

-- 
ciao,
Marco


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev 070 not create dvb device

[Kay Sievers]

On Thu, Oct 27, 2005 at 08:48:10PM +0600, Alexander E. Patrakov wrote:
> Kay Sievers wrote:
> >On Thu, Oct 27, 2005 at 10:28:54AM +0600, Alexander E. Patrakov wrote:
> >>Kay Sievers wrote:
> >>
> >>>You may try something stupid like this:
> >>>
> >>>while [ $(cat /proc/*/status 2> /dev/null | grep -c -E '^Name:.udevd?$') 
> >>>-gt 1 ]; do
> >>>   sleep 0.1
> >>>done
> >>>
> >>1) This can be simplified to:
> >>
> >>while pidof udevd | grep -q " " ; do
> >>    sleep 0.1
> >>done
> >
> >No, that will not catch the "udev" processes. We need to catch both,
> >cause only the "rules-in-daemon" patch forks "udevd" processes.
> >
> Then:
> 
> while pidof udev udevd | grep -q " " ; do
>     sleep 0.1
> done
> 
> :)
> 
> >>2) Greg KH said to stick with (synchronous) udevstart for now, and I 
> >>agree with him here. But there's your comment at 
> >>http://bugs.debian.org/329226
> >>
> >>>That's one of the problems with a synchronous udevstart. It should go
> >>>away for a lot of other reasons too and I refused all the "coldplug"
> >>>patches for udevstart for that reason.
> >>>
> >>That seems to be in disagreement with Greg's words. Is that viewpoint 
> >>obsolete?
> >>   
> >No, thats fine. It depends on how you set-up your booting and it's a safe 
> >way
> >to do it for now.
> > 
> OK. I see: for now, the recommended and safe way to populate /dev is to 
> run udevstart.
> 
> >>Or are there still plans to drop synchronous udevstart
> >>   
> >Sure, I'm currently working on a sysfs triggered, kernel based hotplug:
> > http://www.kernel.org/git/?p=linux/kernel/git/gregkh/patches.git;a=blob;hb=HEAD;f=driver/coldplug-emit-hotplug-events-from-sysfs.patch
> >
> Thanks, now I know where to get the latest version of this patch.
> 
> >>and make this "pidof" hack (or something equivalent) the official 
> >>recommended solution?
> >>   
> >We'll see ...
> > 
> >
> I interpret that as "nothing better has been invented yet for use with 
> that patch but this situation may change". Am I right?

I should be easy, as it's almost the same as "udevsynthesize", which
works already good enough.

> Anyway, I think that the following will work safely enough if one 
> ignores the input subsystem:
> 
> 1. Apply that kernel patch, add udev rules for modaliases and firmware, 
> build the relevant extras. Install updated module-init-tools for 
> blacklist support. Do not install hotplug.
> 2. In S00mountkernfs initscript, mount /proc and /sys as usual.
> 3. In S10udev initscript, mount tmpfs on /dev, run "UDEV_RUN=0 
> /sbin/udevstart" and create additional directories and symlimks in /dev. 
> For Matthew: it is the same as the default udev initscript in LFS does, 
> but with UDEV_RUN=0.

I have it running without udevstart. You just need to create a few
nodes. And you need to start the daemon and may want to disable
/sbin/hotplug (if you have the input fixes, or can live without input events)

> 4. In S40mountfs initscript, mount /usr and the rest of filesystems, as 
> usual.
> 5. In the new S55coldplug-emit initscript (to be used instead of 
> S55hotplug), do those echoes to "uevent" files in sysfs. Thus, modules 
> will be loaded, devices will be created (yes, udevstart's work 
> duplicated) and RUN rules will be also applied.
> 
> Benefit for BLFS: those RUN rules will be applied with /usr certainly 
> mounted, thus there's no longer any need to wait for /usr in the alsa 
> RUN helper.
> 
> Kay, could you please look at this and tell if anything is certainly 
> wrong/unsafe/bad except for the input subsystem?

Well, we are in the middle of finding that out. It was a long way,
SUSE today stores all events in initramfs to be replayed after the root
is mounted. That works pretty well so far, but the "uevent" trigger by
sysfs sounds nicer, cause it works with every kernel and without a
special prepared initramfs.
We'll see, nobody knows how exactly it will look like, but it already
looks better than everthing we've had in the past. :)

Kay


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel