pUPnGO 2012
PANZERKOPF: Never got mdev working...tried you scripts (deactivated udevd in init), run rc.mdev afterlogin. Had to add groups disk, uucp, cdrom and video. Then only minor warnings running mdev -s or rc.mdev.
But no drivers loaded afterwards...
When to launch rc.mdev? Do you need additional scripts/setup?
Btw. diethotplug is an other close to udevd replacement.
But no drivers loaded afterwards...
When to launch rc.mdev? Do you need additional scripts/setup?
Btw. diethotplug is an other close to udevd replacement.
-
- Posts: 282
- Joined: Wed 16 Dec 2009, 21:38
- Location: Earth
Weird....goingnuts wrote:PANZERKOPF: Never got mdev working...tried you scripts (deactivated udevd in init), run rc.mdev afterlogin. Had to add groups disk, uucp, cdrom and video. Then only minor warnings running mdev -s or rc.mdev.
But no drivers loaded afterwards...
When to launch rc.mdev? Do you need additional scripts/setup?
Usually mdev must be launched after mounting sysfs and proc.
Maybe Your busybox has different configuration?
Above code is a part of my system initscript. Attached tarball contains this script and
busybox configuration file.
- Attachments
-
- sysinit.tar.gz
- (3.6 KiB) Downloaded 380 times
SUUM CUIQUE.
Looking at the mdev scripts, I see a couple things...
1. mdev.conf is missing this section (from examples/mdev_fat.conf in the busybox source):
This is what handles hotplug module loading, which is important.
2. Most of the mknod stuff is unneeded with a proper mdev.conf.
I know /dev/{console,full,null,zero,urandom,random} are automatically created, even with mdev.conf absent.
3. sysctl -w kernel.hotplug=/sbin/mdev allows use wthout mounting /proc
4. Alpine uses/used something like:
to load modules for devices that aren't hotplugged. This should really speed things up.
And to coldplug USB devices, you may need this:
Alpine's stuff is at:
http://git.alpinelinux.org/cgit/aports/ ... nitscripts
1. mdev.conf is missing this section (from examples/mdev_fat.conf in the busybox source):
Code: Select all
# Syntax:
# [-]devicename_regex user:group mode [>|=path] [@|$|*cmd args...]
#
# =: move, >: move and create a symlink
# @|$|*: run $cmd on delete, @cmd on create, *cmd on both
# support module loading on hotplug
$MODALIAS=.* root:root 660 @modprobe "$MODALIAS"
2. Most of the mknod stuff is unneeded with a proper mdev.conf.
I know /dev/{console,full,null,zero,urandom,random} are automatically created, even with mdev.conf absent.
3. sysctl -w kernel.hotplug=/sbin/mdev allows use wthout mounting /proc
4. Alpine uses/used something like:
Code: Select all
find /sys -name modalias |xargs sort -u |xargs modprobe -a -b
And to coldplug USB devices, you may need this:
Code: Select all
# mdev -s will not create /dev/usb[1-9] devices with recent kernels
# so we trigger hotplug events for usb for now
for i in $(find /sys/devices -name 'usb[0-9]*'); do
[ -e $i/uevent ] && echo add > $i/uevent
done
http://git.alpinelinux.org/cgit/aports/ ... nitscripts
-
- Posts: 282
- Joined: Wed 16 Dec 2009, 21:38
- Location: Earth
We can use above trick as well as making script for particular event (see /lib/mdev/usbdev for example).Ibidem wrote:Looking at the mdev scripts, I see a couple things...
1. mdev.conf is missing this section (from examples/mdev_fat.conf in the busybox source):This is what handles hotplug module loading, which is important.Code: Select all
# Syntax: # [-]devicename_regex user:group mode [>|=path] [@|$|*cmd args...] # # =: move, >: move and create a symlink # @|$|*: run $cmd on delete, @cmd on create, *cmd on both # support module loading on hotplug $MODALIAS=.* root:root 660 @modprobe "$MODALIAS"
I learned Alpine scripts before making my one. That script unfortunately cannot detectIbidem wrote: 4. Alpine uses/used something like:to load modules for devices that aren't hotplugged. This should really speed things up.Code: Select all
find /sys -name modalias |xargs sort -u |xargs modprobe -a -b
And to coldplug USB devices, you may need this:Code: Select all
# mdev -s will not create /dev/usb[1-9] devices with recent kernels # so we trigger hotplug events for usb for now for i in $(find /sys/devices -name 'usb[0-9]*'); do [ -e $i/uevent ] && echo add > $i/uevent done
all devices plugged in my test boxes (like Broadcom wireless card).
Some devices hasnt modalias file in /sys directory but has uevent with modalias string inside.
Also, my version based on "pure shell", no grep, find, xargs etc. That is not important but
should be faster (IMHO)
SUUM CUIQUE.
-
- Posts: 282
- Joined: Wed 16 Dec 2009, 21:38
- Location: Earth
I use this in my own "pocket Linux", most things are written from scratch but some ideasgreengeek wrote:The rc.shutdown is very much simpler than some of the puppy shutdown scripts I have been looking at recently. Where would you use this? Is it taken from another distro or would it work in a cutdown puppy?
and functions were borrowed from other projects.
SUUM CUIQUE.
A loop to load modules will probably be slower than loading all at once: you may save the time of invoking find/grep/xargs once, but you pay by reading each file serially and invoking modprobe once per module.PANZERKOPF wrote:I learned Alpine scripts before making my one. That script unfortunately cannot detectIbidem wrote: 4. Alpine uses/used something like:to load modules for devices that aren't hotplugged. This should really speed things up.Code: Select all
find /sys -name modalias |xargs sort -u |xargs modprobe -a -b
And to coldplug USB devices, you may need this:Code: Select all
# mdev -s will not create /dev/usb[1-9] devices with recent kernels # so we trigger hotplug events for usb for now for i in $(find /sys/devices -name 'usb[0-9]*'); do [ -e $i/uevent ] && echo add > $i/uevent done
all devices plugged in my test boxes (like Broadcom wireless card).
Some devices hasnt modalias file in /sys directory but has uevent with modalias string inside.
Also, my version based on "pure shell", no grep, find, xargs etc. That is not important but
should be faster (IMHO)
Plus, a for loop has some inherent overhead.
I timed the different methods with modprobe converted to an echo:
Anyway, here's an attempt to handle that case; there is some overhead to parsing the uevent files.
Brute force with find @ 0.39 seconds:
Code: Select all
find /sys/devices -name uevent | xargs grep -h MODALIAS 2>/dev/null |cut -d = -f 2
Code: Select all
#!/bin/sh
#is there really a reason to try twice?
for ONEBUS in /sys/bus/* /sys/bus/*; do
for ONEDEVICE in ${ONEBUS}/devices/*; do
[ -r ${ONEDEVICE}/uevent ] || continue
while read ONEUEVENTSTR; do
case $ONEUEVENTSTR in
MODALIAS=*)
echo ${ONEUEVENTSTR#MODALIAS=} 2>/dev/null
;;
*)
continue
;;
esac
done < ${ONEDEVICE}/uevent
done
done
Code: Select all
grep -h MODALIAS /sys/bus/*/devices/*/uevent 2>/dev/null |cut -d = -f 2
Code: Select all
find /sys -name uevent -exec echo add > {} \;
Each testcase outputs a list of module aliases.
FYI: diethotplug is from 2002; you might want hotplug2.goingnuts wrote:PANZERKOPF: Never got mdev working...tried you scripts (deactivated udevd in init), run rc.mdev afterlogin. Had to add groups disk, uucp, cdrom and video. Then only minor warnings running mdev -s or rc.mdev.
But no drivers loaded afterwards...
When to launch rc.mdev? Do you need additional scripts/setup?
Btw. diethotplug is an other close to udevd replacement.
Then there's mdev and ndev, and Busybox hotplug, and eudev, and probably a few other systems...
But udev/eudev provide one thing the other solutions don't: they can enumerate devices, which is what Xorg wants them for.
-
- Posts: 282
- Joined: Wed 16 Dec 2009, 21:38
- Location: Earth
PANZERKOPF & Ibidem: Thanks for all your input! I guess I stick with udev-124 as its quite small and it works for me. Cant get BB mdev working, diethotplug is fast but lacks some features, hotplug2 seems to favor glibc-dynamic linking and eudev needs Autoconf version 2.68 or higher and I do not want to upgrade now...
And the udevd seems to work on kernel from P216, P412, P431 & P525 without recompile.
Revisited the static build of tcl/tk 8.5 to get attached 3 games running (bubbles.tcl CrystalsBattle.tcl gemgame.tcl) where the first & last will be known from Puppy3...quite addictive...
And the udevd seems to work on kernel from P216, P412, P431 & P525 without recompile.
Revisited the static build of tcl/tk 8.5 to get attached 3 games running (bubbles.tcl CrystalsBattle.tcl gemgame.tcl) where the first & last will be known from Puppy3...quite addictive...
- Attachments
-
- 3_tcl_games.tar.gz
- 3 classic tcl games
- (27.39 KiB) Downloaded 303 times
Last edited by goingnuts on Mon 28 Jan 2013, 20:03, edited 1 time in total.
Excuse me for asking - a while back there was discussion here based on the output of strace, where it seemed that the dynamic linker was looking in many strange places for libs (like /lib/tls, etc) before finally looking in just /lib, /usr/lib, etc. does anyone remember the discussion and could redirect me to it. If this is true, I'd like to do something about it by patching glibc to skip all those locations...
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
I'm pretty sure it's ld-x.xx.so (whatever ld-linux.so.2 links to). the question is where do we find where that list is being composed in the linker code?
techno, "library paths from the build environment with gcc", do you mean during the build of glibc or the program in question?
Or maybe it's just strace's own output?
techno, "library paths from the build environment with gcc", do you mean during the build of glibc or the program in question?
Or maybe it's just strace's own output?
http://stackoverflow.com/questions/9922 ... earch-path
Creating the searched directory structure (/lib/tls/i686/sse2) and symlinking /lib/libc.so.6 there stops the search.
Using less to view content of ld-2.6.1.so and text search for tls or sse2 does not show anything.
Using strace on dynamic linked uclibc binaries does not have these extra search path (goes for "/lib/libc.so" first).
Creating the searched directory structure (/lib/tls/i686/sse2) and symlinking /lib/libc.so.6 there stops the search.
Using less to view content of ld-2.6.1.so and text search for tls or sse2 does not show anything.
Using strace on dynamic linked uclibc binaries does not have these extra search path (goes for "/lib/libc.so" first).
What is the output of:
ldconfig -v 2>/dev/null | grep -v ^$'\t'
on your machine. The command appears to only show locations which are in ld.so.conf, plus the standard locations.
Here, I get:
ldconfig -v 2>/dev/null | grep -v ^$'\t'
/usr/local/lib:
/usr/i586-kiss-linux/lib:
/usr/lib/seamonkey:
/lib:
/usr/lib:
And the content of /etc/ld.so.conf is:
/usr/local/lib
/usr/i586-kiss-linux/lib
/usr/lib/seamonkey
Whose glibc are you using anway?
ldconfig -v 2>/dev/null | grep -v ^$'\t'
on your machine. The command appears to only show locations which are in ld.so.conf, plus the standard locations.
Here, I get:
ldconfig -v 2>/dev/null | grep -v ^$'\t'
/usr/local/lib:
/usr/i586-kiss-linux/lib:
/usr/lib/seamonkey:
/lib:
/usr/lib:
And the content of /etc/ld.so.conf is:
/usr/local/lib
/usr/i586-kiss-linux/lib
/usr/lib/seamonkey
Whose glibc are you using anway?
I am using libs provided with standard Puppy 412...output is:
and content of /etc/ld.so.conf is/lib:
/usr/lib:
/usr/X11R7/lib:
/opt/qt4/lib:
/opt/mozilla.org/lib:
/root/my-applications/lib:
/usr/lib/tls: (hwcap: 0x8000000000000000)
/lib
/usr/lib
/usr/X11R7/lib
/opt/qt4/lib
/opt/mozilla.org/lib
/opt/samba/lib
/root/my-applications/lib
/usr/lib/tls: (hwcap: 0x8000000000000000)
Okay! That's the one which is hidden and generated in some mysterious way. It either has to do with CPU specs and is generated at runtime or it has to do with configure options to glibc and is being determined at glibc compile-time. The key is the 'hwcap' part.
I have asked about this all over at linuxquestions.org -but no takers yet.
Aha! Just found an LKML thread where The Man(Roland McGrath) himself talks about this:
https://lkml.org/lkml/2007/4/24/3
He seems to be saying that these paths are generated at runtime -using entires in /etc/ld.so.conf.d, and/or they depend on options used at glibc compile-time.
On my self-built system here, I don't get any of those extra paths. Guess the upshot is that you need to be using Gilbert's super-duper KISS linux -where most of the nonsense is missing... Or maybe you'd like to roll your own glibc -even BK doesn't do that.
"libs provided with standard Puppy 412" The problem is that that still doesn't tell us where they came from or who built them! The output of `/lib/libc.so.6` will help a little bit -did you know that trick? Here's another 2 which will tell you some things -sometimes clearing up questions about compiling/linking problems:
gcc -dumpspecs
gcc -dumpmachine
Here's another link with tips to the location(s) in the sources.
http://www.unixresources.net/linux/clf/ ... 88306.html
find -name dl-procinfo.h
sysdeps/generic/dl-procinfo.h
sysdeps/i386/dl-procinfo.h
sysdeps/powerpc/dl-procinfo.h
sysdeps/s390/dl-procinfo.h
sysdeps/sparc/dl-procinfo.h
sysdeps/unix/sysv/linux/i386/dl-procinfo.h
sysdeps/unix/sysv/linux/s390/dl-procinfo.h
sysdeps/unix/sysv/linux/x86_64/dl-procinfo.h
And there's this:
http://blog.ijun.org/2012/01/debugging- ... ssues.html
Does your system have a non-empty /etc/ld.so.conf.d directory?
Okay, getting warmer...
Starting at line 52 of sysdeps/i386/dl-procinfo.c:
Those are the possible CPU features (hwcap) which constitute most of the list of possibly-weird locations. 'tls', and perhaps others, depends on the compile-time options for glibc.
Well, I'm just glad I have this clean, nearly vanilla system so that I don't have 14 open()'s being called before the right location is found!
Okay! That's the one which is hidden and generated in some mysterious way. It either has to do with CPU specs and is generated at runtime or it has to do with configure options to glibc and is being determined at glibc compile-time. The key is the 'hwcap' part.
I have asked about this all over at linuxquestions.org -but no takers yet.
Aha! Just found an LKML thread where The Man(Roland McGrath) himself talks about this:
https://lkml.org/lkml/2007/4/24/3
He seems to be saying that these paths are generated at runtime -using entires in /etc/ld.so.conf.d, and/or they depend on options used at glibc compile-time.
On my self-built system here, I don't get any of those extra paths. Guess the upshot is that you need to be using Gilbert's super-duper KISS linux -where most of the nonsense is missing... Or maybe you'd like to roll your own glibc -even BK doesn't do that.
"libs provided with standard Puppy 412" The problem is that that still doesn't tell us where they came from or who built them! The output of `/lib/libc.so.6` will help a little bit -did you know that trick? Here's another 2 which will tell you some things -sometimes clearing up questions about compiling/linking problems:
gcc -dumpspecs
gcc -dumpmachine
Here's another link with tips to the location(s) in the sources.
http://www.unixresources.net/linux/clf/ ... 88306.html
In topdir of glibc sources:If this stuff is causing you a problem, you can turn it off by patching dl-procinfo.h in glibc
find -name dl-procinfo.h
sysdeps/generic/dl-procinfo.h
sysdeps/i386/dl-procinfo.h
sysdeps/powerpc/dl-procinfo.h
sysdeps/s390/dl-procinfo.h
sysdeps/sparc/dl-procinfo.h
sysdeps/unix/sysv/linux/i386/dl-procinfo.h
sysdeps/unix/sysv/linux/s390/dl-procinfo.h
sysdeps/unix/sysv/linux/x86_64/dl-procinfo.h
And there's this:
http://blog.ijun.org/2012/01/debugging- ... ssues.html
Does your system have a non-empty /etc/ld.so.conf.d directory?
Okay, getting warmer...
Starting at line 52 of sysdeps/i386/dl-procinfo.c:
Code: Select all
#ifndef PROCINFO_DECL
= {
"fpu", "vme", "de", "pse", "tsc", "msr", "pae", "mce",
"cx8", "apic", "10", "sep", "mtrr", "pge", "mca", "cmov",
"pat", "pse36", "pn", "clflush", "20", "dts", "acpi", "mmx",
"fxsr", "sse", "sse2", "ss", "ht", "tm", "ia64", "pbe"
}
#endif
Well, I'm just glad I have this clean, nearly vanilla system so that I don't have 14 open()'s being called before the right location is found!
amigo: Thanks for all this info! A lot to test and think about. For now only the output of /lib/libc.so.6
COOL!GNU C Library stable release version 2.6.1, by Roland McGrath et al.
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.2.2.
Compiled on a Linux >>2.6.21.7<< system on 2007-10-18.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.