Is life without udev possible?
I'm not really a luddite - it is just that udev does nothing useful in my application and instead causes problems. Pat implies it it possible "with some tweaks". Does anyone know what those tweaks might be?
|
get a ps2 keyboard and try it out :)
|
Quote:
|
the kernel itself makes most of the needed nodes in /dev
of the things that it doesn't here's what i got so far what you look for depends on what your program needs #/dev/X0R -> null ln -s /proc/kcore /dev/core ln -s /proc/self/fd /dev/fd ln -s /input/mice /dev/mouse #/dev/rtc -> rtc0 ln -s /proc/self/fd/2 /dev/stderr ln -s /proc/self/fd/0 /dev/stdin ln -s /proc/self/fd/1 /dev/stdout (the two hashed i haven't looked at yet) then there are modules for devices, something like Code:
for i in /sys/block/*/device/modalias /sys/bus/*/devices/*/device/modalias /sys/bus/*/devices/*/device/modalias /sys/class/*/*/device/modalias Code:
for i in /sys/block/*/dev maybe some more things, idk PS i didn't put char devices as some have special directories in /dev |
What is wrong with the /dev that you have to install to boot with before tmpsysfs overlays it? My application is static and uses no modules. I need to add to /dev for a touch screen, which, of course, doesn't work. Maybe I could learn udev rules but since the touch stuff lives outside the kernel, I don't think udev can help. In any case, not using udev is easier than learning how to make rules. I did an install without udev but tmpsysfs is still laid on top of /dev.
|
/dev is a special kind of virtual fs, devfs
the kernel populates most of it automatically what rules do you need ? what are you doing anyway ? do you use usb ? do you know how to use modprobe and mknod ? |
Quote:
Quote:
Quote:
Quote:
Quote:
I have been using Slack since 4.0, but these provisions to make desktop users lives easier are beginning to get in the way. |
all devices in /dev are nodes
before they were all made at boot, that lead to problems with some corner cases (not just desktop ones) GKH decided it should be done by a userspace app (after HAL was hotplug then udev), despite other UNIX-es solving that problems properly example of a /dev node: bash-4.3# ls -l /dev/usbmon0 crw------- 1 root root 250, 0 Pro 17 15:14 /dev/usbmon0 c means it's a character device 250 is the major node number 0 is the minor node number so to make this node i would run mknod /dev/usbmon0 c 250 0 (system call is almost the same) to find out that numbers you would look into sysfs's /sys/class/usbmon/usbmon0/dev file (or the uevent file) bash-4.3# cat /sys/class/usbmon/usbmon0/dev 250:0 from what i know; (the documentation is non existent, as is usually the case with Kay Sievers and gang) there are no static versions for dynamic devices, just for one of a kind ones nothing that the kernel puts in devtmpfs gets replaced so if all you need is the dev node, that should be easy to make at boot bdw openwrt has it's own udev-like version, and hotplug is good documentation/example |
You don't need udev to have a functioning system, but it helps with hardware. Without udev you'll have to use mknod to statically assign device nodes in /dev manually, and rely on the kernel hotplugging system.
|
You can replace udev with:
1) eudev 2) mdev from busybox 3) hotplug from openwrt Usually Udev gets event from kernel on device installation and udev creates neccessary device nodes in /dev And devtmpfs doesn't handles it well. Or you can create static device nodes on /dev directory itself. Only if devices don't get changed in each instance. |
For your embedded system, mdev is the way to go. Just in case you didn't come across it yet, see also OpenEmbedded
and of course BusyBox. |
Quote:
Quote:
|
Quote:
Quote:
|
Quote:
|
Quote:
mount -t devtmpfs devtmpfs /dev /dev may be empty beforehand if you like. |
Quote:
hence NO documentation, 0, nada Kay is too smart to explain anything the hotplug doc i linked is the best documentation there is as for the /dev entries being nodes afaik they always have been, at least since 2.6 (maybe in 2.4 they werent, idk) |
Quote:
Quote:
|
Quote:
|
As a postscript to this, I am happy. I have 14.1 running without udev and with a monolithic kernel (no modules or initrd) and it is booting in about 12 seconds and everything works.
|
Quote:
|
Using mdev as an alternative to udev will require some heavy work.
I've been tinkering with a SlackBuild to build a working mdev solution for a few weeks now, but I need to get the rc.mdev init script crafted before I can try to test the package. Be heavily forewarned, mdev does not have rule-based auto-loading of modules. All it does is creates an instance of the device node and attempts to populate it based on it's configuration. If you want additional rule-based assignment of devices, such as input devices, you'll need haldaemon (hal with hal-info). Also, if you decide to disable udev, do NOT uninstall it. Several projects rely on libudev as a dependency, but don't actively use it. Plus, you'll need to use the xf86-input-keyboard/mouse/joystick drivers for input devices if you go with mdev. |
Quote:
that is not documentation on udev, but on writing against udev udev does A LOT of things that you don't know about and even the things you do know about (making nodes, loading firmware) are never explained in any way like that udev sends events to xorg-server you can also go check the source code to find almost no comments and absolutely non existent function naming convention (i counted 3 styles, one of them OO) in short it's about just a little less documented then X and it matters for udev more then your avg program in that there is only one way to do what it does not to mention that a page of ascii art drawings and half a page of text could explain it all anyway we were not here talking about udev api, but about what udev does to make those dev nodes PS if you can find me documentation on how logind/console-kit does anything, id be grateful PPS look at the udev's device struct to see something funny |
Quote:
or the usb laser Virtual keyboard |
You might go the devtmpfs route, really. It makes little difference in boot memory or kernel size, but you do have to set custom permissions after boot.
If you must go static, there's Documentation/devices.txt in the kernel source, which tells your where the devices are supposed to be. Use mknod if you have to do so. Also, /proc/devices can give a hint on where devices are located. There are also files in /sys that tell you about the nodes. For a command like `find /sys -name dev`, the actual contents of those dev files are the major and minor numbers for the device. You might have to figure out if the device is a block device, character device, or something else. Slackware can be done without udev, easily. But yeah, it helps to have a PS/2 keyboard. I think I'll find that reply and mod it up. A bit of precaution: You might look at the /dev directory of your system by booting from a utility disk, just to be sure that the static devs are still there. Also, if you want to slack off, you could just tar the devtmpfs /dev from a running system, then restore it as static devs from a utility disk, to have a nice starting point. Reboot using a devtmpfs-free kernel, and you should be good to go. |
Quote:
|
LFS has a good section on setting up static devices also:
http://linuxfromscratch.org/blfs/vie...s/devices.html |
Quote:
|
All times are GMT -5. The time now is 03:05 AM. |