Re: Do we need hotplug?
Alexander E. Patrakov wrote:
Coldplugging is a bit more problematic. hotplug-light does load modules,
but does not recreate USB hotplug events correctly. This breaks
chmodding pseudofiles in /proc/bus/usb/xxx/yyy when USB host controller
is compiled as a non-module, and thus it will make my scanner
inaccessible for non-root when BLFS finally moves from the obsolete
usb group hack to the proper hotplug handlers.
I've just been working round a similar issue with an Iriver mp3 player. It uses
an altered form of fat 32. There is a kernel patch to allow it to be mounted
but the ifp aplication I used to use to access the device relied on hotplug to
change the permissions onit so non-root uses could access it. Without hotplug,
I can only put songs on the device as root. The solution was to create a udev
rule (all one line, sorry if it wraps)
ACTION=add, BUS=usb, SYSFS{manufacturer}=iRiver Limited.,
PROGRAM=/usr/sbin/ifp-nonroot.sh
That runs a simple script /usr/sbin/ifp-nonroot.sh that looks like this
#!/bin/bash
chgrp audio $DEVICE
chmod g+rw $DEVICE
Of course the script can do almost anything so this is very powerfull, flexible and extensible.
man udev is quite informative and so is the docs/writing_udev_rules/index.html
file in the udev kernel source. That should really get installed in
/usr/share/doc. Perhaps something like
install -m 755 -d /usr/share/doc/udev_rules
install -m 644 docs/writing_udev_rules/index.html /usr/share/doc/udev_rules
Back to the original question: Hotplug is not needed for a minimal
system. Its use in LFS is limited to hardware detection facilities
(compare /etc/sysconfig/modules in LFS-6.1 with LFS-6.0), and BLFS
doesn't use hotplug yet. But it is useful.
To me, I don't see the need for hotplug to be in LFS, I don't think it should
be in BLFS either. If someone needs it they should write a hint. Maybe I'm
being a bit extreme, but...
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Do we need hotplug?
Andrew Benton wrote: The version of udev we have in the development version of the book (udev 063) sets itself as the default hotplug event handler (cat /proc/sys/kernel/hotplug) so do we need the hotplug scripts? Will they ever be used for anything? Is it ever called? Related to this, http://marc.theaimsgroup.com/?l=linux-hotplug-develm=112449669014540w=2 looks like it might be a potential way of coldplugging without the need for an initramfs. Note, I've not even downloaded the tarball, let alone inspected or tested it! Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Do we need hotplug?
Jürg Billeter wrote: (about udev workflow) If you need more details or see potential problems, just mail. Thanks. When I said about races that are hard to avoid, I just meant I have to inspect this because there were races in the past. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Do we need hotplug?
Matthew Burgess wrote: Andrew Benton wrote: so do we need the hotplug scripts? Will they ever be used for anything? Is it ever called? I don't think all device subsystems are udev-compatible at the moment (the 'input' subsystem rings a bell here). Additionally, I don't think we handle 'coldplug' events correctly, somewhat ironically, without the 'hotplug' scripts around. Alexander will no doubt correct me on the above though :) Well, the main two reasons for including hotplug were: 1) Coldplugging (this includes not only loading modules, but also setting permissions on /proc/bus/usb/xxx/yyy by e.g. SANE and gPhoto2 -- but BLFS uses the usb group hack instead of those hotplug handlers) 2) Hotplugging. Hotplugging can be done by Udev now, and it calls /etc/hotplug.d/whatever just as good old /sbin/hotplug did. But in /etc/hotplug.d are scripts from the Hotplug package (they calll agents in /etc/hotplug). Of course they can be replaced with udev rules from hotplug-light, http://www.bofh.it/~md/debian/ (requires linux = 2.6.12, for installation instructions view debian/rules) Coldplugging is a bit more problematic. hotplug-light does load modules, but does not recreate USB hotplug events correctly. This breaks chmodding pseudofiles in /proc/bus/usb/xxx/yyy when USB host controller is compiled as a non-module, and thus it will make my scanner inaccessible for non-root when BLFS finally moves from the obsolete usb group hack to the proper hotplug handlers. There are two solutions discussed not long ago upstream. One is to make an initramfs that captures all early hotplug events, starting from the event with SEQNUM=0, and then replays those events when the root fs is mounted (basically, a better reimplementation of http://bugs.linuxfromscratch.org/show_bug.cgi?id=868 ). This is already available with recent udev releases. In this approach, there's no concept of coldplugging at all. The downside is that races are almost unavoidable. Another solution is to put event replaying logic into udevstart. The downside is that approach is fragile WRT changes in the correspondence between hotplug variable names and sysfs attributes. Also, there were some objections on the list, like this is not the task of udevstart, please at least put it into a separate binary. Noe that there's no implementation of this in the existing udev versions. As for the input susbystem calling /sbin/hotplug directly and not duplicating events on the netlink socket, that's OK if you don't rely upon input module autoloading (e.g. for psmouse). Back to the original question: Hotplug is not needed for a minimal system. Its use in LFS is limited to hardware detection facilities (compare /etc/sysconfig/modules in LFS-6.1 with LFS-6.0), and BLFS doesn't use hotplug yet. But it is useful. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Do we need hotplug?
Andrew Benton wrote: make udevdir=/dev EXTRAS=extras/firmware make udevdir=/dev EXTRAS=extras/firmware install Based on the fact that I don't think any hardware that requires such firmware loading will be fully functional without BLFS packages, I'm not sure we want/need to alter our instructions or rules. I'm open to further arguments*, of course. This is similar to the debate we had not so long back regarding audio devices; although one can `cat' files to one's audio device, full audio functionality isn't possible without BLFS packages. Therefore we decided that the audio rules should be removed from LFS' udev rules. This hasn't happened yet, as I think it was going to be tackled as part of/alongside bug 1032. Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Do we need hotplug?
Matthew Burgess wrote: Jürg Billeter wrote: If you're (or anybode else is) interested in this topic, I could explain our approach - simplified since event recorder got upstream. Yep, I'd be interested, though never having had to dabble with initramfs or initrd I've no idea on their potential complexity and therefore their suitability for LFS. I'd like to know too. I want to eventually move to an initrd or initramfs setup, and I'd like to move to a store the events, then replay them setup at the same time. To that end, knowing how to do it would be a good idea. ;-) signature.asc Description: OpenPGP digital signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Do we need hotplug?
On Die, 2005-08-16 at 20:31 +0100, Matthew Burgess wrote: Jürg Billeter wrote: If you're (or anybode else is) interested in this topic, I could explain our approach - simplified since event recorder got upstream. Yep, I'd be interested, though never having had to dabble with initramfs or initrd I've no idea on their potential complexity and therefore their suitability for LFS. I can't answer the question of suitability for LFS but the whole process probably gets easier with the next kernel releases as klibc is on the way into the kernel to carry over the rootfs mount operation from kernelspace to userspace. Summarized, our bootprocess works as follows: - The kernel emits the first hotplug events at a moment where /init (the init process of initramfs) hasn't run yet, i.e. it calls /sbin/hotplug. In our initramfs /sbin/hotplug is a symlink to udeveventrecorder. udeveventrecorder just creates a log file for each event received, i.e. this does not trigger any module loading or similar actions - The kernel executes /init with pid 1 - /init starts the udevd daemon and replays the recorded events using udevinitsend; this triggers module loading via modalias and a minimal udev rules file - Now all newly occuring events get still recorded and additionally the udevd daemon processes incoming events from the netlink socket - As soon as the desired root device is available, it gets mounted (via udev rule) - /init stops the udevd daemon and then starts the udevd daemon from the mounted root device with the option --stop-exec-queue, i.e. incoming events will be queued only, not processed - /proc/sys/hotplug gets unset as it isn't necessary anymore - /init replays the recorded events using udevinitsend - /init execs run-init (part of klibc) to start the real init and nuke initramfs - The bootscripts call udevcontrol start_exec_queue to process the queued events and all newly occuring events get processed immediately If you need more details or see potential problems, just mail. HTH, Jürg -- Jürg Billeter [EMAIL PROTECTED] -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Do we need hotplug?
The version of udev we have in the development version of the book (udev 063) sets itself as the default hotplug event handler (cat /proc/sys/kernel/hotplug) so do we need the hotplug scripts? Will they ever be used for anything? Is it ever called? -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Do we need hotplug?
Matthew Burgess wrote: I don't think all device subsystems are udev-compatible at the moment (the 'input' subsystem rings a bell here). Additionally, I don't think we handle 'coldplug' events correctly, somewhat ironically, without the 'hotplug' scripts around. Alexander will no doubt correct me on the above though :) It was a coldplug event which prompted me to write. Udev has broken kernel firmware loading using the hotplug scripts. The solution is to use udev-067 and compile it with make udevdir=/dev EXTRAS=extras/firmware make udevdir=/dev EXTRAS=extras/firmware install and then add this line to udev-config-3.rules (it is one line, sorry if it gets wrapped) ACTION=add, SUBSYSTEM=firmware, FIRMWARE=*, PROGRAM=/sbin/firmware_helper %k Would it be possible to have those changes added to the book? -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
