populating /dev from /sys

[amigo]

Have you ever looked at the old shell-based hotplug implementation? It provides hooks for most hardware subsystems.

[Karl Godt]

http://archive.debian.net/sarge/all/hotplug/filelist
I have installed that into one Macpup 4 installation together with reconfigured hal and e17 shows the plugged in drives at boot time, but hotplugged drives don't get updated .
Have made a sleep loop into xwin for pidof rc.services . Takes 30 seconds for /etc/init.d/hotplug on 2GHz CPU to finish .

[technosaurus]

@Karl, You may need to manually add the name of your hotplug executable (with full path) to /proc/sys/kernel/hotplug
after the cold plug part of init just add a line like
echo /path/to/hotplug > /proc/sys/kernel/hotplug


I looked through the hotplug scripts, (no wonder it was replaced). I'm pretty sure we can get a 5-10x speed improvement over those (sed? really?) and use the newer hotplug mechanisms. If it is still too slow, it would be easy to rewrite the common case in <100 lines of C since it just passes env variables.

[Karl Godt]

Code: Select all

#!/bin/ash
PATH="${PATH}:/usr/local/bin:/usr/X11/bin"
echo "HOTPLUG EVENT TRIGGERED
`date`
$*
">>/tmp/photplug.log
#find /sys -path "*${*}*" >>/tmp/photplug.log
export DISPLAY=':0.0'
exec  xmessage "HOTPLUG EVENT TRIGGERED"

as a start

HOTPLUG EVENT TRIGGERED
Wed May 15 01:48:02 GMT-8 2013
usb

HOTPLUG EVENT TRIGGERED
Wed May 15 01:48:02 GMT-8 2013
usb

HOTPLUG EVENT TRIGGERED
Wed May 15 01:48:02 GMT-8 2013
scsi

HOTPLUG EVENT TRIGGERED
Wed May 15 01:48:02 GMT-8 2013
scsi_host

HOTPLUG EVENT TRIGGERED
Wed May 15 01:48:02 GMT-8 2013
usb_device

HOTPLUG EVENT TRIGGERED
Wed May 15 01:48:07 GMT-8 2013
scsi

HOTPLUG EVENT TRIGGERED
Wed May 15 01:48:07 GMT-8 2013
scsi

HOTPLUG EVENT TRIGGERED
Wed May 15 01:48:07 GMT-8 2013
scsi_device

HOTPLUG EVENT TRIGGERED
Wed May 15 01:48:07 GMT-8 2013
scsi

HOTPLUG EVENT TRIGGERED
Wed May 15 01:48:07 GMT-8 2013
scsi_disk

HOTPLUG EVENT TRIGGERED
Wed May 15 01:48:07 GMT-8 2013
block

HOTPLUG EVENT TRIGGERED
Wed May 15 01:48:07 GMT-8 2013
bdi

HOTPLUG EVENT TRIGGERED
Wed May 15 01:48:07 GMT-8 2013
block

HOTPLUG EVENT TRIGGERED
Wed May 15 01:48:07 GMT-8 2013
block

for a usb pen drive 4GB
# probepart2.07 -m -d/dev/sdc
/dev/sdc1|ext3|1946
/dev/sdc2|ntfs|1961

[technosaurus]

as a start

here is a script that people can run to help me in supporting their devices:

Code: Select all

#!/bin/ash
echo "---------- $@ --------------" >> "$HOME/hotplug.log"
/usr/bin/env >> "$HOME/hotplug.log"

just insert your device(s) and let it settle, remove and gzip the hotplug.log in your home directory (/root on puppy) and post it here

[Ibidem]

There are uevent files that don't contain all variables.
But it seems this is duplicating what mdev does in C already.

http://lists.busybox.net/pipermail/ucli ... hment.diff
The mknod patch for uclibc.

A char device is any device read as a stream (byte at a time); a block device is read block at a time (usu. 512-1024 bytes); usually this means block device == disk, char device == tty or similar.

