Well I don't speak for him, but the dev nodes you create inside lxc container (glorified chroot jail actually) depends on what you want to run inside it (for security reasons)Iguleder wrote:Why not?jamesbond wrote:... (not just for all devices).
populating /dev from /sys
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
- Iguleder
- Posts: 2026
- Joined: Tue 11 Aug 2009, 09:36
- Location: Israel, somewhere in the beautiful desert
- Contact:
I don't see how this improves security. You're still using the same kernel as the host - that's the main weakness of jails, compared to virtualization.
For example, if you want to ruin the first hard drive (in 99% of cases, that's sda1) from inside the chroot environment, just create the device node with mknod (by the way, you don't even need /sys to know the major and minor numbers, since their constant).
For example, if you want to ruin the first hard drive (in 99% of cases, that's sda1) from inside the chroot environment, just create the device node with mknod (by the way, you don't even need /sys to know the major and minor numbers, since their constant).
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]
Agreed. But security is always trade-off. It depends on your needs. Even full virtualisation (KVM / Xen and the like) can be broken into if one is desperate enough. By the way mknod doesn't work as non-root so once you enter the jail and drop privileges you can't just make new nodes.that's the main weakness of jails, compared to virtualization
Anyway, we are distracting from the original topic. We can carry on the discussion in a new thread if you wish.
If technosaurus wants to continue exploring ways of creating device nodes from /sys then so be it
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
Mine looks now as:
Nice replacement for /sbin/pup_event_backend* files . Have to test it though .
Could need help for the much to long lines
I guess that can be done by awk alone ..
Code: Select all
#!/bin/ash
exec 1>>/tmp/photplug.log 2>&1
eval `env`
[ "$ACTION" = add ] || exit
[ "$MODALIAS" ] && {
[ -f /tmp/hotplug.modules ] || modprobe -c >/tmp/hotplug.modules
MODS=`grep "^alias $MODALIAS" /tmp/hotplug.modules |awk '{print $3}' | sort -u`
#OPTS=`grep "^options $MODALIAS" /tmp/hotplug.modules |cut -f3- -d' '`
for m in $MODS ;do
OPTS=`grep -m1 "^options $m" /tmp/hotplug.modules |cut -f3- -d' '`
modprobe -b -v $m $OPTS
done
exit
}
[ "$MAJOR" -a "$MINOR" -a "$DEVNAME" -a "$SUBSYSTEM" ] && {
sed -n '/Block devices:/,$ p' /proc/devices | grep "$SUBSYSTEM" | awk '{print $1}' | grep -w "$MAJOR" && {
[ -e /dev/$DEVNAME ] && exit
DEV="/${DEVNAME}"
mkdir -p "/dev/${DEV%/*}"
mknod /dev/$DEVNAME b $MAJOR $MINOR
exit $? ; }
sed -n '/Character devices:/,/Block devices:/p' /proc/devices | grep "$SUBSYSTEM" | awk '{print $1}' | grep -w "$MAJOR" && {
[ -e /dev/$DEVNAME ] && exit
DEV="/${DEVNAME}"
mkdir -p "/dev/${DEV%/*}"
mknod /dev/$DEVNAME c $MAJOR $MINOR
exit $? ; }
}
Could need help for the much to long lines
Code: Select all
sed -n '/Character devices:/,/Block devices:/p' /proc/devices | grep "$SUBSYSTEM" | awk '{print $1}' | grep -w "$MAJOR"
Last edited by Karl Godt on Fri 17 May 2013, 12:13, edited 1 time in total.
Above wasn't loading any modules .
This now worked >
Have sound and everything
If it is faster and less load , time will tell . Am running a Puppy-4.3 without /etc/modprobe.d .
2.6.30.9-i586-dpup005-Celeron2G and it's name comes from being compiled on a dpup by iguleder
Adjustment to rc.sysinit >
This now worked >
Code: Select all
[ "$MODALIAS" ] && {
LIST=`modprobe -b -D "$MODALIAS" | sed 's%.*\(/.*\)\.k.*%\1%'`
for m in $LIST ; do
modprobe -b -v "${m##*/}"
done
}
If it is faster and less load , time will tell . Am running a Puppy-4.3 without /etc/modprobe.d .
2.6.30.9-i586-dpup005-Celeron2G and it's name comes from being compiled on a dpup by iguleder
Adjustment to rc.sysinit >
Code: Select all
if [ -x /sbin/photplug ] ; then
echo '/sbin/photplug' >/proc/sys/kernel/hotplug
#v405 udevd calls /sbin/pup_event_backend_modprobe, which needs this...#my intention is for puppy to work with either of these...
elif [ -x /sbin/udevd ];then ##changed -f to -x
Today had no sound.
What was wrong ?
My grep for SUBSYSTEM grep MAJOR does not work when
14 sound
116 alsa
are set in /proc/devices.
SUBSYSTEM passed by the kernel for MAJOR 116 is sound not alsa.
working fix looks as
What was wrong ?
My grep for SUBSYSTEM grep MAJOR does not work when
14 sound
116 alsa
are set in /proc/devices.
SUBSYSTEM passed by the kernel for MAJOR 116 is sound not alsa.
working fix looks as
Code: Select all
[ "$SUBSYSTEM" = sound ] && GPATTERN='alsa|sound' || GPATTERN="$SUBSYSTEM"
sed -n '/Character devices:/,/Block devices:/p' /proc/devices | grep -E "$GPATTERN" | awk '{print $1}' | grep -w "$MAJOR" && {
«Give me GUI or Death» -- I give you [[Xx]term[inal]] [[Cc]on[s][ole]] .
Macpup user since 2010 on full installations.
People who want problems with Puppy boot frugal :P
Macpup user since 2010 on full installations.
People who want problems with Puppy boot frugal :P
Old kernels have no DEVNAME ..
modprobe -D is short for --show-depends but there a several BUGs in the common modprobe.c getopt line :
/sbin/modprobe-3.11.1 | -3.12 compiled suppressing warnings is what I am using.
modprobe -D also sometimes shows the install lines .
Working code :
Load is double than before :
modprobe -D is short for --show-depends but there a several BUGs in the common modprobe.c getopt line :
Code: Select all
while ((opt = getopt_long(argc, argv, "VvqLnsd:C:h:S:o:DRrclt:aiIbf", options, NULL)) != -1){ /* h: has to be rearranged ':' meaning has to follow an argument */
modprobe -D also sometimes shows the install lines .
Working code :
Code: Select all
#!/bin/ash
exec 1>>/tmp/photplug.log 2>&1
alias sed='busybox sed'
alias grep='busybox grep'
#alias awk='busybox awk' ##awk: applet not found
#eval `env` ##/sbin/photplug: eval: line 1: =/bin/busybox_1.18.3_STATIC_upx9_648KB: not found
env
[ "$ACTION" = add ] || exit
echo $MODALIAS
[ "$MODALIAS" ] && {
#eval `modprobe -b -D "$MODALIAS"| grep -vE '^install|^blacklist|^options'`
#exit
LIST=`modprobe -b -D "$MODALIAS" | grep -vE '^install|^blacklist|^options' | sed 's%.*\(/.*\)\.k.*%\1%'`
for m in $LIST ; do
modprobe -b -v "${m##*/}"
done
}
[ "$MAJOR" -a "$MINOR" -a "$SUBSYSTEM" ] && { [ "$DEVNAME" -o "$DEVPATH" ] && {
[ "$DEVNAME" ] || DEVNAME="${SUBSYSTEM}/${DEVPATH##*/}"
sed -n '/Block devices:/,$ p' /proc/devices | grep "$SUBSYSTEM" | awk '{print $1}' | grep -w "$MAJOR" && {
[ -e /dev/$DEVNAME ] && exit
DEV="/${DEVNAME}"
mkdir -p "/dev/${DEV%/*}"
mknod /dev/$DEVNAME b $MAJOR $MINOR
exit $? ; }
[ "$SUBSYSTEM" = sound ] && GPATTERN='alsa|sound' || GPATTERN="$SUBSYSTEM"
sed -n '/Character devices:/,/Block devices:/p' /proc/devices | grep -E "$GPATTERN" | awk '{print $1}' | grep -w "$MAJOR" && {
[ -e /dev/$DEVNAME ] && exit
DEV="/${DEVNAME}"
mkdir -p "/dev/${DEV%/*}"
mknod /dev/$DEVNAME c $MAJOR $MINOR
exit $? ; }
}
}
- Attachments
-
- xload_after.jpg
- desktop start
- (7.44 KiB) Downloaded 1107 times
Firmware loading
Had first troubles with
02:00.0 Network controller: Ralink corp. RT5390 Wireless 802.11n 1T/1R PCIe
that needs rt2860.bin firmware
( not sure about the current state of my /usr/share/misc/pci.ids file )
02:00.0 Network controller: Ralink corp. RT5390 Wireless 802.11n 1T/1R PCIe
that needs rt2860.bin firmware
( not sure about the current state of my /usr/share/misc/pci.ids file )
Code: Select all
test "$FIRMWARE" && {
echo -n 1 > /sys/$DEVPATH/loading
FIRMWAREBIN=`ls /lib/firmware/$FIRMWARE`
test "$FIRMWAREBIN" || FIRMWAREBIN=`ls /lib/firmware/*/$FIRMWARE`
test "$FIRMWAREBIN" || exit 1
test -f "$FIRMWAREBIN" || exit 1
echo "FIRMWAREBIN='$FIRMWAREBIN'"
cat "$FIRMWAREBIN" > /sys/$DEVPATH/data
if [ $? = 0 ]; then
#echo -n 1 > /sys/$DEVPATH/loading
#echo -n -1 > /sys/$DEVPATH/loading
echo 0 >/sys/$DEVPATH/loading
else
echo "ERROR loading '$FIRMWAREBIN'"
fi
}
«Give me GUI or Death» -- I give you [[Xx]term[inal]] [[Cc]on[s][ole]] .
Macpup user since 2010 on full installations.
People who want problems with Puppy boot frugal :P
Macpup user since 2010 on full installations.
People who want problems with Puppy boot frugal :P
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
here are some more functions that may be useful for hotplugging:
note: my functions use insmod to load modules instead of the simpler modprobe ... insmod can be implemented in <5 lines of c
note2: it does not yet handle missing modules, my recommendation would be that if the module does not exist, to use the package manager to download and install it, but we don't split up our modules like that (yet)
Code: Select all
moddir=/lib/modules/`uname -r`
loadmod(){ #$1=topdir $2=module name
[ -f $1/$2.ko ] && insmod $1/$2.ko && return
for x in $1/*;do
[ -d $x ] && loadmod $x $2;
done
}
#loadmod $moddir $1
loaddeps(){
[ "$1" ] || return
while read mod deps; do
case $mod in
*/$1.ko:)for x in $deps; do [ "$x" ] && insmod $moddir/$x;done;;
esac
done < $moddir/modules.dep
}
loadfirmware(){
[ "$FIRMWARE" ] || return
echo 1 > "/sys/$DEVPATH/loading"
fwdir=/lib/modules
[ -f "$fwdir/$FIRMWARE" ] && cat "$fwdir/$FIRMWARE" > "/sys/$DEVPATH/data" && \
echo 0 > "/sys/$DEVPATH/loading" &
[ ! -f "$fwdir/$FIRMWARE" ] && echo -1 > "/sys/$DEVPATH/loading" && return 1
}
#MODALIAS='pci:v000014E4d00004301sv*sd*bc*sc*i*'
loadmodfromalias(){
[ ! "$MODALIAS" ] && [ ! "$1" ] && return
[ ! "$MODALIAS" ] && MODALIAS="$1"
while read dummy alias module; do
[ "$MODALIAS" == "$alias" ] && loaddeps $module && loadmod $moddir $module && return
done < $moddir/modules.alias
[ "$1" ]
}
note2: it does not yet handle missing modules, my recommendation would be that if the module does not exist, to use the package manager to download and install it, but we don't split up our modules like that (yet)
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
Xorg configured with udev
Yesterday I run into real trouble :
Xorg.0.log :
No keys working to switch to terminal or quitting the Xorg server .
Am not sure what causes it , but I suspect udev dependencies :
Xorg.0.log :
When no udev is running, Xorg s from binary builds may go to desktop but without input enabled .[ 3298.493] (**) ModulePath set to "/usr/lib64/xorg/modules"
[ 3298.498] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.
[ 3298.500] (WW) Disabling Mouse0
[ 3298.502] (WW) Disabling Keyboard0
No keys working to switch to terminal or quitting the Xorg server .
Am not sure what causes it , but I suspect udev dependencies :
Code: Select all
commit a6273cc85c01fc020643a68e49ca4e7a2d2ae898
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Thu Jan 12 10:17:34 2012 +1000
xfree86: mention udev in the xorg.conf manpage AutoAddDevices section
And point out what "hotplugging" means.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
yes its on my to-do list to look into patching X to run properly without libudev (need to find the commit that added it), but in the mean time tinyxserver is a self sufficient replacement.
I think a standard device fallback for each input would be sufficient if another utility maps actual input devices to those standard ones (via symlinks or whatever).
I think a standard device fallback for each input would be sufficient if another utility maps actual input devices to those standard ones (via symlinks or whatever).
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
Re: Xorg configured with udev
Karl Godt wrote:When no udev is running, Xorg s from binary builds may go to desktop but without input enabled .
No keys working to switch to terminal or quitting the Xorg server .
Code: Select all
Section "ServerFlags"
Option "AutoAddDevices" "false"
Option "DontZap" "false"
EndSection
@technosaurus - I'm interested if you can find how to remove udev dependency from Xorg but still be able to have hotplugging (using other means).
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
it previously used hal so I can look at that. I was thinking since they split the config files, an inotify-watch on that directory for added/changed events would be logical (kqueue for bsd) Then the hotplug handler only has to add/modify a file. This can be done in shell, c, or whatever.
It talks about getting input setup in the 1.8 and 1.9 release notes without udev btw
It talks about getting input setup in the 1.8 and 1.9 release notes without udev btw
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
FYI, I've written an experimental library intended to use as a fallback/replacement for some of the features libudev offers.
Right now it only will map a device to a sysfs directory and get the PCI IDs if they're available.
Source is over at https://github.com/idunham/libsysdev; the first port of anything to use it is https://github.com/idunham/xf86-input-evdev, branch sysdev
The API is intended to make porting Mesa to it simple.
There's no "listen for events" code, though. I might see about something to make it easy to listen to inotify events in /dev/input and /dev/block or /dev/disk.
Right now it only will map a device to a sysfs directory and get the PCI IDs if they're available.
Source is over at https://github.com/idunham/libsysdev; the first port of anything to use it is https://github.com/idunham/xf86-input-evdev, branch sysdev
The API is intended to make porting Mesa to it simple.
There's no "listen for events" code, though. I might see about something to make it easy to listen to inotify events in /dev/input and /dev/block or /dev/disk.
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
I may be wrong, but I think those events are handled internally -- it needs help with hot plug events such as plugging in a wireless mouse after X is running.Ibidem wrote:FYI, I've written an experimental library intended to use as a fallback/replacement for some of the features libudev offers.
Right now it only will map a device to a sysfs directory and get the PCI IDs if they're available.
Source is over at https://github.com/idunham/libsysdev; the first port of anything to use it is https://github.com/idunham/xf86-input-evdev, branch sysdev
The API is intended to make porting Mesa to it simple.
There's no "listen for events" code, though. I might see about something to make it easy to listen to inotify events in /dev/input and /dev/block or /dev/disk.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
Might I ask what "those events" refers to in your comment?technosaurus wrote:I may be wrong, but I think those events are handled internally -- it needs help with hot plug events such as plugging in a wireless mouse after X is running.Ibidem wrote:FYI, I've written an experimental library intended to use as a fallback/replacement for some of the features libudev offers.
Right now it only will map a device to a sysfs directory and get the PCI IDs if they're available.
Source is over at https://github.com/idunham/libsysdev; the first port of anything to use it is https://github.com/idunham/xf86-input-evdev, branch sysdev
The API is intended to make porting Mesa to it simple.
There's no "listen for events" code, though. I might see about something to make it easy to listen to inotify events in /dev/input and /dev/block or /dev/disk.
The inotify bit is one possible way of listening for hotplug events.
Hotplugging a GPU/input device means a new device appears in /dev/dri or /dev/input, or an old one disappears; I'm figuring that we can check for that by means of an inotify watch.
As far as I can tell after skimming xorg-xserver source, there are several possible "config" backends for the X server that seem to be responsible for hotplugging; the main code for these is in config/<backend>.c, and I can't really tell exactly where they hook up or how X listens for hotplug events.
I do know config/config.c calls the setup and teardown needed for "the current config backend", and include/hotplug.h declares the functions in config/config.c.
You can build the server with any one of several config backends, or with none; wscons, udev, and HAL are the currently available backends.
Each of these will try to figure out an appropriate driver for each device, then load that driver specifying the device.
When evdev is the driver loaded, it will check whether an input device is "virtual" or not (meaning roughly "is it a pointer or keyboard, or is it something else?") so it knows whether to refuse to proceed.
The way evdev checks this is by finding the corresponding sysfs path and checking if it contains the string "LNXSYSTEM"--if evdev finds that string, it bails out.
Generating this path is currently done by libudev.
mesa somehow-or-other ends up with an fd for a DRI device (without using udev), then uses udev (or some sysfs fallback code that you must manually enable) to get the corresponding PCI ids and parses those PCI ids to determine the mesa driver.
...Ah, that's it: the udev backend installs a wakeup handler (named wakeup_handler(), of course) with RegisterBlockAndWakeupHandlers(). But I'm not sure exactly how all that works; it's a bit above my pay grade . Perhaps udev sends a signal, perhaps it's something along the lines of select() on a socket...
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
I was referring to button/key presses
A netlink socket like udev uses will catch hotplug events ... example here:
https://www.kernel.org/doc/pending/hotplug.txt
A netlink socket like udev uses will catch hotplug events ... example here:
https://www.kernel.org/doc/pending/hotplug.txt
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
I'm more wondering how to make X11 catch hotplugging (esp. devices appearing)...without depending on a particular hotplug helper.technosaurus wrote:I was referring to button/key presses
A netlink socket like udev uses will catch hotplug events ... example here:
https://www.kernel.org/doc/pending/hotplug.txt
In particular, my hope is to work with mdev, vdev, udev, hotplug2, or even static /dev.
If someone runs mknod /dev/input/mouse1 c 4 64 from an xterm, it would be nice if X could go "Ah, there's a new...mouse! Let's load *that* driver!"
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
I know it may sound ridiculous but, the X server could be used as the hotplug handler by just monitoring the netlink hotplug socket in the same loop as the unix domain (or tcp) socket ... or even use select(). For _most_ users the X server is, for all intents and purposes, essentially a daemon anyhow. In fact as part of my nanosaurus experiment, Xvesa and jwm were forked off of /init as if they were a daemon.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].