> Yes, it does, sorry. Gives you why it was designed, how it operates, a complete history,

said it before, i'll say it again

no it doesn't

let me know if you want to help

> One of the changes that was made in this case was to move some of the functionality to a privileged, trusted, but user-space process, which would receive notifications from the kernel and then respond to them. This in contrast to functionality that runs entirely in "kernel space," which is more limited.

i have no idea what this means or what it is referring to.

It means that the Linux kernel runs with special privileges granted by the cpu, which no user process (not even one that runs as root) can possibly enjoy. This hardware-defined level is called kernel space. Everything else runs in user space.

https://stackoverflow.com/questions/...the-user-space

For me your story is quite strange. This is your first thread, and as you stated you are new to linux.
That is ok, just this is not where it begins. As you see you need to learn a lot to be able to understand the answers. So start with something else, which is not that difficult, not with udev.

And I said it before and I'll say it again: it does, and it's there for anyone to read. You obviously are not understanding what you're reading or asking, so there's not much anyone here can do about that.

Your question was exactly this: "why does udev exist? what was the need to develop udev?"
And under the "Rationale" section of the Wikipedia article (the VERY TOP): "To be able to deal with peripheral devices that are hotplug-capable in a user-friendly way, a part of handling all of these hotplug-capable hardware devices was handed over from the kernel to a daemon running in user-space. Running in user space serves security and stability purposes."

That is the "Why does it exist, and what the need was". Either you understand it or not.

The answer is very simple: because someone had an idea, tried it and everyone found it useful (at least quite a few).

> You obviously are not understanding what you're reading or asking, so there's not much anyone here can do about that.

can't argue with you there, but i'm here trying to learn anyway,

> That is the "Why does it exist, and what the need was". Either you understand it or not

i don't, at all, but my research into udev came up with an entirely different answer, udev exists as a conveniance to manage device nodes, which is entirely different then the nonsensical word salad on wikipedia.

It isn't "word salad"...those are clear English words and terms. And if you can't understand what's being said, why are you arguing about how it doesn't answer your question?? What exactly isn't clear??? And you claim to have done other research...but don't post a link to it or what it says. And you've got a group of experienced folks here telling you the same thing and somehow you are arguing that we're wrong.

Since that's the case, not much point in asking us. Good luck.

A long time ago, sysadmins had to manage their own /dev. This was done by looking in devices.txt, which is now at /usr/src/linux/Documentation/admin-guide/devices.txt. Files in there (/dev/) are "a window" (how I look at it - my terms) to linux devices. This was done with mknod, and by looking up major/minor numbers in the previously mentioned devices.txt. There was a helper script, called MAKEDEV (all caps), that would help you make groups of these devices to lessen the admin's work. You probably still have MAKEDEV and mknod laying around someplace. The result was a static /dev directory that often had more files than were needed to do the job. If a new device was added, the admin had to allow for this and pull out mknod. Then there were the file permissions of the individual device files. If you unplugged a device, the device node of it stayed in place.

Later, kdevtmpfs, via the kernel, took on much of this duty to make the /dev/ directory leaner. I ran this setup for awhile. IIR, I still had to make a few symlinks here and there. This approach assumes a sysadim that is willing and able to do this work, but what happens with distributions and how do they account of new devices plugged into the system on their users' machines? We can't have Ubuntu users flooding the help forums when they plug in a new device and it doesn't work.

The solution was udev, which watches what is plugged in and unplugged, and manages the /dev device area so the admin doesn't have to. To do this, it uses a complex system of config files (/lib/udev/rules.d/, /etc/udev) and a daemon along with an admin utility, udevadm. Udev exists to ease setup in distributions, to offload this burden from the admin on to a software subsystem. This is how it's done in most other operating systems like Windows or OpenVMS: the OS "just takes care of it" - the admin doesn't have to explicity create a COM1 or TXA0 device.

As more and more stuff began to rely on udev, it found its way into (almost?) all linux distributions. I ran a modified LFS for awhile, and resisted it until libusb required it. While it's techically possible to run without it, most all modern linuxes (linuxi?) have it. My issue is that, when something like this breaks, the admin is left to debug a large, complex subsystem he might know little about. Incidently, this goes for Avahi, PAM, Systemd, and Dbus as well.

1 members found this post helpful.