After some goggling, I have found there to be very little in the way of information about what eudev actually means, besides a new name so I figured it deserves a new thread.
Here are my two questions:

Most pressing, will it allow for separate /usr and /var without an initramfs?
A more long term question, is Gentoo intending to replace udev with eudev as the "standard" option?

Most pressing, will it allow for separate /usr and /var without an initramfs?
A more long term question, is Gentoo intending to replace udev with eudev as the "standard" option?

My 2cts about this. Mind you ! Might not be worth more than 1/2 ct !

1/ Of course you know who Greg KH is !
2/ I understand that he is also a Gentoo dev and a member of Gentoo's Council.

Well well... this being considered then, my opinion is that, in order for whatever udev fork project to be successful AND sustainable AND in a position to replace upstream's udev, that project MUST be supported / encouraged / backed / blessed by Greg KH.

I do not understand that he does. (to say the least) => I do not believe eudev will replace udev as the standard option.

From what I understand separate initramfs-less /usr is said already broken. I am sure that maintaining this possibility is going to require more and more efforts from the project who will be forced to diverge every day more from upstream. So... I think that... it will just be a matter of workforce/time.

Well... do not worry that much... I am naturally pessimistic !
And of course, I transmit all my encouragements to the project members. But... these encouragements... are worth 1/2 ct too ! _________________

From what I understand separate initramfs-less /usr is said already broken.

For the normal udev, this is true. The other nameless udev fork has solved this issue, but it seems to be less active since eudev made its entrance. It is exiting to see a fork hit the tree, its just it would be nice if it fixes some of the major flaws with upstream version, in addition to cutting systemd._________________First things first, but not necessarily in that order.

I saw a post on superuser where the 3.6.10-gentoo-sources requires eudev... anyone try it yet?

The poster you mention obviously knows nothing of what he is writing about !
I saw that message. From what he posts it is obvious that the dependency on eudev was pushed by the virtual package ! Not by whatever-kernel-source package ! _________________

...
I have found there to be very little in the way of information about what eudev actually means, besides a new name
...

