From: Kay Sievers <kay.sievers@vrfy.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: new version of udev has different cd/dvd devices
Date: Fri, 30 Dec 2005 21:58:44 +0000 [thread overview]
Message-ID: <20051230215844.GA6526@vrfy.org> (raw)
In-Reply-To: <43B313ED.40402@bl.com>
On Fri, Dec 30, 2005 at 09:00:12PM +0000, Darren Salt wrote:
> I demand that Kay Sievers may or may not have written...
>
> > On Fri, Dec 30, 2005 at 07:12:21PM +0000, Darren Salt wrote:
> >> I demand that Kay Sievers may or may not have written...
> >>> On Fri, Dec 30, 2005 at 07:09:20PM +0100, Marco d'Itri wrote:
> >>>> On Dec 30, Greg KH <greg@kroah.com> wrote:
> >>>>> Or we can just stick with the rules we have today that use %e just
> >>>>> fine, as it emulates exactly what a static /dev would have done, and no
> >>>>> one is complaining about it :)
> >>>> People are complaining about it because events are not received in bus
> >>>> order anymore, so the names randomly change (and since there is no
> >>>> locking often the same links is created for two devices).
> >>> Exactly. That's the reason why it will be removed.
> >> So, basically, you're removing something which *worked* here because of an
> >> unrelated change which broke it.
>
> > It never worked reliably for modular kernels.
>
> Hmm. I'm using mostly monolithic, and it's failing regardless.
Sure, that's expected, cause your naming rules are broken.
> >>>> But still, I'd rather keep it as long as possible since half broken is
> >>>> better than totally broken and I do not have a replacement ready.
> >>> That doesn't makes sense. %e it conceptually completely broken and
> >>> offering something that can't work does not give any value.
> >> Can you provide instances in which it *doesn't* work, given events
> >> received in bus order?
>
> > Plug in/out any device on any bus, reboot and all your silly numbers will
> > change. That's no longer acceptable with current system requirements.
>
> That's a known effect and, as such, can be routed around. For some devices, I
> can see that this can be a problem; but for others, it may well be perfectly
> acceptable.
"Some devices" concepts are exactly that we are working on to get rid
of. Why are you running an explicitely marked as "unstable" system, if you
have no clue what we are working on?
> I know that (given the previous, stable, naming) removing and not replacing
> the sound card here in my main Linux box would cause the on-board sound
> hardware to be "card 0" rather than "card 1". That's acceptable and expected
> (I'm allowing ALSA to automatically number them because, until fairly
> recently, this worked reliably).
Then you never used USB sound devices, like headsets or something
else. Again, if you lack of the needed experience in the area or ability
to imagine the picture, please stop posting this nonsense.
> [snip]
> >>> Write out a rule at discovery (from udev itself) for every unconfigured
> >>> device and you get a sane enumeration, that will not change at next boot.
> >> ITYM "sane enumeration that will not change".
>
> > There is by concept no "sane enumeration" on a dynamic system and will
> > never be. But seem you don't get the picture at all.
>
> If the user says that "these parts of the system are static" (and I say that
> much of my system is static), why *shouldn't* some enumeration be considered
> sane?
Cause _nothing_ is static today. Get used to it.
> >> If, with no devices previously configured, it differs from what would be
> >> done with events sorted into bus order, I for one will consider it broken
> >> for the simple reason that it cannot be predicted from bus order.
>
> > Again, seems you have absolutely no clue what all this is about, do your
> > homework before posting such nonsense.
>
> For "bus order", read "whatever order happens to have been used by older udev
> which provides stable naming given the same hardware configuration". This
> looks like bus order from where I'm sitting.
Repeating the same stuff again and again doesn't add any value to it.
> If a newly-upgraded udev happens to generate its own rules which provide
> different naming, well, that's breakage right there: I could insert a disk
> into one CDROM drive then be surprised that I get a "drive empty" error
> because udev has called the wrong one (the writer, /dev/hdd) /dev/cdrom.
No, definitely not. Your broken rules have renamed it. Fix them and
everthing is fine.
Kay
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
next prev parent reply other threads:[~2005-12-30 21:58 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-28 22:38 new version of udev has different cd/dvd devices Moshe Yudkowsky
2005-12-28 22:50 ` Marco d'Itri
2005-12-28 23:29 ` Kay Sievers
2005-12-29 0:10 ` Moshe Yudkowsky
2005-12-29 0:22 ` Marco d'Itri
2005-12-29 0:44 ` Moshe Yudkowsky
2005-12-29 13:20 ` Phil Howard
2005-12-29 13:36 ` Marco d'Itri
2005-12-29 15:18 ` Phil Howard
2005-12-29 16:57 ` Kay Sievers
2005-12-30 7:46 ` Greg KH
2005-12-30 13:45 ` Phil Howard
2005-12-30 18:09 ` Marco d'Itri
2005-12-30 18:16 ` Darren Salt
2005-12-30 18:49 ` Kay Sievers
2005-12-30 18:56 ` Kay Sievers
2005-12-30 19:12 ` Darren Salt
2005-12-30 19:16 ` Kay Sievers
2005-12-30 19:47 ` Darren Salt
2005-12-30 20:34 ` Kay Sievers
2005-12-30 21:00 ` Darren Salt
2005-12-30 21:45 ` Kay Sievers
2005-12-30 21:58 ` Kay Sievers [this message]
2005-12-30 22:51 ` Darren Salt
2005-12-30 23:02 ` Darren Salt
2005-12-30 23:47 ` Marco d'Itri
2005-12-31 0:04 ` Kay Sievers
2005-12-31 0:20 ` Darren Salt
2005-12-31 0:39 ` Marco d'Itri
2006-01-02 10:35 ` Martin Schwenke
2006-01-04 18:48 ` Patrick Mansfield
2006-01-04 21:23 ` Darren Salt
2006-01-05 12:27 ` Marco d'Itri
2006-01-05 17:03 ` Greg KH
2006-01-05 17:52 ` Greg KH
2006-01-05 18:50 ` patman
2006-01-06 0:50 ` Greg KH
2006-01-06 3:40 ` patman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20051230215844.GA6526@vrfy.org \
--to=kay.sievers@vrfy.org \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).