From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Fri, 30 Dec 2005 20:34:05 +0000 Subject: Re: new version of udev has different cd/dvd devices Message-Id: <20051230203405.GA6051@vrfy.org> List-Id: References: <43B313ED.40402@bl.com> In-Reply-To: <43B313ED.40402@bl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org 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 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. > >> 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. > > Just get rid of _any_ simple enumeration, for exactly the same reason a > > kernel devfs is completely useless. > > I don't think so - AFAIK, use of "%e" doesn't cause processes to hang due to > implementation bugs. (And that is, AIUI, exactly why the kernel devfs is > useless.) No, devfs is useless, cause it simply enumerates based on discovery order, that does not help anything if devices come and go, which can happen anytime with recent kernels and stuff like pci hotplug ... > > 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, 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. > What about device removal? What about swapping devices due to (for example) > interrupt problems? What about plugging the same (hot-pluggable) device into > a different port? > > [snip] > > Writing out rules is reliable, predictable and one can understand what's > > going on. > > I'd say exactly that about %e and module probing, as was before the event > order was randomised. Nobody forces you to use it, it isn't even part of the udev tree. You can stick with what you have or whatever you think is better. > > The %e is unfixable and will definitely die some day. > > Right now, to me, it looks fixable. Good luck, go ahead. You will surprise me if you come up with something useful. 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_id865&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