Okay, then we've got a misunderstanding with respect to custom compiled software. The location pasted above is the upstream source of udev - in other words, that's what the udev developers release. You can certainly get that and compile it locally (as you already know :)), but there are often some other things that need to be taken into account to make sure the whole system is going to play nicely with it (this is especially important with respect to udev).

By a "stock" system, I mean a full installation of Slackware 11.0 that has not been modified. For the purposes of udev development testing, the important parts are the kernel and the init scripts. In order to get good (usable) feedback from testing, we like for people to use the official 2.6.17.13 kernel from /extra or the 2.6.18 kernel from /testing (or the 2.6.18.7 compiled from the same config) and our modified versions of the init scripts as included in the sysvinit-2.86 package.

If you've figured out all (or even most) of the needed changes to stuff for newer udev (especially the ones needed to the rules files), then we'd definitely love to get you involved in testing our stuff.

In reference to your changes of rc.* - well, I understand; sometimes there's just no way around it, and even when there is, sometimes it's the best way. That being said, modifying the stock rc.* scripts (especially rc.{S,M,6}, make upgrades a tremendous headache. Once you go through an upgrade cycle and fight with trying to figure out if your changes are even needed any more, where to put them, and so on, in the new scripts, you'll probably decide that rc.local is a *wonderful* place to put things after all... ;-)

:) LOL @ rc.local.. Hehehe I have a bunch of things in there.. My hdparm settings are in there (rather than make **another** rc.file (which I did first) I just put my IDE device IO settings, save-settings, power-down settings, and also rc.local initializes my motherboard HWsensors stuff.)
Umm, as far as a stock installation, I guess mine doesn't count. However, I do have almost 300 GB free, and it would be small beans to install another Slack-11 installation in another partition, fresh off of the CD's.. In fact, I have been meaning to do this for some time, as it would be a perfect learning/testing ground where I wouldn't risk my actual 'real' install.. You should know, I came full-speed from Windoze XP about 2 months ago after it DESTROYED my old HD and I finally 'threw it out the window' (Windoze I mean, once and for all ;) ) so I am far from an expert, but I am definitely a tuner/tweaker/perfectionist when it comes to this puter :).
That said, I'd be happy to install a 'stock' slack-11 with which to play with your new udev's, for the good of all.
Keep me posted.
Sasha

Just an update for anyone else who might come across this thread, the issues of udev not being able to "rmdir" due to the fact that /dev is a "read-only filesystem" and the "file exists" error when the kernel/boot scripts try to create symlinks which already exists is, indeed related to the kernel config.

I'm running 2.6.24 which I downloaded from kernel.org and just compiled and installed myself. With the stock kernel, no error messages on boot; with the custom (i.e. configured to fit my machine, as opposed to the configuration which comes with Slackware 12) kernel, I get hundreds of these errors. Other than slowing down the boot process, wasting my battery, and annoying me, they don't seem to have any effect. I still have to work on my configuration to get my sound card working and such, but I was hoping that I could get this udev business sorted out first. Since I'm not sure how to find out which options cause it, nor how to find out if my kernel has been compiled "incorrectly," I'm a bit stuck on the "fixing udev errors" front.

I'll post back if I figure it out. In the meantime, if anyone has any suggestions...

I had this same problem; I believe the solution was to enable tempfs support in the kernel under "File systems" -> "Pseudo filesystems" -> "Virtual memory file system support".

That worked for me, no more udev boot errors. Thanks. By the way,
it makes sense because rc.udev checks for tmpfs, which I will have to
look more in detail to know what it does.

Also, the boot message "Triggering udev events" appears twice in my boot,
one some place early and the other one near the end, second one adding "--retry-failed". Don't know what this is.

I reverted back to the stock Slackware 11 configuration and it fixed my problem. I just checked and saw that tempfs is, indeed, enabled. For anyone who's looking for it in the kernel config (as of 2.6.24):

-> File systems
-> Pseudo filesystems
-> Virtual memory file systems support (former shm fs)