Hi:
In my machine I run Slackware 14.0. I would like to dispense with udev and go back to devfs and the devices being statically managed. In the ANNOUNCE.14_0 file of Slackware 14.0, it says: I'm the only user and if the only price I'd pay is, according to the quote, to put the mount command path into the user's PATH variable and issue a 'sudo mount /dev/xxx' the few times I use my flash stick, I would gladly go back to the old system. There would remain the thing of mounting and dismounting optical disks, but this is a very little burden that I had already got used to. I know before hand that there will come the inevitable question "Why do you want to do such a thing?", therefor I'm trying to answer it at this point. To make the answer complete, I should say that the use of udev has added some complications I would gladly dispense with.

I will sacrifice my DOS/Windows partition and use it to install a second instance of slackware 14.0, so I may experiment without risk of damaging valuable data. I commented out the invocation of /etc/rc.d/rc.udev in rc.M (later on I discovered it can be run from rc.S too), but the result was of a catastrophic type. I also remember having read the following in file rc.S: By the way, I don't either wish any hotplugging capability. I remember having painstakingly written down on paper all of the entries listed by lsmod, and having made sure /etc/rc.d/rc.modules contained all of them, before making /etc/rc.d/rc.udev non-executable (this was part of a second try I did, I think).

So, the many "buts" above (code block) and my unhappy experience tell me that turning udev off may be not an easy thing to do. But that is really the contents of my question. What is my definition of ease? I reformulate: what would be the degree of knowledge I would need in order to turn udev off in a tidy way? I could also revert to some previous Slackware distribution, but that would be a rather drastic measure, I think.

You should first be familiar with the /dev directory and its layout and making devices nodes manually using mknod. Read /usr/src/Documentation/devices.txt.

Be aware e.g. that to use an USB key you'll have to create the device node yourself before mounting the key.

Good luck.

1 members found this post helpful.

That I will do. Thanks Didier.

Re-reading you initial post I'm under the impression that what you actually want is get rid of the stuff that allows auto-mounting of devices.

If I'm correct IMO you'd better keep udev but get rid of udisk and udisks2 then. I don't now how/where the daemons are called though, so you'll have to find by yourself or ask.

I don't know if there are some settings needed for that depending on the desktop(s) you use, as I I'm a fluxbox user.

Please forgive the use of superfluous quotations, but somebody could post while I am writing. Your suggestion about disposing of udisk and udisk2 is welcome. In my attempt to get rid of some undesirable side effects that I associate with the use of udev, I'll first try your suggestion. There is perhaps some interaction between xfce 4, the desktop environment I am using at present, and udisk, udisk2, as may be inferred from the following, written by Volkerding himself (optical disk #1://ANNOUNCE.14_0): That, I will deal with after having properly disposed of udisk/udisk2. There is also a upower, by the way. The automount capability was in my opinion making me life difficult. However, the fundamental cause of my original wanting to dispense with udev and hotplugging is the continuous, never ending access to the hard disk, for as long as the machine is turned on. I once detected this begins at the exact moment when rc.udev is invoked in the init scripts (which starts udev). Whether this effect is due to udev alone or can be independently solved, I would not like to elucidate right now. But I'm afraid, on second thought, that disabling automount will do little for it. But disabling automount capabilities will anyways be a first step in the direction I aim at. Please forgive me if I was too verbose and thanks again for your generous help.

In my small system with less than 16MB available memory I don't use udev but I still use devtmpfs. Also I wonder why on your system udev accesses the hard disk endlessly.

In regard to the latter, I reference you to this link, started by me because of the very same issue. In regard to the former, does that system use dynamic allocation of the nodes in /dev, or are these a set of static and fixed nodes? Put more simply, are the devices in your system static devices?

Did you figure out with block tracing that it's udev who was accessing your harddisk?

Dynamic. I have a few USB things there. Either dynamic or static, devtmpfs doesn't harm. Does it?

I can only answer your question with the following, as I do not know what "block tracing" is:
("this begins" = "the disk begins being continously accessed").
I'll assume it doesn't. If you are a slackware user or by any means know something about it, when was devtmpfs for the first time implemented in that distribution? Or even a better question: what would be the drawbacks of entirely falling back to devfs and forget even about devtmpfs?

Anyways, I must read .../Documentation/devices.txt very carefully, assuming it's written in a language more or less accessible to me first. Then proceed with the issue of dispensing with udisks, udisks2. Or maybe the other way around. The ultimate goal being to put and end to the continuous hard disk access. Any further comment on the continuous hard disk access issue I will post it in the thread referenced to in post #8. My immediate goal is to dispense with udisks, udisk2 and see what happens.

Since this thread is marked as SOLVED I won't explain further.

But one thing -- devfs no longer exists in newer kernels. You may want to resort to statically created device nodes if you don't want to use devtmpfs.

Just removing udev will not do the kob, you also need to recompile several packages that are built against udev. I don't which these are on Slackware, but on CRUX these are:
- libdevmapper
- util-linux-ng
- mesa3d
- xorg-server

Since Crux only comes with a very minimal installation there may be more packages on Slackware that are built against udev.

That was the intention stated at the beginning of the thread that is, to rely on static devices alone. Until somebody cares to convince me to the contrary, I do not see what the advantages of using dynamic devices can be in my case.

I am perhaps being a bit naive, but have you seen this (it's from /etc/rc.d/rc.S, Slackware 14.0 x86_64, the distribution I am dealing with)?:
That does not seem to imply the need to recompile any packages, TobySGD. Maybe I need to know first what "to remove udev" exactly means. rc.S only speaks about "turning off udev".

Removing udev and disabling it are basically the same, it becomes unavailable for services that are built in the way that they need it. These services will not run flawlessly anymore.

And why would the rc.S script author express himself in such terms? Could not he be Volkerding himself? Infact, I donot find any contradictions between said script and your words. Only that Volderding, should he be the author, would be forgetting to explain an important thing.