udev, udisks, dbus and dd command

Question

i'm interesting to better understand what happen, at operating system level, when a new device (usb stick or ide/sata hdd) is plugged into a PC, that is from the kernel level to the userspace level. Moreover i would like to know at which level "dd" command works.

What I've understood is that, once an external drive is attached, the kernel "intercept" this event and informs the udev system that is always listening thanks to the udevd daemon. Udisks is the instance for collecting information about block devices. Udisks needs udev for this. Udisks is connected to the d-bus (dbus is not something only used by udisks; many programs use dbus for exchanging info). Via d-bus, anyone can connect to udisks and ask what's the current list of devices.

Question: when I launch the dd command, maybe it connects to d-bus to copy/image a drive ?

I also attach a picture taken from wikipedia that show the linux levels. Can you tell me, please, on that picture, the path beginning from the attached device to the instance of dd command ?

Thanks in advance.

Vincenzo.

Answer 1

That's really two questions:

1) dd is a normal user application, just like cp. Just like cp, it copies by issuing "read" system calls, getting the result, and then issueing "write" system calls. Unlike cp, you can set the block size for dd, which is why dd has always been traditionally used to copy block devices. But today, cp /dev/sdb /dev/sdc will do exactly the same thing as dd, and equally fast, as modern versions of cp (unlike maybe ancient versions) also always will read and write complete blocks.

Neither cp nor dd does something special to get a "disk layout" or anything like that, they just read until the operating system signals they are at the end.

2)

once an external drive is attached, the kernel "intercept" this event

The kernel doesn't really intercept this event, as all driver-level actions are already happening in the kernel. So when you attach an USB device, the USB host controller hardware notices that, generates an interrupt, and the USB host controller driver reacts to that, and then the various parts of the USB stack start to enumerate the new device, identify it's type, identify potential drivers, attach new block devices created by those drivers, etc.

udev is just a mechanism for the kernel to communicate these events to user-space, so user-space can react on them, e.g. by creating symlinks.

and informs the udev system that is always listening thanks to the udevd daemon.

Udisks is the instance for collecting information about block devices.

udisks is a desktop demon that the desktop uses to get information about block devices, because the desktop likes to do everything on the D-Bus. You don't really need udisks if you are not running a D-Bus desktop (and in fact, it doesn't run on some of my machines).

Via d-bus, anyone can connect to udisks and ask what's the current list of devices.

You can do this equally well by other means, e.g. looking at /dev or the information in /sys.

The whole udev - udisk - Desktop chain is only needed for the desktop to be informed when new block devices appear, or existing block device change state, so the Desktop can pop up fancy windows, or whatever. If you use Linux in the traditional way and don't need a fancy window when you put it an USB stick, you don't need this.