There was a thread for discussing what name to give the new udev fork (https://forums.gentoo.org/viewtopic-t-942670.html). I didn't get in on that one. There was a vote as to whether to keep the working name udev-ng or a different one. Out of the (drum roll) 19 votes cast, no one picked eudev. Some of the discussion covered the eudev name, but focused mostly on "eu" as an abbreviation for either Estados Unidos (normally abbreviated EE.UU.) or European Union.

Richard Yao, one of the eudev developers, stepped in to point out the name came from an Ubuntu developer who had floated the idea of Embedded Udev.

Let me suggest another interpretation for you: the Greek prefix ευ (transliterated as eu) modifies a word to give it a spin of good, normal, happy, and/or pleasing. One of my favorite words using this prefix comes from Aristotelian philosophy. Eudaimonia: the state of happiness and well-being that comes from living a good life.

I saw a post on superuser where the 3.6.10-gentoo-sources requires eudev... anyone try it yet?

Running 3.6.10 with stock udev right now, posting this.

OTOH a problem recently surfaced, where my /dev/dvd, /dev/cdrom, etc symlinks are no longer getting created. I don't know when that happened - it just showed up yesterday when my wife tried to play a dvd. I looked, and it has happened on all 4 up-to-date systems in the house. (I use genkernel, boot with initramfs, and manage my own kernel configs.)_________________.sigs waste space and bandwidth

I am currently using the braindamaged fork since it allows for a separate /var and /usr which I have. I did see the naming thread, but as far as I can see there has been no information about whether it fixes udev's broken approach to /usr or if it just fixes the problem of gnomeOS taking over the init process. Don't get me wrong, this is important, but I prefer both._________________First things first, but not necessarily in that order.

After some goggling, I have found there to be very little in the way of information about what eudev actually means, besides a new name so I figured it deserves a new thread.
Here are my two questions:

Most pressing, will it allow for separate /usr and /var without an initramfs?
A more long term question, is Gentoo intending to replace udev with eudev as the "standard" option?

Separate /usr is supposed to be supported tho doubt it's already working as intended. Let's wait for the first release. As for the second question, unless systemd upstream screws up royally it will take quite a while before eudev replacing systemd-udev as the default will be discussed.

I saw a post on superuser where the 3.6.10-gentoo-sources requires eudev... anyone try it yet?

Running 3.6.10 with stock udev right now, posting this.

OTOH a problem recently surfaced, where my /dev/dvd, /dev/cdrom, etc symlinks are no longer getting created. I don't know when that happened - it just showed up yesterday when my wife tried to play a dvd. I looked, and it has happened on all 4 up-to-date systems in the house. (I use genkernel, boot with initramfs, and manage my own kernel configs.)

It is the modus operandi of Mr Suominen to do things like this where he patched udev which broke the creation of /dev/cdrom, then got r9 immediately stabilized and promptly removed the last working version, r8, leaving us, the users, with no symbolic links that most programs use to access the cdrom drive. Then to make things worse, there is no clear understanding how these links are supposed to be created. Are the users supposed to create rules manually?

Since Mr. Suominen so utterly broke this feature without any documentation or quick fix on how these links should be created with r9, you can either create them manually or recover udev-171-r8 from the cvs archive, host it in your local portage overlay and mask all versions above r8 until this problem is fixed.

Newer versions of udev ebuilds hint at what has happened in later versions:

ewarn "Upstream has removed the persistent-net and persistent-cd rules"
ewarn "generator. If you need persistent names for these devices,"
ewarn "place udev rules for them in ${ROOT}etc/udev/rules.d."
ewarn "Be aware that you cannot directly swap device names, so persistent"
ewarn "rules for network devices should be like the ones at the following"
ewarn "URL:"
ewarn "https://bugs.gentoo.org/show_bug.cgi?id=433746#c1"

The odd thing about this is that if you already had the old persistent rules in that directory and you didn't remove them, udev ignores both of them leaving you without a symlink to your cdrom drive device.

I saw a post on superuser where the 3.6.10-gentoo-sources requires eudev... anyone try it yet?

Running 3.6.10 with stock udev right now, posting this.

OTOH a problem recently surfaced, where my /dev/dvd, /dev/cdrom, etc symlinks are no longer getting created. I don't know when that happened - it just showed up yesterday when my wife tried to play a dvd. I looked, and it has happened on all 4 up-to-date systems in the house. (I use genkernel, boot with initramfs, and manage my own kernel configs.)

It is the modus operandi of Mr Suominen to do things like this where he patched udev which broke the creation of /dev/cdrom, then got r9 immediately stabilized and promptly removed the last working version, r8, leaving us, the users, with no symbolic links that most programs use to access the cdrom drive. Then to make things worse, there is no clear understanding how these links are supposed to be created. Are the users supposed to create rules manually?

Since Mr. Suominen so utterly broke this feature without any documentation or quick fix on how these links should be created with r9, you can either create them manually or recover udev-171-r8 from the cvs archive, host it in your local portage overlay and mask all versions above r8 until this problem is fixed.

And yes, I of course admit that this is a direct result of me not seeing this change affecting this feature of udev. -r9 solves one problem, while introducing another, like I mentioned in the bug. In the end, staying with 171 is a dead end, and next to nobody is maintaining it.

So while I don't like the tone of your post, I'm willing to accept any patches you have to solve this issue so that it doesn't reintroduce the regression with -r8 and later 3.x kernels.

(And I don't mean to sound in any way rude, these are just the facts we are in...)

After some goggling, I have found there to be very little in the way of information about what eudev actually means, besides a new name so I figured it deserves a new thread.
Here are my two questions:

Most pressing, will it allow for separate /usr and /var without an initramfs?
A more long term question, is Gentoo intending to replace udev with eudev as the "standard" option?

Separate /usr is supposed to be supported tho doubt it's already working as intended. Let's wait for the first release. As for the second question, unless systemd upstream screws up royally it will take quite a while before eudev replacing systemd-udev as the default will be discussed.

Right, I don't think setting eudev as default is even a topic yet, it's something we will reconsider far in future...

Right now the viable options are:

- Use 196-r1 and initramfs (if you have sep. /usr)
- Switch to eudev and experiment

With my very limited understanding if the situation, the issue is just with a separate /usr as there are dependencies in /usr/lib for some of the boot software. Of course a separate /var could be an issue if you have boot time dependencies somewhere down that path.

With my very limited understanding if the situation, the issue is just with a separate /usr as there are dependencies in /usr/lib for some of the boot software. Of course a separate /var could be an issue if you have boot time dependencies somewhere down that path.

Well, there are already a couple of things in /var/lib too. Of course these are for the time being not very important because associated services can be launched post-mount without any particular impact.
As a matter of fact, my question was more to be understood as : Are they already known intentions to fill /var/lib with material that would be needed by services that must compulsorily be launched pre-mount ?_________________

Right now I've got an ugly kludge in /etc/local.d to build my symlinks. Of course the correct way is to write a udev rule, but I haven't learned how to do that, yet. Now that I know that a fix is on its way, I think I'll just wait. Fortunately my ugly kludge was written to be graceful in this situation, so it's just a matter of time._________________.sigs waste space and bandwidth

- Use 196-r1 and initramfs (if you have sep. /usr)
- Switch to eudev and experiment

I like option 2. At the moment it is not quite working as expected. I have a root on lvm setup with just about every directory as its own partition in the lvm. For some reason, lvm is failing to start with eudev so the boot process fails. This was working with braindamaged udev, and I made sure the only thing to change at that time was udev -> eudev.

It works when I pull out my 'rescue' initramfs that was built by genkernel, which does mount /usr._________________First things first, but not necessarily in that order.

The resulting system neither boots cleanly nor functions properly. I didn't see/enumerate everthing that went wrong. For starters, eth0 went missing. I suspect that caused most of the problems, but in addition something really weird happened with the keyboard and X. X accepted no input from the keyboard - I couldn't log in. I didn't think to check the mouse - sorry about that one. One other oddity... the system didn't switch to framebuffer early in the boot, as it normally does. It remained in text mode until X started.

However the Magic SysRq key worked, so the keyboard actually was recognized by the kernel. This is all the stranger, because I would have expected the changes to completely kill the keyboard or leave it completely functional - not this half-state. Any Magic SysRq got me back to a text screen where I logged in as root, commented out the lines above, and backed everything off.

Since I must be a bit of a masochist, I think I'll go build kernel-3.7.0 and try that. If there's something specific I can do to bug this out, please let me know._________________.sigs waste space and bandwidth