FS#14808 - [udev] Please add some static devices needed for fbsplash

Attached to Project: Arch Linux
Opened by kujub (kujub) - Saturday, 23 May 2009, 17:44 GMT
Last edited by Thomas Bächler (brain0) - Tuesday, 26 January 2010, 21:40 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Aaron Griffin (phrakture)
Thomas Bächler (brain0)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:

I rewrote the scripts needed to hook fbsplash into initscripts. http://aur.archlinux.org/packages.php?ID=26039

Tough i encountered one problem. To be able to start the daemon early (instead of after "Loading UDev uevents" which means no progress is shown for several seconds) i needed to implement this hack:

/bin/mkdir /dev/fb
/bin/mknod -m 660 /dev/fb/0 c 29 0
/bin/chgrp video /dev/fb/0
/bin/ln -s fb/0 /dev/fb0

/bin/mkdir /dev/vc
for i in 0 1 ${SPLASH_TTY} ; do
/bin/mknod -m 620 /dev/vc/$i c 4 $i
/bin/chgrp tty /dev/vc/$i
/bin/ln -s vc/$i /dev/tty$i
done

/bin/mknod -m 666 /dev/tty c 5 0
/bin/chgrp tty /dev/tty

Where ${SPLASH_TTY} defaults to 16, but can be configured to any other value.

I would appreciate if those nodes could be added as static ones into /lib/udev/devices/ so we could have a clean way to do this.

Additional info:
* package version(s)
udev 141-1

Steps to reproduce:
Get initscripts-extras-fbsplash from the AUR.
Remove the call to spash_mknods in splash-functions-arch.sh.
Install.
In /etc/conf.d/fbsplash set SPLASH_START_EARLY="yes"

Result:
Splash daemon fails to start.
This task depends upon

Closed by  Thomas Bächler (brain0)
Tuesday, 26 January 2010, 21:40 GMT
Reason for closing:  None
Comment by kujub (kujub) - Saturday, 23 May 2009, 18:15 GMT
Result should read:
Splash daemon fails to start early. (It is started at the later point as if set SPLASH_START_EARLY="no".)
Comment by Tobias Powalowski (tpowa) - Sunday, 24 May 2009, 20:28 GMT
groups in early userspace are pretty useless
Comment by Thomas Bächler (brain0) - Sunday, 24 May 2009, 21:55 GMT
This is not about early userspace, but the early stage of rc.sysinit. I am really not sure if we should do this, especially add fb devices statically while they are not present on each machine.
Comment by kujub (kujub) - Monday, 25 May 2009, 08:37 GMT
[quote]groups in early userspace are pretty useless[quote]
I remember if i didn't chgrp in the hack the groups where wrong after boot. That's why it's a dirty hack and I'm not satisfied with this approach. :/
[quote]fb devices ... are not present on each machine[/quote]
Good point. Is there any way to detect this ?
Comment by kujub (kujub) - Monday, 25 May 2009, 08:52 GMT
Another point: The devices needed are even there when loading the initcpio after the udev hook. I was able to start the splash daemon there in an early version of the scripts. (Now the fbcondecor_helper is used for that.) Maybe some small and fast udev thing could be added right where the udev daemon is started ?
Comment by kujub (kujub) - Monday, 25 May 2009, 10:17 GMT
Whoohoo! Now i changed the hack to this:

if /bin/pidof -o %PPID /sbin/udevd >/dev/null; then
splash_real_stat_busy "Loading UDev uevents for starting fbsplash early "
udevstart="$(/bin/date +%s%0N)"
/sbin/udevadm trigger --subsystem-match=tty --subsystem-match=graphics
/sbin/udevadm settle
splash_real_stat_done
udevend="$(/bin/date +%s%0N)"
printhl " UDev uevent processing time: $((($udevend-$udevstart)/1000000))ms"
fi

And hooked it into initscripts at stat_done "Starting UDev Daemon" starting the splash there. Seems to work good and takes only about 110 ms here.
Any concerns ?
Comment by Heiko Baums (cyberpatrol) - Monday, 25 May 2009, 10:53 GMT
Kurt, I don't know, if this is, what you want, but if you need a specific udev rule, just create it, put it into a separate file in /etc/udev/rules.d like "00-fbsplash.rules" and add this file to the initrd e.g. with 'FILES="/etc/udev/rules.d/00-usbkey.rules"' in /etc/mkinitcpio.conf. I guess, this is also possible inside a hook.
Comment by kujub (kujub) - Monday, 25 May 2009, 11:23 GMT
Heiko: Thank you for your help, but there is no problem in the initrd.
Comment by Thomas Bächler (brain0) - Monday, 25 May 2009, 13:32 GMT
Yes, that looks much better. You actually settle enough devices to get started, then start the splash daemon and let us do the rest (seriously, 110ms is not too much time).

How do you hook this up in the initscripts? Does it work with unpatched Arch initscripts? If not, we need to provide more hooks where you can plug in your functions (I _really_ always hated that there were separate initscripts for splash in the past and I really want all this to work with unpatched initscripts, so splash users will always be on the same page as non-splash users).
Comment by kujub (kujub) - Monday, 25 May 2009, 16:37 GMT
It works with unpatched Arch initscripts. We override stat_{busy,done,fail} and grab $1 from stat_busy since Greg Helton's script version included in fbsplash 1.5.4.3-3 which where my starting point.
If you want, you can look at the hook script here: http://aur.archlinux.org/packages/initscripts-extras-fbsplash/initscripts-extras-fbsplash/fbsplash.inithooks . It's installed as /etc/rc.d/functions.d/fbsplash.sh and only does the calls to the main scripts. The 'splash rc_init sysinit is for setting up an tmpfs an for starting the daemon early the 'splash rc_init boot' is used for setting the event device which the daemon needs to watch the keyboard (and for starting the daemon if early start isn't possible).
However dedicated hook points instead of grabbing the stat_busy messages would be more clean for sure. :)
Comment by kujub (kujub) - Thursday, 25 June 2009, 14:33 GMT
I think this can be closed now. (Hopefully we do not need a cleaner implementation of some initscripts hooks framework because of  FS#14569 )

Loading...