Armin K. wrote:
On 24.5.2015 19:26, Bruce Dubbs wrote:
Armin K. wrote:
On 24.5.2015 18:06, Bruce Dubbs wrote:
Actually I've been toying with the idea of using a custom script to make
a series of mknod commands to add things I need at boot. Then I can
skip udev completely. In the final analysis, what does it add for us?
About the only thing I can think of that affects most users is that it
may change some permissions in /dev.
Udev doesn't create any device nodes for some time now. It's handled by
devtmpfs. What it does is:
It changes permissions, creates symlinks and in certain cases, renames
device
nodes.
It monitors devices addition and removals which is done by kernel
(hotplug) and,
depending on the nature of the device, applies a certain rule upon it,
such as
create a generic symlink, set up permissions, ownership, renaming, etc.
The latter is important for some software, where it relies on udev
through
libudev to notify them about device additions and removals. One such
software is
Xorg's input drivers, which is why you can plug in a mouse after X
server has
been started and it will be recognised automatically, without having a
need to
restart the Xorg server and configure the device through xorg.conf.
There are other packages that rely on libudev for similar stuff and
it's mostly
related to handing external devices such as printers, scanners,
cameras (web
cameras and professional digital cameras), etc. USB device handling
through
libusb-1 is done through libudev too.
Yes, for most workstations, it generally is only useful for usb
devices. For a server, we may not want to even enable usb. There may
be a need for dynamic hotplug of pci devices or scsi drives on a server,
but I think that could be done without udev.
On a lot of servers, such as those used for the linuxfromscratch.org
servers, there is no capability to plug in any device.
You wouldn't need any scripts. Hotplug is done by the kernel. What udev does is
act on the hotplug - notify the software that may be expecting it and apply
certain rules on the device - if any.
So, if no software is specifically listening for a SCSI or PCI device and wants
to know when it's available so it can do something with it, you don't need udev
at all.
Good point. I've done some timing checks on boot and although it's not a
significant amount of time, the udev boot script takes the longest. For instance:
May 23 23:05:31 -05:00 (none) Mounting virtual file systems: /run /proc /sys OK
May 23 23:05:31 -05:00 (none) Bringing up the loopback interface... OK
May 23 23:05:31 -05:00 (none) Setting hostname to toshiba-lfs... OK
May 23 23:05:31 -05:00 toshiba-lfs Populating /dev with device nodes... OK
May 23 23:05:36 -05:00 toshiba-lfs Activating all swap files/partitions... OK
May 23 23:05:36 -05:00 toshiba-lfs Mounting root file system in read-only
mode... OK
May 23 23:05:36 -05:00 toshiba-lfs Checking file systems... OK
May 23 23:05:37 -05:00 toshiba-lfs Remounting root file system in read-write
mode... OK
May 23 23:05:37 -05:00 toshiba-lfs Mounting remaining file systems... OK
May 23 23:05:37 -05:00 toshiba-lfs Cleaning file systems: OK
May 23 23:05:37 -05:00 toshiba-lfs Creating files and directories... OK
May 23 23:05:37 -05:00 toshiba-lfs Retrying failed uevents, if any... OK
May 23 23:05:38 -05:00 toshiba-lfs Setting up Linux console... OK
May 23 23:05:38 -05:00 toshiba-lfs Starting system log daemon... OK
May 23 23:05:38 -05:00 toshiba-lfs Starting kernel log daemon... OK
May 23 23:05:38 -05:00 toshiba-lfs Bringing up the eth0 interface...
May 23 23:05:38 -05:00 toshiba-lfs Adding IPv4 address 192.168.0.51 to the eth0
interface... OK
May 23 23:05:38 -05:00 toshiba-lfs Setting up default gateway... OK
May 23 23:05:38 -05:00 toshiba-lfs Bringing up the wlan0 interface... SKIP
May 23 23:05:38 -05:00 toshiba-lfs Starting SSH Server... OK
udev takes 5 seconds of the total 7 second boot time.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
