[gentoo-amd64] Re: udevd event find_free_number?

[Duncan]

Richard Fish posted
<7573e9640604032014p7dbd2358raa41f90c21097021@××××××××××.com>, excerpted
below,  on Mon, 03 Apr 2006 20:14:43 -0700:

> On 4/3/06, Jack Cuyler <jjvcuyler@×××××××××××××××.com> wrote:
>> When booting, I get an error message that "find_free_number" doesn't
>> work, will be removed, and shouldn't be used.  I've googled, but the
>> best I can find is something on a debian list to the effect of, "Yes,
>> that's right.  Don't use it."
>>
>> My question is, how do I disable it?
>
> Check /etc/udev/rules.d/*.  If you have any rules with "%e" in them, you
> will get this warning.  Although, I see the cdrom rules in 50-udev.rules
> is still using %e, so I'm personally waiting to see what replaces this
> before I fix my rules...

Interesting this should come up, as I was getting tired enough of the
message myself to just be getting ready to go looking.  Having not done so
yet, the above confirms what I suspected, and I yet believe the following
is safe to say...

Greg KH, one of the guys on the Gentoo kernel team and the one that makes
the most changes to our udev, according to the changelog, is one of two or
three that were responsible for udev in the first place.  He's no longer
responsible for it upstream, as he has enough other stuff on his plate
that likely didn't fit so well, but as the biggest proponent of udev (he's
had several white papers and speeches on it, look it up) and one of the
original three, it's safe to say he knows it inside and out and pretty
well keeps up with upstream.

Additionally, GKH is kernel lieutenant for device drivers -- /that's/ the
big thing on his plate and a driving force behind the udev thing in the
first place, for him.  It's safe to say as a result of that he continues
to cooperate very closely with the udev upstream, and they with him --
closely as in on a close to daily basis, or things will break as the
kernel and udev will get out of sync.

Finally, in addition to the volunteer hats he wears with Gentoo and as the
mainline kernel drivers lieutenant, his paying job is I believe doing the
/same/ things for Novell/SuSE.

Suffice it to say that it's rather unlikely we'll be left high and dry
with a udev implementation that doesn't work, unless you've  modified your
rules significantly beyond the default.  That's the reason those warnings
haven't been an urgent investigative matter, here.  If something does get
broken, it's going to be only for a very short period and as the result of
normal development snafus.  You'll only likely see it if you happen to
sync in the period of hours that it's broken before it's caught, and
happen to reboot then too.  Even then, chances are it'll be something
non-critical that  breaks, something like CD/DVDs (in this case), that
aren't necessary for maintenance mode.  (Of course, if you have to boot
your liveCD or whatever backup, you'll be using the old and well tested
setup on the liveCD itself, not bleeding edge one that happened to break
for a few hours, and you had the bad enough luck to catch the sync at
exactly the wrong time.)

The warnings are just that -- warnings of deprecation.  No new use of the
warned feature should be made, as the feature is deprecated.  However,
the process of deprecation is there precisely to allow some changeover
time, so the system is working as it's supposed to.  As long as you've not
made your own customizations using that feature and as long as you
properly etc-update after your udev upgrades, before rebooting, and as
long as you always  keep at least one known working kernel when you
upgrade that (testing the new one before entirely removing the old
one), you should be fine, barring the occasional routine breakage that
should be expected running ~arch, if that's indeed what  you /are/
running.  (I don't believe stable would have the warning yet, but I may be
wrong.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@g.o mailing list