[Karl Godt]

Here you are :

Code: Select all

#!/bin/ash

eval `env`
[ "$ACTION" = remove ] && SUFFIX=rem || SUFFIX=add
echo "---------- $@ --------------
`env`

`dmesg|tail`
">> "$HOME/hotplug.${SUFFIX}.log"

Modded the code a tiny bit. Hope you don't mind.
Kernel is Drake Puppy 0.3
# uname -r
2.6.39
BB is
# busybox |head -n1
BusyBox v1.17.2 (2011-05-01 08:45:38 GMT-8) multi-call binary.

[Karl Godt]

Karl Godt wrote:
as a start Very Happy

YEP, hundreds of xmessages can be annoying , but to detect single events by mount or kill, it is quite useful .

[Iguleder]

What about devtmpfs? Newer udev versions (AFAIK, 17x and above) require this feature and udev no longer creates device nodes.

The kernel already has that information (major, minor numbers and device names), so why don't you just let it create those device nodes on its own?

Sounds more efficient and smaller (in terms of binary size) to me. Just mount a devtmpfs file system and you're done - this can be done from the initramfs and it is guaranteed that /dev will be populated correctly.

[Karl Godt]

Must say that I have enabled that in some kernels and all of a sudden the USB Modem disconnected and reconnected with ttyUSB0 becomming ttyUSB1 .

But have encountered that too on standard configurations afterwards .

Devtmpfs kernel feature can be enabled without automatically letting the kernel mounting it .
This lead to empty /dev directory at shutdown.
Normal kernels had no nodes there afterwards .
Tiny point to watch out for in full installations .

Otherwise devtmpfs is OK for me.

udev-140 works for me . Dunno what's that hype all about upgrade .

[Iguleder]

Devtmpfs kernel feature can be enabled without automatically letting the kernel mounting it .
This lead to empty /dev directory at shutdown.

You described both the problem and the solution here ... just mount that devtmpfs from the init script!

Normal kernels had no nodes there afterwards .
Tiny point to watch out for in full installations .

I see no difference between full installations, frugal ones or any other hypothetical installation. The init script stays the same, just mount devtmpfs before doing things specific to the installation type used.

udev-140 works for me . Dunno what's that hype all about upgrade .

Windows 1.0 works great on my brand new UEFI, 64-bit ARMv8 laptop. I run it inside VirtualBox, on top of Xen, inside QEMU, inside Bochs, in a Fedora chroot. NOT

EDIT: forgot to mention - devtmpfs is pretty standard. If you don't have it in your kernel, that's probably because you insist on using an ancient kernel, so that's your problem already. You're trying to force things to work, because you decided not to have the clean solution isn't available. 21st century versions of X, recent versions of udev and Wayland and more stuff won't work on such a kernel - if you solve this problem, I guess figuring out some dirty hack for creating device nodes won't be an issue for you

[jamesbond]

What about devtmpfs?

If I read correctly technosaurus wants to do this inside his lxc container (or chroot jail, or whatever), and probably creating the nodes also in a controlled manner (not just for all devices).
If it is for the main system I agree we should all switch to devtmpfs.

[Iguleder]

... (not just for all devices).

Why not?

[Karl Godt]

udev-140 works with kernel 3.5 - NO FEAR !

[Iguleder]

Of course it does - it creates all device nodes on its own (e.g if a device node is not there already, it creates it).

Once you upgrade udev (to something more recent than 2009, to make it possible to use a modern graphics stack), it won't.

[jamesbond]

... (not just for all devices).

Why not?

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]

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).

[jamesbond]

that's the main weakness of jails, compared to virtualization

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.

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

[Karl Godt]

Mine looks now as:

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 $? ; }
}

Nice replacement for /sbin/pup_event_backend* files . Have to test it though .

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"

I guess that can be done by awk alone ..

[Karl Godt]

Above wasn't loading any modules .

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
        
}

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 >

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