On Tue, 24 Jan 2006 12:59:14 +0100 "Peter Zubaj" <[EMAIL PROTECTED]> wrote:
> > >On Tue, 24 Jan 2006 11:27:20 +0000 > >James Courtier-Dutton <[EMAIL PROTECTED]> wrote: > > > >> Sergei Steshenko wrote: > >> >> This has ZERO to do with ALSA, so why did you post it here? > >> >> > >> >> James > >> >> > >> > Because: > >> > > >> > 1) the thread is about stable ABI, among other things; > >> > 2) because people complain HERE that older version of ALSA with older > >> > kernel version used to work and after the upgrade ALSA stops working; > >> > 3) because with stable ABI people would be able to simply use old BINARY > >> > versions of ALSA with newer kernels and thus have no problem. > >> > > >> > P.S. On Mandriva 2006.0 'xpdf' is broken. So, being constructively lazy, > >> > I just replaced it with the one from Mandriva 10.2. Of course, I did this > >> > by picking Mandriva 10.2 'xpdf' RPM. That is, I reverted to older BINARY > >> > version. > >> > > >> > I believe that ALSA users should have the ability to simply revert to > >> > older > >> > binary version of ALSA as well. > >> > > >> You can currently use kernel alsa driver and userland alsa-lib with > >> different version number, and for some people it will work. > >> But a majority of the problems are caused by bugs being fixed in newer > >> versions. The bug fix might require changes to alsa-driver or alsa-lib > >> or both. > >> So, even with an ABI, people will still have problems. In fact the > >> kernel alsa ioctrl interface has not changed in a long time, so in > >> effect there has been an ABI for a considerable amount of time already, > >> but users still have problems. > >> > >> Summary: > >> Even if we had what you request, it would most certainly not be "no > >> problem" for the user. > >> > >> James > >> > > > >In simple English, are you saying that, for example, fixing a bug > >related SB (emu- whatever) can break ICE1724-based M-Audio ? > > > >If yes, is it the case with Windows ? > > > > Alsa (and many linux drivers) reuses many parts for diffrent cards (for > example AC97 codec code). > Yes, fixing bug for one card can result in bug in other card used same common > part. But there are many cases where fixing bug in common part fix many cards. > In windows, drivers do not share common parts - every card driver is build > from other sources. If you want binary drivers, abi stability, why don't you > just use windows. > > Peter Zubaj I want the best of the two worlds - that's why. Regarding details of implementation. Let's suppose the common part (like the AC97 code) is implemented as included code or as a subroutine. If somebody reports a problem with particular card, and it's not at all obvious that fixing the problem for the card won't break other cards, then instead of the (included file/subroutine) common for all the AC97 cards a "private" modified for the particular card copy should be used. Yes, there will be a headache of keeping registry of what is private and what common, but, I think, not breaking things should be of the highest priority. ------------------------------------------------------- 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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
