Re: [Alsa-user] stable APIs and ABIs
On Wed, 25 Jan 2006 18:15:09 +0100 "Hemmann, Volker Armin" <[EMAIL PROTECTED]> wrote: > On Wednesday 25 January 2006 18:11, Sergei Steshenko wrote: > > On Wed, 25 Jan 2006 13:35:05 +0100 > > > > "Hemmann, Volker Armin" <[EMAIL PROTECTED]> wrote: > > > On Wednesday 25 January 2006 05:04, Sergei Steshenko wrote: > > > > > Easy, isn't it? > > > > > > > > Don't you think the same applies to you ? > > > > > > If I'd be the troll, yes. > > > > > > Sadly, the trolls are you and Bill, so it is not on me to stop. > > > > The point/difference is that you think you have the right to call > > people trolls. > > > which I have, when people are so blatantly troll around. > Which you think you have. --- 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
Re: [Alsa-user] stable APIs and ABIs
On Wednesday 25 January 2006 18:11, Sergei Steshenko wrote: > On Wed, 25 Jan 2006 13:35:05 +0100 > > "Hemmann, Volker Armin" <[EMAIL PROTECTED]> wrote: > > On Wednesday 25 January 2006 05:04, Sergei Steshenko wrote: > > > > Easy, isn't it? > > > > > > Don't you think the same applies to you ? > > > > If I'd be the troll, yes. > > > > Sadly, the trolls are you and Bill, so it is not on me to stop. > > The point/difference is that you think you have the right to call > people trolls. which I have, when people are so blatantly troll around. --- 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
Re: [Alsa-user] stable APIs and ABIs
On Wed, 25 Jan 2006 13:35:05 +0100 "Hemmann, Volker Armin" <[EMAIL PROTECTED]> wrote: > On Wednesday 25 January 2006 05:04, Sergei Steshenko wrote: > > > > Easy, isn't it? > > > > Don't you think the same applies to you ? > > If I'd be the troll, yes. > > Sadly, the trolls are you and Bill, so it is not on me to stop. > > The point/difference is that you think you have the right to call people trolls. --- 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
Re: [Alsa-user] stable APIs and ABIs
On Wed, 25 Jan 2006 08:58:42 +0100 "Peter Zubaj" <[EMAIL PROTECTED]> wrote: > >Again, if I remember correctly, Peter Zubaj said that ALSA developers care > >more about themselves and the development process than about end users. I do > >not remember the exact words, but I believe that was the sense. > > > > There was nothing about alsa developpers. > > I wrote this: > > http://article.gmane.org/gmane.linux.alsa.user/20682 > > >Most of people here do this for fun in their free time for free. They do > >this to fit their needs and they care about users only if this doesn't > >cost too much of their time. > > and this > > http://article.gmane.org/gmane.linux.alsa.user/20686 > > >Someone will probably hate me, but for linux (in current state) are > >developers more important than users (this is up to users and > >distribution makers to change this). > > > > > > Aktivujte si neobmedzenu mailovu schranku na www.pobox.sk! > > > > OK, I retract the word "ALSA" :-). --- 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
Re: [Alsa-user] stable APIs and ABIs
On Wednesday 25 January 2006 05:04, Sergei Steshenko wrote: > > Easy, isn't it? > > Don't you think the same applies to you ? If I'd be the troll, yes. Sadly, the trolls are you and Bill, so it is not on me to stop. --- 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
Re: Re: [Alsa-user] stable APIs and ABIs
>Again, if I remember correctly, Peter Zubaj said that ALSA developers care >more about themselves and the development process than about end users. I do >not remember the exact words, but I believe that was the sense. > There was nothing about alsa developpers. I wrote this: http://article.gmane.org/gmane.linux.alsa.user/20682 >Most of people here do this for fun in their free time for free. They do >this to fit their needs and they care about users only if this doesn't >cost too much of their time. and this http://article.gmane.org/gmane.linux.alsa.user/20686 >Someone will probably hate me, but for linux (in current state) are >developers more important than users (this is up to users and >distribution makers to change this). Aktivujte si neobmedzenu mailovu schranku na www.pobox.sk! --- 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&kid3432&bid#0486&dat1642 ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] stable APIs and ABIs
On Wed, 25 Jan 2006 04:48:37 +0100 "Hemmann, Volker Armin" <[EMAIL PROTECTED]> wrote: > On Wednesday 25 January 2006 01:01, Sergei Steshenko wrote: > > On Tue, 24 Jan 2006 18:23:00 -0500 > > > > Lee Revell <[EMAIL PROTECTED]> wrote: > > > On Wed, 2006-01-25 at 01:06 +0200, Sergei Steshenko wrote: > > > > Again, if I remember correctly, Peter Zubaj said that ALSA developers > > > > care > > > > more about themselves and the development process than about end > > > > users. I do > > > > not remember the exact words, but I believe that was the sense. > > > > > > Go away, troll. > > > > > > Lee > > > > Do you think such a post will make Linux more user-friendly ? > > > > maybe not, but you going away will make this list more user friendly. > > I am a user. > > Without your mails, this list is much friendlier. > > So the logival conclusion is, you stop trolling, this list more user friendly. > > Easy, isn't it? > > > Don't you think the same applies to you ? --- 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
Re: [Alsa-user] stable APIs and ABIs
On Wednesday 25 January 2006 01:01, Sergei Steshenko wrote: > On Tue, 24 Jan 2006 18:23:00 -0500 > > Lee Revell <[EMAIL PROTECTED]> wrote: > > On Wed, 2006-01-25 at 01:06 +0200, Sergei Steshenko wrote: > > > Again, if I remember correctly, Peter Zubaj said that ALSA developers > > > care > > > more about themselves and the development process than about end > > > users. I do > > > not remember the exact words, but I believe that was the sense. > > > > Go away, troll. > > > > Lee > > Do you think such a post will make Linux more user-friendly ? > maybe not, but you going away will make this list more user friendly. I am a user. Without your mails, this list is much friendlier. So the logival conclusion is, you stop trolling, this list more user friendly. Easy, isn't it? --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 24 Jan 2006, Bill Unruh wrote:
While this is true, it would seem that a more stable system than is now in
place could surely also be designed. Ie, a driver compiled against one of
the kernels 2.6.x-y would work on any of the others of that series.
I disagree. linux-2.6.0 was released IIRC two years ago. In the meantime
the kernel internals have changed a lot - some times because a subsystem
was redesigned, some times because a new technology (say wireless
networking or DVB TV cards) needed to be supported. So module distributors
would have to supply binary blobs for the different ABI versions even
within the same kernel series. And for drivers that use multiple
subsystems it would come down to one binary for each kernel version...
Put in this mess the fact that many distributors patch their kernels so
you think that you have 2.6.14 while it is more like a 2.6.15 but not
quite a 2.6.15 and you can imagine the confusion this would cause to both
users and developers.
2. There is a HUGE variety of ways a kernel can be compiled:
a. you can use a lot of different compilers: gcc-3.{2,3,4} and ICC are
quite common - and reasonable - options. Since the kernel uses every bit of
the intricacies of the available compiler to maximise performance its
virtually impossible to provide a stable ABI.
b. even in the same processor family you have different CPUs that may
require different calling conventions. For example x86 CPUs can use
registers to pass function arguments, which can lead in a significant
speed-up... the kernel has a Config option for this... the catch ? using it
breaks binary modules, unless they are compiled with the same option -
AFAIK nvidia and linuxant do not distribute such modules. And if you use a
wrapper to fix the calling convention the overhead may become too much in
some cases.
Surely this could be an option for the module writer. Ie, if they really
want max performance, use all of the optimisations. If not, there is a more
stable option. (I guess you might say that is already there-- it is called
a user space driver).
Well, the module writer can do whatever he wants, but the kernel
developers would still have to provide the infrastructure to do so. And in
order to provide a stable ABI with all compiler versions one would have to
forego important optimisations. Function inlining is a good example, since
a function might be a normal symbol under a certain compiler and then
disappear (i.e. become inline) for another compiler.
c. there are people that compile their kernels with different options
(compiler flags, CPU optimisations, debugging, or even things like 4K vs 8K
stacks in x86).
d. And lets not get into the whole multi-platform thing...
Lets not since most sound cards for PCs do not run on Macs anyway.
Actually I am not sure how valid this is for PCI and USB cards... AFAIK
there is no reason the card itself would not function under another CPU
family... apart from driver support of course.
I am all for open source drivers, whatever. But Linuxant for example is
there because the number of volunteers to write drivers for various
wireless cards for linux is simply not there. They do not exist. And
similarly for some of the other closed source drivers. Others are, I agree,
just the manufacturers being bloody minded, but lets not have the
developers and manufacturers enter into a "who can be more bloody minded"
contest.
Volunteers do exist, but the manufacturers refuse to release the device
specs. I think that releasing programming information for a device would
be the best for a manufacturer. They do not have to develop a driver
themselves, and their device will be eventually supported on every
OS/platform with enough motivated developers.
Personally I'm all for open source drivers and the
each-module-for-its-kernel principle. It works and it does not hog down the
development process with
Well, the question being raised is "does it work?". It comes at a cost, a
cost of Linux simply not supporting numerous devices (despite the valiant
efforts of many people) and of manufacturers refusing to support Linux.
I do not really think that a stable ABI would change this. The nvidia-like
solution (however controversial) solves the technical problems, without
requiring a stable ABI, and I severely doubt that a stable ABI would
require any less work from the manufacturer. It would only result to a
driver-less device in the long run when the old ABI is dropped.
maintaining obsolete code. Vendors can either provide open soure drivers,
work from userspace, or attempt to provide support the way they do now...
End
Or not support Linux at all.
To be honest, I don't see how having a stable ABI would help vendors
develop a new driver. It might ease its _maintenance_ a bit, but I don't
think that the overhead of the rather rare API changes is that big.
I think that the reasons Linux is not supported by most vendors are mor
Re: [Alsa-user] stable APIs and ABIs
On Tue, 24 Jan 2006 18:23:00 -0500 Lee Revell <[EMAIL PROTECTED]> wrote: > On Wed, 2006-01-25 at 01:06 +0200, Sergei Steshenko wrote: > > Again, if I remember correctly, Peter Zubaj said that ALSA developers > > care > > more about themselves and the development process than about end > > users. I do > > not remember the exact words, but I believe that was the sense. > > Go away, troll. > > Lee > Do you think such a post will make Linux more user-friendly ? --- 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
Re: [Alsa-user] stable APIs and ABIs
On Wed, 25 Jan 2006, Theodoros V. Kalamatianos wrote:
On Tue, 24 Jan 2006, Bill Unruh wrote:
I simply do not have the technical knowledge to know if this is the problem
or if there are other technical problems with making modules "stable".
Certainly something about the interfaces is "stable". Alsa 1.0.x can be
compiled against kernel 2.6.y, or even 2.4.y and work. Ie, all the entry
points etc do not need changing. From that point of view the interface is
stable. But for some reason that module still needs to be compiled against
that kernel for it to work. Why? Is there a technical problem or is it a
lack of will ( as you suspect) or is it malice ( as the quote from
developers regarding their antipathy to non-sourcecode modules would seem
to indicate).
I think there quite a few reasons why a stable ABI is not desired:
1. You have to carry along old interfaces and live with bad design decisions.
This means that:
a. Lots of people spend time in maintaining the compatibility stuff instead
of writing new code and fixing bugs. Plus the code size increases and the
code paths where bugs can be found multiply.
Oh and lets not forget: To introduce a new design (say the Nth) for a
subsystem you'd still have to to modify the wrappers that provide the 1..N-2
versions of its ABI _and_ create a new wrapper for the N-1 ABI... Don't you
think this would be too much ? And keep in mind that something as simple as
adding a new element in a C struct results in an ABI change.
When the developers strive to reduce code duplication, it sounds stupid to me
to have multiple routines that do the same more or less job, just to keep a
stable ABI.
b. it is much more difficult to shake off known bad practices, since many
people won't fix their code unless it stops working.
c. a lot of drivers will communicate with each other via wrappers, unless
someone fixes them. Can you imagine the following:
Driver A -> old_function_ver_1 (wrapper) -> new_function ->
old_function_ver_2 -> driver B ?
and since sometimes the change in an interface may be much more than just a
function prototype this can lead in significant performance loss.
While this is true, it would seem that a more stable system than is now in
place could surely also be designed. Ie, a driver compiled against one of
the kernels 2.6.x-y would work on any of the others of that series.
2. There is a HUGE variety of ways a kernel can be compiled:
a. you can use a lot of different compilers: gcc-3.{2,3,4} and ICC are quite
common - and reasonable - options. Since the kernel uses every bit of the
intricacies of the available compiler to maximise performance its virtually
impossible to provide a stable ABI.
b. even in the same processor family you have different CPUs that may require
different calling conventions. For example x86 CPUs can use registers to pass
function arguments, which can lead in a significant speed-up... the kernel
has a Config option for this... the catch ? using it breaks binary modules,
unless they are compiled with the same option - AFAIK nvidia and linuxant do
not distribute such modules. And if you use a wrapper to fix the calling
convention the overhead may become too much in some cases.
Surely this could be an option for the module writer. Ie, if they really
want max performance, use all of the optimisations. If not, there is a more
stable option. (I guess you might say that is already there-- it is called
a user space driver).
c. there are people that compile their kernels with different options
(compiler flags, CPU optimisations, debugging, or even things like 4K vs 8K
stacks in x86).
d. And lets not get into the whole multi-platform thing...
Lets not since most sound cards for PCs do not run on Macs anyway.
To provide a stable ABI you would finally get something similar to the
current VERMAGIC stuff... which is probably not what you want, since you
still have to distribute multiple compilations of the same module. Or you
would have to live with significantly reduced performance for the next X
years just because you are unable to make the best of the new compilers and
CPU features.
3. Having an official stable ABI would encourage people to keep closed source
drivers - even for trivial reasons. This means that a device would only be
usable on the platforms an configurations the vendor supports. And it would
also mean that when the device reaches its end of product life you might not
be able to support it for a new kernel series - unless of course you decided
to keep the old ABI even for the new series... not even M$ does that...
I am all for open source drivers, whatever. But Linuxant for example is
there because the number of volunteers to write drivers for various
wireless cards for linux is simply not there. They do not exist. And
similarly for some of the other closed source drivers. Others are, I agree,
just the manufacturers being bloody minded, but lets not have the
d
Re: [Alsa-user] stable APIs and ABIs
On Tue, 2006-01-24 at 14:51 -0800, Bill Unruh wrote: > On Tue, 24 Jan 2006, Lee Revell wrote: > > > On Tue, 2006-01-24 at 14:13 -0800, Bill Unruh wrote: > >> AAgrhaheh. The claim from you was that it is easy for a user to update > >> the drivers for a new kernel, or install new drivers which had been > >> developed to a new kernel. Just three lines-- untar, configure and > >> make. I point out that it is NOT that easy. It is that easy only if > >> the user's system has been set up as a development environment. > > > > If you get a new soundcard and your current system does not support it > > there's a simple fix for non-developers: > > > > apt-get update && apt-get dist-upgrade > > Funny, my distributions (mandrake 10.1 and Mandriva 2006) have no such > commands. So basically what all of you are complaining about is that there is no easy way to upgrade drivers without changing kernels, rebooting, etc. You're right -- that's really annoying to some people, esp to end users who couldn't care less about compiling stuff, etc. It is also not a kernel problem however, but a distribution one. (The real problem arises from users who THINK they know what they're doing but don't, screw something up or can't figure it out, assume the kernel is to blame, and go spamming lists about how their kernels are broken.) It is up to the distribution to provide a way for you to upgrade these (and in turn make binaries, etc). This, in turn, requires the distribution to compile these and set them up against any random kernel they run, which requires the "real" drivers to be compileable against the kernel that you, as the user are running. As such, either the source must be available (and backported; alternatively a whole new kernel could be provided, requiring a simple reboot, which is something that most of the users you mention would not shirk away from), or the driver provider must have made a binary for that distribution's kernel setup. The latter is a bit unreasonable due to the sheer variety of kernels out there requiring different modules (see modversions for more info about the things that require a recompile of the modules). Thus you are left with the former, leaving it up to the distribution to package the stuff. But what of the hardware provider, you may ask, who doesn't want to wait the years it takes for a driver to be incorporated into a kernel? Well, as it turns out, different distros have different policies when it comes to support of such out-of-tree drivers. Some embrace them (e.g. Ubuntu, Debian/unstable(?), Gentoo (via numerous ebuilds), etc) while others don't. Once again, not a main-line kernel problem. Or, if the hardware provider wanted to avoid this problem, they could merge their device drivers *BEFORE* the hardware was on the market. Wouldn't that be a novel idea. And as a sidenote on the ABI stability issues, here's something to think about: I was recently doing a bit of porting to Windows. Turns out, they have THREE calling conventions commonly used -- pascal, standard, and fastcall (not sure about that last one). Talk about carrying old cruft around for the sake of ABI compatibility. And regarding a more recent e-mail about linux demanding stuff: A number of years ago, Adaptec gave very good support to linux. Their drivers worked, and were updated promptly. And guess what -- any linux server with SCSI had an Adaptec board in it. (late 90's - 01 or so) The better the support that you as a manufacturer provide, the better the market for it. Creative also realized this a while back and released a bunch of specs on the EMU10K1 proc along with a driver, iirc, and that quickly became the most popular board amongst linux users for sound. (not sure what they're up to now, I'm sure people on this list have more insight into it than I do.) And a side-note about binary drivers: (a) The LK developers have enough to worry about without having to support users with weird binary driver problems. The binary module could do bad things behind the kernel's back and there'd be no way to trace it. (b) Count the amount of hardware that is now useable on another platform, e.g. PPC or Alpha, that wasn't otherwise due to lack of driver support. With an open-source driver for one platform, it was trivial to make it work on both platforms. Basically, the LK people have lost faith in the manufacturers' ability to provide drivers, and want to focus all of their efforts on developing open drivers that they can maintain themselves. Part of this focusing involves making it worthwhile to the manufacturer to release the information (e.g. by making it unacceptable to maintain an out-of-tree or binary driver). Anyways, that's pretty much all I have to say on the issue -- sorry for spamming everyone with this hashed out stuff, but I guess I'm under the (most likely false) impression that the people maintaining this thread are not just trolling. Again, apologies for the spam. -
Re: [Alsa-user] stable APIs and ABIs
On Wed, 2006-01-25 at 01:06 +0200, Sergei Steshenko wrote: > Again, if I remember correctly, Peter Zubaj said that ALSA developers > care > more about themselves and the development process than about end > users. I do > not remember the exact words, but I believe that was the sense. Go away, troll. Lee --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 24 Jan 2006 15:00:06 -0800 (PST) Bill Unruh <[EMAIL PROTECTED]> wrote: > On Tue, 24 Jan 2006, Lee Revell wrote: > > > On Tue, 2006-01-24 at 14:51 -0800, Bill Unruh wrote: > >> On Tue, 24 Jan 2006, Lee Revell wrote: > >> > >>> On Tue, 2006-01-24 at 14:13 -0800, Bill Unruh wrote: > AAgrhaheh. The claim from you was that it is easy for a user to update > the drivers for a new kernel, or install new drivers which had been > developed to a new kernel. Just three lines-- untar, configure and > make. I point out that it is NOT that easy. It is that easy only if > the user's system has been set up as a development environment. > >>> > >>> If you get a new soundcard and your current system does not support it > >>> there's a simple fix for non-developers: > >>> > >>> apt-get update && apt-get dist-upgrade > >> > >> Funny, my distributions (mandrake 10.1 and Mandriva 2006) have no such > >> commands. > >> > > > > Um, you get my point, every distro has a package manager with a command > > that says "update packages to the latest version". > > Mandrake is still running 1.0.8 Alsa on their latest kernel in 2006 ( and > is at alsa 1.0.3 on the latest kernel on 10.1 and previous distros have no > updates at all anymore.) Debian on their latest stable is I belive still on > the 2.4.x kernels. Yeah. Manufacturers should rely on distributions to get > out their drivers. > > No, it's 1.0.9 : " alsamixer -v alsamixer: invalid option -- v AlsaMixer v1.0.9 ". --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 24 Jan 2006 14:51:44 -0800 (PST) Bill Unruh <[EMAIL PROTECTED]> wrote: > On Tue, 24 Jan 2006, Lee Revell wrote: > > > On Tue, 2006-01-24 at 14:13 -0800, Bill Unruh wrote: > >> AAgrhaheh. The claim from you was that it is easy for a user to update > >> the drivers for a new kernel, or install new drivers which had been > >> developed to a new kernel. Just three lines-- untar, configure and > >> make. I point out that it is NOT that easy. It is that easy only if > >> the user's system has been set up as a development environment. > > > > If you get a new soundcard and your current system does not support it > > there's a simple fix for non-developers: > > > > apt-get update && apt-get dist-upgrade > > Funny, my distributions (mandrake 10.1 and Mandriva 2006) have no such > commands. > You know, I confirm. --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 24 Jan 2006 14:13:35 -0800 (PST) Bill Unruh <[EMAIL PROTECTED]> wrote: > On Tue, 24 Jan 2006, Lee Revell wrote: > > > On Tue, 2006-01-24 at 09:37 -0800, Bill Unruh wrote: > >> It might be, but it in general is not. It is not possible for the > >> average > >> user to just recompile. He almost certainly did not install the > >> development > >> stuff when he installed Linux. He probably did not install the kernel > >> source when he installed linux. So, before he can do "make" he has to > >> install a HUGE list of development programs and libraries and he has > >> to > >> find the kernel source and config files for his particular version of > >> Linux. In the process he has to resolve a bunch of dependencies, by > >> which > >> time he is screaming. Then he can finally do the make, and the make > >> install. > > > > Why in the hell are all these end users having to compile the kernel to > > get their sound working? 99.99% of users should never have to compile > > anything. Sounds like the distros are doing a piss poor job, or else > > people insist on buying bleeding edge hardware that hasn't been on the > > market long enough for us to write a working driver. > > AAgrhaheh. The claim from you was that it is easy for a user to update the > drivers for a new kernel, or install new drivers which had been developed > to a new kernel. Just three lines-- untar, configure and make. I point out > that it is NOT that easy. It is that easy only if the user's system has > been set up as a development environment. The whole premise was "the user > has a new kernel or the user has a new driver for his new soundcard. Why > cannot the user not simply find a precompiled version for all 2.6.x kernels > and install it, instead of having to have a version for every single > possible version of the kernel, or instead of having to compile it > himself." This discussion also began from the difficulties that sound card > manufacturers have in supporting Linux. They cannot simply include a binary > driver module which the user can install on his system. This is true whether > they > include source code or not. > > This is an impediment to manufacturer's supporting Linux. If the > manufacturer has to include 700 versions of his drivers and tell the user > exactly how to determine the version of the user's kernel and figure out > which of the 700 versions to install, or tell the user how to set up a > developement environment on his system, download the kernel source for his > particular kernel and then compile and install it ( which as you said is > the easy part), it is going to impede the best will in the world of the > manufacturer to support Linux. > > Bad support such as -- Here is the source code. Go off and figure out how to > install this on your kernel.-- is far worse than no support at all as far > as most manufacturers are concerned. > > Ie, this is a problem not just for manufacturers who do not want to include > driver source code for whatever reason. It is one for manufacturers who > behave like good Linux citizens as well. > > And "Do not buy that new sound card-- wait a year or two or three until the > distribution you like gets around to including that card in their > distribution" does not seem like an adequate response. > > > Now, if there is a technical reason why it is very difficult to set up the > module system so as to enable one binary to run on all say 2.6.x kernels, > that is one thing. If it is bloody mindedness on the developer's part ( > that would make it too easy for manufacturers to develop binary only > drivers) it is another issue. I would like to know which it is. > > Regarding "If it is bloody mindedness on the developer's part" - I believe it is EXACTLY what it is. I'm saying this because I read the kernel developers' document justifying absence of stable ABI and IMO the arguments used by kernel developers were wrong. I even proposed a binary interface for ALSA. It was a very a rough draft, more of a concept, but, if I remember correctly, nobody said it was impossible to implement. Again, if I remember correctly, Peter Zubaj said that ALSA developers care more about themselves and the development process than about end users. I do not remember the exact words, but I believe that was the sense. I agree with "This is an impediment to manufacturer's supporting Linux". I think that Linux development community should understand it is not in the position to demand anything from manufacturers. Linux's best chance to be adopted is to work out a stable solution acceptable to manufacturers, and only then, as someone has already said, after gaining 5-10% market share, it will be reasonable to try to convince the manufacturers to release the specs in order to facilitate OSS drivers development. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX
Re: [Alsa-user] stable APIs and ABIs
On Tue, 24 Jan 2006, Bill Unruh wrote:
I simply do not have the technical knowledge to know if this is the problem
or if there are other technical problems with making modules "stable".
Certainly something about the interfaces is "stable". Alsa 1.0.x can be
compiled against kernel 2.6.y, or even 2.4.y and work. Ie, all the entry
points etc do not need changing. From that point of view the interface is
stable. But for some reason that module still needs to be compiled against
that kernel for it to work. Why? Is there a technical problem or is it a
lack of will ( as you suspect) or is it malice ( as the quote from
developers regarding their antipathy to non-sourcecode modules would seem
to indicate).
I think there quite a few reasons why a stable ABI is not desired:
1. You have to carry along old interfaces and live with bad design
decisions. This means that:
a. Lots of people spend time in maintaining the compatibility stuff
instead of writing new code and fixing bugs. Plus the code size increases
and the code paths where bugs can be found multiply.
Oh and lets not forget: To introduce a new design (say the Nth) for a
subsystem you'd still have to to modify the wrappers that provide the
1..N-2 versions of its ABI _and_ create a new wrapper for the N-1 ABI...
Don't you think this would be too much ? And keep in mind that something
as simple as adding a new element in a C struct results in an ABI change.
When the developers strive to reduce code duplication, it sounds stupid to
me to have multiple routines that do the same more or less job, just to
keep a stable ABI.
b. it is much more difficult to shake off known bad practices, since
many people won't fix their code unless it stops working.
c. a lot of drivers will communicate with each other via wrappers, unless
someone fixes them. Can you imagine the following:
Driver A -> old_function_ver_1 (wrapper) -> new_function ->
old_function_ver_2 -> driver B ?
and since sometimes the change in an interface may be much more than just
a function prototype this can lead in significant performance loss.
2. There is a HUGE variety of ways a kernel can be compiled:
a. you can use a lot of different compilers: gcc-3.{2,3,4} and ICC are
quite common - and reasonable - options. Since the kernel uses every bit
of the intricacies of the available compiler to maximise performance its
virtually impossible to provide a stable ABI.
b. even in the same processor family you have different CPUs that may
require different calling conventions. For example x86 CPUs can use
registers to pass function arguments, which can lead in a significant
speed-up... the kernel has a Config option for this... the catch ? using
it breaks binary modules, unless they are compiled with the same option -
AFAIK nvidia and linuxant do not distribute such modules. And if you use a
wrapper to fix the calling convention the overhead may become too much in
some cases.
c. there are people that compile their kernels with different options
(compiler flags, CPU optimisations, debugging, or even things like 4K vs
8K stacks in x86).
d. And lets not get into the whole multi-platform thing...
To provide a stable ABI you would finally get something similar to the
current VERMAGIC stuff... which is probably not what you want, since you
still have to distribute multiple compilations of the same module. Or you
would have to live with significantly reduced performance for the next X
years just because you are unable to make the best of the new compilers
and CPU features.
3. Having an official stable ABI would encourage people to keep closed
source drivers - even for trivial reasons. This means that a device would
only be usable on the platforms an configurations the vendor supports. And
it would also mean that when the device reaches its end of product life
you might not be able to support it for a new kernel series - unless of
course you decided to keep the old ABI even for the new series... not even
M$ does that...
Personally I'm all for open source drivers and the
each-module-for-its-kernel principle. It works and it does not hog down
the development process with maintaining obsolete code. Vendors can either
provide open soure drivers, work from userspace, or attempt to provide
support the way they do now... End users who do not know how to compile a
kernel can either ask their distributors to add the missing drivers, or
learn how to compile a kernel :-)
---
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/listin
Re: [Alsa-user] stable APIs and ABIs
On Tue, 24 Jan 2006, Lee Revell wrote: On Tue, 2006-01-24 at 14:51 -0800, Bill Unruh wrote: On Tue, 24 Jan 2006, Lee Revell wrote: On Tue, 2006-01-24 at 14:13 -0800, Bill Unruh wrote: AAgrhaheh. The claim from you was that it is easy for a user to update the drivers for a new kernel, or install new drivers which had been developed to a new kernel. Just three lines-- untar, configure and make. I point out that it is NOT that easy. It is that easy only if the user's system has been set up as a development environment. If you get a new soundcard and your current system does not support it there's a simple fix for non-developers: apt-get update && apt-get dist-upgrade Funny, my distributions (mandrake 10.1 and Mandriva 2006) have no such commands. Um, you get my point, every distro has a package manager with a command that says "update packages to the latest version". Mandrake is still running 1.0.8 Alsa on their latest kernel in 2006 ( and is at alsa 1.0.3 on the latest kernel on 10.1 and previous distros have no updates at all anymore.) Debian on their latest stable is I belive still on the 2.4.x kernels. Yeah. Manufacturers should rely on distributions to get out their drivers. --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 24 Jan 2006, Lee Revell wrote: On Tue, 2006-01-24 at 14:13 -0800, Bill Unruh wrote: This discussion also began from the difficulties that sound card manufacturers have in supporting Linux. They cannot simply include a binary driver module which the user can install on his system. This is true whether they include source code or not. This is an impediment to manufacturer's supporting Linux. No, it's not - all they have to do is submit the driver to the kernel developers in an acceptable state, and they don't have to worry about further support. Are you really so out of touch or is this just a persona you have assumed for this discussion? Once it is submitted to the kernel developers (well, the alsa developers since we are talking about sound cards) it takes a while to actually come out in a release kernel. Then it takes a while (>1 year) for that kernel to be incorportated into a distribution (in the case of Debian more like a decade). And then many users still continue to use old distributions. The manufacturer is supposed to sit back and think this is OK. Sheesh. --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 2006-01-24 at 14:51 -0800, Bill Unruh wrote: > On Tue, 24 Jan 2006, Lee Revell wrote: > > > On Tue, 2006-01-24 at 14:13 -0800, Bill Unruh wrote: > >> AAgrhaheh. The claim from you was that it is easy for a user to update > >> the drivers for a new kernel, or install new drivers which had been > >> developed to a new kernel. Just three lines-- untar, configure and > >> make. I point out that it is NOT that easy. It is that easy only if > >> the user's system has been set up as a development environment. > > > > If you get a new soundcard and your current system does not support it > > there's a simple fix for non-developers: > > > > apt-get update && apt-get dist-upgrade > > Funny, my distributions (mandrake 10.1 and Mandriva 2006) have no such > commands. > Um, you get my point, every distro has a package manager with a command that says "update packages to the latest version". Lee --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 24 Jan 2006, Lee Revell wrote: On Tue, 2006-01-24 at 14:13 -0800, Bill Unruh wrote: AAgrhaheh. The claim from you was that it is easy for a user to update the drivers for a new kernel, or install new drivers which had been developed to a new kernel. Just three lines-- untar, configure and make. I point out that it is NOT that easy. It is that easy only if the user's system has been set up as a development environment. If you get a new soundcard and your current system does not support it there's a simple fix for non-developers: apt-get update && apt-get dist-upgrade Funny, my distributions (mandrake 10.1 and Mandriva 2006) have no such commands. --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tuesday 24 January 2006 12:15, Sergei Steshenko wrote: > > -- > > Giuliano. > > Look, "the device" a piece of metal, with electric motor(s) and a piece > of plastic (the device PCB) on which the controller, which is also kind > of CPU for the device, is installed. > > "The CPU" is also a CPU, which is installed onto a piece of plastic > (the motherboard PCB); typically CPU works with an electric motor - its > cooling fan. Or, by the way, the heatsink, and the computer case as a > whole, are also pieces of metal. and the firmware runs on the cpu of the device, while the kernel (and kernel drivers) run on the CPU of the computer. IUt is sad, that you don't see the fundamental difference. --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tuesday 24 January 2006 11:54, James Courtier-Dutton wrote: > Sergei Steshenko wrote: > > We have already discussed this, here's yet another opinion: > > > > http://ask.slashdot.org/article.pl?sid=06/01/23/214258 -> > > > > " > > This is why we need a kernel api and abi > > (Score:2) > > by Billly Gates (198444) Alter Relationship on Tuesday January 24, > > @02:03AM (#14544582) (http://www.livejournal.com/users/sinistertim101 | > > Last Journal: Thursday December 22, @08:27PM) Flamebait all you want from > > the moderators reading this belonging to the pure gnu persusian but > > writing closed source drivers are tough for linux. > > This has ZERO to do with ALSA, so why did you post it here? > because he is a f*ing troll. The other thread showed it clearly. --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 2006-01-24 at 14:13 -0800, Bill Unruh wrote: > This discussion also began from the difficulties that sound card > manufacturers have in supporting Linux. They cannot simply include a > binary > driver module which the user can install on his system. This is true > whether they > include source code or not. > > This is an impediment to manufacturer's supporting Linux. No, it's not - all they have to do is submit the driver to the kernel developers in an acceptable state, and they don't have to worry about further support. Lee --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 2006-01-24 at 14:13 -0800, Bill Unruh wrote: > AAgrhaheh. The claim from you was that it is easy for a user to update > the drivers for a new kernel, or install new drivers which had been > developed to a new kernel. Just three lines-- untar, configure and > make. I point out that it is NOT that easy. It is that easy only if > the user's system has been set up as a development environment. If you get a new soundcard and your current system does not support it there's a simple fix for non-developers: apt-get update && apt-get dist-upgrade Lee --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 24 Jan 2006, Lee Revell wrote: On Tue, 2006-01-24 at 09:37 -0800, Bill Unruh wrote: It might be, but it in general is not. It is not possible for the average user to just recompile. He almost certainly did not install the development stuff when he installed Linux. He probably did not install the kernel source when he installed linux. So, before he can do "make" he has to install a HUGE list of development programs and libraries and he has to find the kernel source and config files for his particular version of Linux. In the process he has to resolve a bunch of dependencies, by which time he is screaming. Then he can finally do the make, and the make install. Why in the hell are all these end users having to compile the kernel to get their sound working? 99.99% of users should never have to compile anything. Sounds like the distros are doing a piss poor job, or else people insist on buying bleeding edge hardware that hasn't been on the market long enough for us to write a working driver. AAgrhaheh. The claim from you was that it is easy for a user to update the drivers for a new kernel, or install new drivers which had been developed to a new kernel. Just three lines-- untar, configure and make. I point out that it is NOT that easy. It is that easy only if the user's system has been set up as a development environment. The whole premise was "the user has a new kernel or the user has a new driver for his new soundcard. Why cannot the user not simply find a precompiled version for all 2.6.x kernels and install it, instead of having to have a version for every single possible version of the kernel, or instead of having to compile it himself." This discussion also began from the difficulties that sound card manufacturers have in supporting Linux. They cannot simply include a binary driver module which the user can install on his system. This is true whether they include source code or not. This is an impediment to manufacturer's supporting Linux. If the manufacturer has to include 700 versions of his drivers and tell the user exactly how to determine the version of the user's kernel and figure out which of the 700 versions to install, or tell the user how to set up a developement environment on his system, download the kernel source for his particular kernel and then compile and install it ( which as you said is the easy part), it is going to impede the best will in the world of the manufacturer to support Linux. Bad support such as -- Here is the source code. Go off and figure out how to install this on your kernel.-- is far worse than no support at all as far as most manufacturers are concerned. Ie, this is a problem not just for manufacturers who do not want to include driver source code for whatever reason. It is one for manufacturers who behave like good Linux citizens as well. And "Do not buy that new sound card-- wait a year or two or three until the distribution you like gets around to including that card in their distribution" does not seem like an adequate response. Now, if there is a technical reason why it is very difficult to set up the module system so as to enable one binary to run on all say 2.6.x kernels, that is one thing. If it is bloody mindedness on the developer's part ( that would make it too easy for manufacturers to develop binary only drivers) it is another issue. I would like to know which it is. --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 2006-01-24 at 09:37 -0800, Bill Unruh wrote: > It might be, but it in general is not. It is not possible for the > average > user to just recompile. He almost certainly did not install the > development > stuff when he installed Linux. He probably did not install the kernel > source when he installed linux. So, before he can do "make" he has to > install a HUGE list of development programs and libraries and he has > to > find the kernel source and config files for his particular version of > Linux. In the process he has to resolve a bunch of dependencies, by > which > time he is screaming. Then he can finally do the make, and the make > install. Why in the hell are all these end users having to compile the kernel to get their sound working? 99.99% of users should never have to compile anything. Sounds like the distros are doing a piss poor job, or else people insist on buying bleeding edge hardware that hasn't been on the market long enough for us to write a working driver. Lee --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tuesday 24 January 2006 12:49, Sergei Steshenko wrote: >On Tue, 24 Jan 2006 09:37:10 -0800 (PST) > >Bill Unruh <[EMAIL PROTECTED]> wrote: >> On Tue, 24 Jan 2006, Sergei Steshenko wrote: >> > On Tue, 24 Jan 2006 12:39:06 + >> > >> > James Courtier-Dutton <[EMAIL PROTECTED]> wrote: >> >> What we have with Linux is better than what you want. >> >> You install the Linux kernel, and you have support for all sound >> >> cards already there. No need to go searching the net for some >> >> driver like one has to do in Windows. >> >> If it is not already in the Linux kernel, your sound card is >> >> unlikely to work in Linux at all. >> >> If you want support or a bug fix for some particular sound card, >> >> you then have to either wait for your distro to support it. >> >> (similar to waiting for the manufacture's web site to be updated >> >> with a new driver), or alternatively, compile the kernel and alsa >> >> from sources, and get the very latest bug fixes and features. >> >> >> >> If you think about it, the Linux way is actually a lot better >> >> than the method you are describing. >> >> It might be, but it in general is not. It is not possible for the >> average user to just recompile. He almost certainly did not install >> the development stuff when he installed Linux. He probably did not >> install the kernel source when he installed linux. So, before he can >> do "make" he has to install a HUGE list of development programs and >> libraries and he has to find the kernel source and config files for >> his particular version of Linux. In the process he has to resolve a >> bunch of dependencies, by which time he is screaming. Then he can >> finally do the make, and the make install. >> >> Even on my system, I was going to install the 1.0.10 alsa, and ran >> make, only to notice that the only source I had installed was the >> 2.6.8.1 when I had months ago replaced the running kernel with >> 2.6.11, without the source. Also, sometimes I switch between >> kernels. And suddenly I have to recompile for both kernels. This is >> both a pain and is something that would drive the naive user around >> the bend. These things are easy for those of us who have done it a >> lot, and have gotten over the fear that anything we do could destroy >> the system (in part because we have the confidence that if it were >> destroyed, we could fix it). >> >> So, What is the problem with making the module--kernel interface so >> that a driver compiled for 2.6.x would run without recompilation on >> 2.6.y? Is it a philosophical position, that the linux developers >> want to ensure that this does not get done, as the quote seems to >> indicate? Or is there some deep technical reason why this is >> difficult/impossible to do? This is not an issue of closed >> source/open source. I am asking a technical question about the >> design of the module-kernel interface. >> >> > Basically, end user should not be forced to compile a driver. >> > Any honest developer should release his/her code only after sanity >> > checks, the first of them being compileability. So, after that >> > first sanity check the compiled driver already exists. > >Thanks for having the courage not to shut up. > >IMHO you are absolutely right about the philosophical position - it is > just it, the lack of desire to introduce stability through first > defining interfaces and then sticking to them. > >And, risking to attract even more awe - the side effect of the > "bazaar" part of development model. > >Regarding dependencies - you are again right. Even simpler than kernel > things require a lot of dependencies to be resolved - I am doing some > development, so I know it. > Such an attitude regarding the kernel is counter-productive in terms of the progress because it, if you want a really stable interface, means broken stuff has to be carried forward into the very hazy future. Never to be fixed because half the apps on the box will fall over if they do. IMO the developers are 100% correct when they tell you that unless it is indeed a kernel module, then and only then is it have access to the defines, and then only to the src tree of the currently running kernel by well defined linkages. If the currently running kernel was an rpm/dpkg/whathaveyou install, precompiled, then those defines will not be available because the kernel's src tree isn't there. Such an error when you try to build your output, should only tell you to go to the system defines and grep for the one(s) you missed or miss-used. When they tell you to use system defines, they are telling you to use the "stable as long as its running this version of clib, with this version of the compiler" headers. These are much more stable than the kernel is ever going to be. If, in building something in userspace intended to be an application, and the writer uses the kernel headers just because they're there, then don't blame the kernel people for your stupidity when the next kernel breaks your
Re: [Alsa-user] stable APIs and ABIs
On Tue, 24 Jan 2006, Sergei Steshenko wrote: On Tue, 24 Jan 2006 09:37:10 -0800 (PST) Bill Unruh <[EMAIL PROTECTED]> wrote: On Tue, 24 Jan 2006, Sergei Steshenko wrote: On Tue, 24 Jan 2006 12:39:06 + James Courtier-Dutton <[EMAIL PROTECTED]> wrote: What we have with Linux is better than what you want. You install the Linux kernel, and you have support for all sound cards already there. No need to go searching the net for some driver like one has to do in Windows. If it is not already in the Linux kernel, your sound card is unlikely to work in Linux at all. If you want support or a bug fix for some particular sound card, you then have to either wait for your distro to support it. (similar to waiting for the manufacture's web site to be updated with a new driver), or alternatively, compile the kernel and alsa from sources, and get the very latest bug fixes and features. If you think about it, the Linux way is actually a lot better than the method you are describing. It might be, but it in general is not. It is not possible for the average user to just recompile. He almost certainly did not install the development stuff when he installed Linux. He probably did not install the kernel source when he installed linux. So, before he can do "make" he has to install a HUGE list of development programs and libraries and he has to find the kernel source and config files for his particular version of Linux. In the process he has to resolve a bunch of dependencies, by which time he is screaming. Then he can finally do the make, and the make install. Even on my system, I was going to install the 1.0.10 alsa, and ran make, only to notice that the only source I had installed was the 2.6.8.1 when I had months ago replaced the running kernel with 2.6.11, without the source. Also, sometimes I switch between kernels. And suddenly I have to recompile for both kernels. This is both a pain and is something that would drive the naive user around the bend. These things are easy for those of us who have done it a lot, and have gotten over the fear that anything we do could destroy the system (in part because we have the confidence that if it were destroyed, we could fix it). So, What is the problem with making the module--kernel interface so that a driver compiled for 2.6.x would run without recompilation on 2.6.y? Is it a philosophical position, that the linux developers want to ensure that this does not get done, as the quote seems to indicate? Or is there some deep technical reason why this is difficult/impossible to do? This is not an issue of closed source/open source. I am asking a technical question about the design of the module-kernel interface. Basically, end user should not be forced to compile a driver. Any honest developer should release his/her code only after sanity checks, the first of them being compileability. So, after that first sanity check the compiled driver already exists. Thanks for having the courage not to shut up. IMHO you are absolutely right about the philosophical position - it is just it, the lack of desire to introduce stability through first defining interfaces and then sticking to them. I simply do not have the technical knowledge to know if this is the problem or if there are other technical problems with making modules "stable". Certainly something about the interfaces is "stable". Alsa 1.0.x can be compiled against kernel 2.6.y, or even 2.4.y and work. Ie, all the entry points etc do not need changing. From that point of view the interface is stable. But for some reason that module still needs to be compiled against that kernel for it to work. Why? Is there a technical problem or is it a lack of will ( as you suspect) or is it malice ( as the quote from developers regarding their antipathy to non-sourcecode modules would seem to indicate). And, risking to attract even more awe - the side effect of the "bazaar" part of development model. No I do not believe that this is it. That they have been able to set things up so that the kernel, written by hundreds of different people, can work together as well as it does indicates a huge degree of discipline and planning. I do not believe it is simply the result of the chaos of many workers. --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 24 Jan 2006 09:37:10 -0800 (PST) Bill Unruh <[EMAIL PROTECTED]> wrote: > On Tue, 24 Jan 2006, Sergei Steshenko wrote: > > > On Tue, 24 Jan 2006 12:39:06 + > > James Courtier-Dutton <[EMAIL PROTECTED]> wrote: > > > >> > >> What we have with Linux is better than what you want. > >> You install the Linux kernel, and you have support for all sound cards > >> already there. No need to go searching the net for some driver like one > >> has to do in Windows. > >> If it is not already in the Linux kernel, your sound card is unlikely to > >> work in Linux at all. > >> If you want support or a bug fix for some particular sound card, you > >> then have to either wait for your distro to support it. (similar to > >> waiting for the manufacture's web site to be updated with a new driver), > >> or alternatively, compile the kernel and alsa from sources, and get the > >> very latest bug fixes and features. > >> > >> If you think about it, the Linux way is actually a lot better than the > >> method you are describing. > > It might be, but it in general is not. It is not possible for the average > user to just recompile. He almost certainly did not install the development > stuff when he installed Linux. He probably did not install the kernel > source when he installed linux. So, before he can do "make" he has to > install a HUGE list of development programs and libraries and he has to > find the kernel source and config files for his particular version of > Linux. In the process he has to resolve a bunch of dependencies, by which > time he is screaming. Then he can finally do the make, and the make > install. > > Even on my system, I was going to install the 1.0.10 alsa, and ran make, > only to notice that the only source I had installed was the 2.6.8.1 when I > had months ago replaced the running kernel with 2.6.11, without the source. > Also, sometimes I switch between kernels. And suddenly I have to recompile > for both kernels. This is both a pain and is something that would drive the > naive user around the bend. These things are easy for those of us who have > done it a lot, and have gotten over the fear that anything we do could > destroy the system (in part because we have the confidence that if it were > destroyed, we could fix it). > > So, What is the problem with making the module--kernel interface so that a > driver compiled for 2.6.x would run without recompilation on 2.6.y? Is it a > philosophical position, that the linux developers want to ensure that this > does not get done, as the quote seems to indicate? Or is there some deep > technical reason why this is difficult/impossible to do? This is not an > issue of closed source/open source. I am asking a technical question about > the design of the module-kernel interface. > > > > Basically, end user should not be forced to compile a driver. > > Any honest developer should release his/her code only after sanity checks, > > the first of them being compileability. So, after that first sanity check > > the > > compiled driver already exists. > > Thanks for having the courage not to shut up. IMHO you are absolutely right about the philosophical position - it is just it, the lack of desire to introduce stability through first defining interfaces and then sticking to them. And, risking to attract even more awe - the side effect of the "bazaar" part of development model. Regarding dependencies - you are again right. Even simpler than kernel things require a lot of dependencies to be resolved - I am doing some development, so I know it. --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 24 Jan 2006, Sergei Steshenko wrote: On Tue, 24 Jan 2006 12:39:06 + James Courtier-Dutton <[EMAIL PROTECTED]> wrote: What we have with Linux is better than what you want. You install the Linux kernel, and you have support for all sound cards already there. No need to go searching the net for some driver like one has to do in Windows. If it is not already in the Linux kernel, your sound card is unlikely to work in Linux at all. If you want support or a bug fix for some particular sound card, you then have to either wait for your distro to support it. (similar to waiting for the manufacture's web site to be updated with a new driver), or alternatively, compile the kernel and alsa from sources, and get the very latest bug fixes and features. If you think about it, the Linux way is actually a lot better than the method you are describing. It might be, but it in general is not. It is not possible for the average user to just recompile. He almost certainly did not install the development stuff when he installed Linux. He probably did not install the kernel source when he installed linux. So, before he can do "make" he has to install a HUGE list of development programs and libraries and he has to find the kernel source and config files for his particular version of Linux. In the process he has to resolve a bunch of dependencies, by which time he is screaming. Then he can finally do the make, and the make install. Even on my system, I was going to install the 1.0.10 alsa, and ran make, only to notice that the only source I had installed was the 2.6.8.1 when I had months ago replaced the running kernel with 2.6.11, without the source. Also, sometimes I switch between kernels. And suddenly I have to recompile for both kernels. This is both a pain and is something that would drive the naive user around the bend. These things are easy for those of us who have done it a lot, and have gotten over the fear that anything we do could destroy the system (in part because we have the confidence that if it were destroyed, we could fix it). So, What is the problem with making the module--kernel interface so that a driver compiled for 2.6.x would run without recompilation on 2.6.y? Is it a philosophical position, that the linux developers want to ensure that this does not get done, as the quote seems to indicate? Or is there some deep technical reason why this is difficult/impossible to do? This is not an issue of closed source/open source. I am asking a technical question about the design of the module-kernel interface. Basically, end user should not be forced to compile a driver. Any honest developer should release his/her code only after sanity checks, the first of them being compileability. So, after that first sanity check the compiled driver already exists. --- 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
Re: [Alsa-user] stable APIs and ABIs
Lee Revell wrote: I have not made any silly statements. Yes, closed source is debugged, by the people who have the source code. If parts of the kernel are allowed to be closed source it becomes impossible for anyone except the people who have the source code to the closed part to debug it. Actually, Lee, it's worse than that. And I've yet to see you make a silly statement. In userland I had a problem with apparently unrelated libraries interfering with each other. It turned out that is was a bad case of symbol overloading -- and I only found the problem by having the source of both libraries. If you have bad interactions between two closed-source drivers in the kernel then there is no one who can debug the problem because no one has the source needed to debug the problem. I think, to be honest, the problem about source code is more to do with who can make the fix. If there's a bug that annoys me and my friends enough, we'll either fix it or analyse the source enough to work around it. My friends and I have next to no influence over any vendors so if we have a bug in there code we either live with it or change the hardware. It's only when such a bug affects enough people that the manufacturer does something about it, and by that time there's been a lot of damage done to the vendors reputation -- look how much people like the old creative soundcards and how much bad press the new ones get and by the time Creative notice they've shot themselves in the foot it'll be too late. jch --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tuesday 24 January 2006 07:50, Sergei Steshenko wrote: >On Tue, 24 Jan 2006 12:39:06 + > >James Courtier-Dutton <[EMAIL PROTECTED]> wrote: >> Sergei Steshenko wrote: >> > Takashi, as end user I want to know nothing about alsa-lib and >> > kernel. >> > >> > I want to have a website with driver per card, i.e. I want to >> > perform only intellectualy primitive lookup operation: read the >> > file names in repository, find the file which matches my card name >> > and install it. >> > >> > Like with 'xpdf' - I see the program name (moral equivalent of my >> > card name) and version suffix. If the newest version doesn't work, >> > I revert to an older one. >> >> Sergei, >> >> What we have with Linux is better than what you want. >> You install the Linux kernel, and you have support for all sound >> cards already there. No need to go searching the net for some driver >> like one has to do in Windows. >> If it is not already in the Linux kernel, your sound card is >> unlikely to work in Linux at all. >> If you want support or a bug fix for some particular sound card, you >> then have to either wait for your distro to support it. (similar to >> waiting for the manufacture's web site to be updated with a new >> driver), or alternatively, compile the kernel and alsa from sources, >> and get the very latest bug fixes and features. >> >> If you think about it, the Linux way is actually a lot better than >> the method you are describing. >> >> James > >Well, Jaroslav wants this discussion to be over... > So let it... >I compiled kernel on a number of occasions a number of years ago. >And it even worked. I do too, following Linus's releases, currently running 2.6.16-rc1. >However, the number of configuration options is scary, and thus the >chance to make a mistake. Which is precisely why you copy the .config from the older version and then do a make oldconfig, which sets the new options from the older ones. >So, replacing just one part of the system (a driver in question), and >replacing it with the one compiled by you, the professionals, seems to > me to be a much safer option. > >Basically, end user should not be forced to compile a driver. >Any honest developer should release his/her code only after sanity > checks, the first of them being compileability. So, after that first > sanity check the compiled driver already exists. I'm the end user, and I have no problems with that, with either the idea that I might have to do it, or in doing it if the documentation is current. I'd even write "and your point is?" but this thread should end. So beit. -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tuesday 24 January 2006 06:47, Sergei Steshenko wrote: >On Tue, 24 Jan 2006 12:42:32 +0100 > >Takashi Iwai <[EMAIL PROTECTED]> wrote: >> At Tue, 24 Jan 2006 13:03:45 +0200, >> >> Sergei Steshenko wrote: >> > 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. >> >> The binary compatibility of alsa-lib has been kept for long time. >> We have occasionally fixes and extensions, but the old binary should >> run. >> >> However, the often problematic part during versions is the >> confiugration. It's not API/ABI. >> >> >> Takashi > >Again, in simple English, is there a document describing how >to install, say, binary ALSA version 1.0.6 on 2.6.15 kernel ? I don't know about the document, but up until a week ago, I had been running alsalib-1.0.3b with kernels as new as 2.6.16-rc1. My hardware hadn't changed until I added an SB Audigy2 Value card in all this time, so why should the userland driver change? >Also, please see very recent Lee's note and pay attention to these > words: > >" >This won't work as 1.0.9-rc4 is older than the version that comes with >kernel 2.6.13. Either use the latest ALSA release (1.0.10) or just > use the version included with kernel 2.6.13. >". > > >Guys, actually, nobody cares how you call it - ABI or API. > >Let's talk in consumer's language - if newer binary version doesn't >work, but an older binary version used to work, making the whole thing >work should be no more complex than replacing new 'xpdf' RPM with the >old one. Agreed. [...] This whole thread is essentially a waste of time, and somewhat resembles elephant breeding in that there is a lot of trumpeting and foot stomping, and it will be 22 months before the results can be known to be successfull. What we preach here has very close to zero effect either on the kernel people, or on the vendor whose code is tied up in so much cross licenseing of patents and copyrights that there is no way in hell it will be released because if he did, the lawyers will have them for lunch, as the main course. It _is_ how things are, either get used to it or go bug the proprietary people & leave us alone. The only way the situation will ever change is if and when linux becomes more than 5% of that vendors bottom line. At that point, market forces alone will fix the problem, or that vendor will become irrevelant, maybe even extinct by the time linux has hit the 10% mark. We, for all our high and mighty sounding debates, can do nothing about it that takes effect _today_. This thread is a waste of everyones time. Lets end it and get back to business as usual, which I'm told, on this list, has to do with alsasound support. -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. --- 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
Re: [Alsa-user] stable APIs and ABIs
At Tue, 24 Jan 2006 14:16:52 +0200, Sergei Steshenko wrote: > > On Tue, 24 Jan 2006 13:14:15 +0100 > Takashi Iwai <[EMAIL PROTECTED]> wrote: > > > At Tue, 24 Jan 2006 13:47:47 +0200, > > Sergei Steshenko wrote: > > > > > > On Tue, 24 Jan 2006 12:42:32 +0100 > > > Takashi Iwai <[EMAIL PROTECTED]> wrote: > > > > > > > At Tue, 24 Jan 2006 13:03:45 +0200, > > > > Sergei Steshenko wrote: > > > > > > > > > > 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. > > > > > > > > The binary compatibility of alsa-lib has been kept for long time. We > > > > have occasionally fixes and extensions, but the old binary should run. > > > > > > > > However, the often problematic part during versions is the > > > > confiugration. It's not API/ABI. > > > > > > > > > > > > Takashi > > > > > > > > > > > > > Again, in simple English, is there a document describing how > > > to install, say, binary ALSA version 1.0.6 on 2.6.15 kernel ? > > > > In simple shell syntax: > > > > tar xvf alsa-lib-1.0.6.tar.gz > > ./configure > > su -c "make install" > > > > > Also, please see very recent Lee's note and pay attention to these words: > > > > > > " > > > This won't work as 1.0.9-rc4 is older than the version that comes with > > > kernel 2.6.13. Either use the latest ALSA release (1.0.10) or just use > > > the version included with kernel 2.6.13. > > > ". > > > > Yeah, it is the very configuration issue (and the very specific to > > each sound card). You might need to modify the alsa-lib configuration > > files to suit with the latest driver status after you instal the older > > alsa-lib. > > > > We don't guarantee that alsa-lib-1.0.9 configuration does work with > > 2.6.15 kernel and we don't dare to fix old releases. But the old > > binary itself can communicate with the kernel without any problems. > > Of course there were bugs in old alsa-lib, but it's irrelevant with > > the topic here. > > > > > > Takashi > > > > Takashi, as end user I want to know nothing about alsa-lib and kernel. > > I want to have a website with driver per card, i.e. I want to perform > only intellectualy primitive lookup operation: read the file names in > repository, find the file which matches my card name and install it. Any problem with alsaconf for such a purpose? > Like with 'xpdf' - I see the program name (moral equivalent of my card name) > and version suffix. If the newest version doesn't work, I revert to an older > one. Well, it's only if the configuration (or its syntax) of your app between both versions isn't changed. You had a luck with xpdf :) In alsa-lib it happened sometimes, as you know. And, yes, it'd be definitely better to restrict the check of the consistentcy of configurations in alsa-lib. Takashi --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 24 Jan 2006 12:39:06 + James Courtier-Dutton <[EMAIL PROTECTED]> wrote: > Sergei Steshenko wrote: > > Takashi, as end user I want to know nothing about alsa-lib and kernel. > > > > I want to have a website with driver per card, i.e. I want to perform > > only intellectualy primitive lookup operation: read the file names in > > repository, find the file which matches my card name and install it. > > > > Like with 'xpdf' - I see the program name (moral equivalent of my card name) > > and version suffix. If the newest version doesn't work, I revert to an older > > one. > > > > > Sergei, > > What we have with Linux is better than what you want. > You install the Linux kernel, and you have support for all sound cards > already there. No need to go searching the net for some driver like one > has to do in Windows. > If it is not already in the Linux kernel, your sound card is unlikely to > work in Linux at all. > If you want support or a bug fix for some particular sound card, you > then have to either wait for your distro to support it. (similar to > waiting for the manufacture's web site to be updated with a new driver), > or alternatively, compile the kernel and alsa from sources, and get the > very latest bug fixes and features. > > If you think about it, the Linux way is actually a lot better than the > method you are describing. > > James > Well, Jaroslav wants this discussion to be over... I compiled kernel on a number of occasions a number of years ago. And it even worked. However, the number of configuration options is scary, and thus the chance to make a mistake. So, replacing just one part of the system (a driver in question), and replacing it with the one compiled by you, the professionals, seems to me to be a much safer option. Basically, end user should not be forced to compile a driver. Any honest developer should release his/her code only after sanity checks, the first of them being compileability. So, after that first sanity check the compiled driver already exists. --- 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
Re: [Alsa-user] stable APIs and ABIs
Sergei Steshenko wrote: Takashi, as end user I want to know nothing about alsa-lib and kernel. I want to have a website with driver per card, i.e. I want to perform only intellectualy primitive lookup operation: read the file names in repository, find the file which matches my card name and install it. Like with 'xpdf' - I see the program name (moral equivalent of my card name) and version suffix. If the newest version doesn't work, I revert to an older one. Sergei, What we have with Linux is better than what you want. You install the Linux kernel, and you have support for all sound cards already there. No need to go searching the net for some driver like one has to do in Windows. If it is not already in the Linux kernel, your sound card is unlikely to work in Linux at all. If you want support or a bug fix for some particular sound card, you then have to either wait for your distro to support it. (similar to waiting for the manufacture's web site to be updated with a new driver), or alternatively, compile the kernel and alsa from sources, and get the very latest bug fixes and features. If you think about it, the Linux way is actually a lot better than the method you are describing. James --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 24 Jan 2006, Sergei Steshenko wrote: > Takashi, as end user I want to know nothing about alsa-lib and kernel. > > I want to have a website with driver per card, i.e. I want to perform > only intellectualy primitive lookup operation: read the file names in > repository, find the file which matches my card name and install it. > > Like with 'xpdf' - I see the program name (moral equivalent of my card > name) and version suffix. If the newest version doesn't work, I revert > to an older one. If the end user is not capable to do the standard *nix installation, then nothing can help. The distribution makers are supposed to offer the user friendly interface for installation and upgrade. It's out of scope of standard projects to prepare such "one click" operations for end users. I haven't found anything interesting for our project in this discussion, so I vote to end it. Jaroslav - Jaroslav Kysela <[EMAIL PROTECTED]> Linux Kernel Sound Maintainer ALSA Project, SUSE Labs --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 24 Jan 2006 13:14:15 +0100 Takashi Iwai <[EMAIL PROTECTED]> wrote: > At Tue, 24 Jan 2006 13:47:47 +0200, > Sergei Steshenko wrote: > > > > On Tue, 24 Jan 2006 12:42:32 +0100 > > Takashi Iwai <[EMAIL PROTECTED]> wrote: > > > > > At Tue, 24 Jan 2006 13:03:45 +0200, > > > Sergei Steshenko wrote: > > > > > > > > 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. > > > > > > The binary compatibility of alsa-lib has been kept for long time. We > > > have occasionally fixes and extensions, but the old binary should run. > > > > > > However, the often problematic part during versions is the > > > confiugration. It's not API/ABI. > > > > > > > > > Takashi > > > > > > > > > Again, in simple English, is there a document describing how > > to install, say, binary ALSA version 1.0.6 on 2.6.15 kernel ? > > In simple shell syntax: > > tar xvf alsa-lib-1.0.6.tar.gz > ./configure > su -c "make install" > > > Also, please see very recent Lee's note and pay attention to these words: > > > > " > > This won't work as 1.0.9-rc4 is older than the version that comes with > > kernel 2.6.13. Either use the latest ALSA release (1.0.10) or just use > > the version included with kernel 2.6.13. > > ". > > Yeah, it is the very configuration issue (and the very specific to > each sound card). You might need to modify the alsa-lib configuration > files to suit with the latest driver status after you instal the older > alsa-lib. > > We don't guarantee that alsa-lib-1.0.9 configuration does work with > 2.6.15 kernel and we don't dare to fix old releases. But the old > binary itself can communicate with the kernel without any problems. > Of course there were bugs in old alsa-lib, but it's irrelevant with > the topic here. > > > Takashi > Takashi, as end user I want to know nothing about alsa-lib and kernel. I want to have a website with driver per card, i.e. I want to perform only intellectualy primitive lookup operation: read the file names in repository, find the file which matches my card name and install it. Like with 'xpdf' - I see the program name (moral equivalent of my card name) and version suffix. If the newest version doesn't work, I revert to an older one. --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 24 Jan 2006 12:59:14 +0100 "Peter Zubaj" <[EMAIL PROTECTED]> wrote: > > >On Tue, 24 Jan 2006 11:27:20 + > >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
Re: [Alsa-user] stable APIs and ABIs
At Tue, 24 Jan 2006 13:47:47 +0200, Sergei Steshenko wrote: > > On Tue, 24 Jan 2006 12:42:32 +0100 > Takashi Iwai <[EMAIL PROTECTED]> wrote: > > > At Tue, 24 Jan 2006 13:03:45 +0200, > > Sergei Steshenko wrote: > > > > > > 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. > > > > The binary compatibility of alsa-lib has been kept for long time. We > > have occasionally fixes and extensions, but the old binary should run. > > > > However, the often problematic part during versions is the > > confiugration. It's not API/ABI. > > > > > > Takashi > > > > > Again, in simple English, is there a document describing how > to install, say, binary ALSA version 1.0.6 on 2.6.15 kernel ? In simple shell syntax: tar xvf alsa-lib-1.0.6.tar.gz ./configure su -c "make install" > Also, please see very recent Lee's note and pay attention to these words: > > " > This won't work as 1.0.9-rc4 is older than the version that comes with > kernel 2.6.13. Either use the latest ALSA release (1.0.10) or just use > the version included with kernel 2.6.13. > ". Yeah, it is the very configuration issue (and the very specific to each sound card). You might need to modify the alsa-lib configuration files to suit with the latest driver status after you instal the older alsa-lib. We don't guarantee that alsa-lib-1.0.9 configuration does work with 2.6.15 kernel and we don't dare to fix old releases. But the old binary itself can communicate with the kernel without any problems. Of course there were bugs in old alsa-lib, but it's irrelevant with the topic here. Takashi --- 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
Re: Re: [Alsa-user] stable APIs and ABIs
>On Tue, 24 Jan 2006 11:27:20 + >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 Aktivujte si neobmedzenu mailovu schranku na www.pobox.sk! --- 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&kid3432&bid#0486&dat1642 ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: Re: [Alsa-user] stable APIs and ABIs
>On Tue, 24 Jan 2006 11:27:20 + >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 Aktivujte si neobmedzenu mailovu schranku na www.pobox.sk! --- 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&kid3432&bid#0486&dat1642 ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] stable APIs and ABIs
On Tue, 24 Jan 2006, Sergei Steshenko wrote: > > > Comparing the above two I'd say that the difference is IDE bus vs. PCI > > > bus. > > > > > > So, why do we have such a discrimination here. Aren't buses and drivers > > > created > > > equal ? > > > > No, because the firmware runs on the device, while the driver runs > > on the CPU and it's linked to the kernel. > > > Look, "the device" a piece of metal, with electric motor(s) and a piece > of plastic (the device PCB) on which the controller, which is also kind > of CPU for the deive, is installed. > > "The CPU" is also a CPU, which is installed onto a piece of plastic > (the motherboard PCB); typically CPU works with an electric motor - its > cooling fan. Or, by the way, the heatsink, and the computer case as a whole, > are also pieces of metal. > > Should I go down to similarity between screws, voltage regulators, decoupling > caps, resistors, etc. ? However, the kernel runs on one of those things and the firmware on different one. The point is that the firmware is independent on the kernel because it does not share or is linked to any code that belongs to the kernel, neither when it was compiled, nor when it is executed. Since it's a completely distinct and independent peice of software, it is not required to be GPL'd. The only concern is if it's legal to include the binary image of the firmware inside the driver. -- Giuliano. --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 24 Jan 2006 12:42:32 +0100 Takashi Iwai <[EMAIL PROTECTED]> wrote: > At Tue, 24 Jan 2006 13:03:45 +0200, > Sergei Steshenko wrote: > > > > 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. > > The binary compatibility of alsa-lib has been kept for long time. We > have occasionally fixes and extensions, but the old binary should run. > > However, the often problematic part during versions is the > confiugration. It's not API/ABI. > > > Takashi > Again, in simple English, is there a document describing how to install, say, binary ALSA version 1.0.6 on 2.6.15 kernel ? Also, please see very recent Lee's note and pay attention to these words: " This won't work as 1.0.9-rc4 is older than the version that comes with kernel 2.6.13. Either use the latest ALSA release (1.0.10) or just use the version included with kernel 2.6.13. ". Guys, actually, nobody cares how you call it - ABI or API. Let's talk in consumer's language - if newer binary version doesn't work, but an older binary version used to work, making the whole thing work should be no more complex than replacing new 'xpdf' RPM with the old one. From: Lee Revell <[EMAIL PROTECTED]> To: Väisänen Teemu <[EMAIL PROTECTED]> Cc: alsa-user@lists.sourceforge.net Subject: Re: [Alsa-user] Problems with 2.6.13.1 kernel and alsa 1.0.9-rc4 Date: Tue, 24 Jan 2006 05:05:58 -0500 Sender: [EMAIL PROTECTED] X-Mailer: Evolution 2.5.4 On Tue, 2006-01-24 at 11:56 +0200, Väisänen Teemu wrote: > Hi all. > > I managed to get sounds working perfectly with kernel 2.6.11 and alsa > 1.0.9-rc4 with help of > http://www.alsa-project.org/alsa-doc/doc-php/template.php?company=Intel&card=ICH+southbridge+AC97+audio.&chip=440MX%2C+i810%2C+i810E%2C+i820%2C+ICH4%2C+ICH5%2C+ICH6&module=intel8x0 > (I'm having Intel 82891BA/BAM AC'97 Audio) but when I'm trying to > install alsa same way to 2.6.13.1, I get messages as: > > .../*.ko needs unknown symbol class_simple_device_add > .../*.ko needs unknown symbol class_simple_device_destroy > .../*.ko needs unknown symbol class_simple_device_remove > > Where .../*.ko is for example /lib/modules/2.6.13.1/kernel/sound/acore/snd.ko > > Do you know is problem caused by alsa drivers or kernel? This won't work as 1.0.9-rc4 is older than the version that comes with kernel 2.6.13. Either use the latest ALSA release (1.0.10) or just use the version included with kernel 2.6.13. BTW there's no reason to run 2.6.13.1, there are newer 2.6.13.x kernels available. Lee " --- 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&kid3432&bid#0486&dat1642 ___ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
Re: [Alsa-user] stable APIs and ABIs
On Tue, 24 Jan 2006 11:27:20 + 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 ? --- 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
Re: [Alsa-user] stable APIs and ABIs
At Tue, 24 Jan 2006 13:03:45 +0200, Sergei Steshenko wrote: > > 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. The binary compatibility of alsa-lib has been kept for long time. We have occasionally fixes and extensions, but the old binary should run. However, the often problematic part during versions is the confiugration. It's not API/ABI. Takashi --- 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
Re: [Alsa-user] stable APIs and ABIs
Bill Unruh wrote: On Mon, 23 Jan 2006, Lee Revell wrote: On Tue, 2006-01-24 at 06:02 +0200, Sergei Steshenko wrote: I was talking about the moral/ideological issue. My point is that from moral/ideological point of view it doesn't make sense to insist on OSS only in one case. It's not a moral or ideological issue, it's a technical one - there's no reasonable way to debug a program if the source code is not available. Sure there is. Most software is closed source and most software is also debugged. Not by you or me, but by someone. And for the vast majority of users, they have to wait for someone else to do it. I agree completely that opensource is great and would love all software to be be opensource. But that battle is not won by making silly statements. Bill, you are talking rubbish now. To debug a program you need the source code. If I only have half the source code, (i.e half open source, half closed source), I still cannot do proper debugging tasks, because I don't have proper visibility of all the source code. There are some software bugs that you HAVE to have the full source code in order to fully debug. James --- 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
Re: [Alsa-user] stable APIs and ABIs
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 --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 24 Jan 2006 11:57:58 +0100 (CET) Giuliano Pochini <[EMAIL PROTECTED]> wrote: > > On 24-Jan-2006 Sergei Steshenko wrote: > > > 1) we have an IDE drive separated from the CPU by IDE bus. The IDE drive > > runs closed-source firmware, which is in terms of the controller inside the > > drive still software. There is no fuss about it; > > > > 2) we have a WiFi card or an audio card - both sitting on PCI bus, i.e. they > > are separated from the CPU by PCI bus. If the cards are running closed > > source > > software (their respective drivers) there is a fuss about it. > > > > Comparing the above two I'd say that the difference is IDE bus vs. PCI bus. > > > > So, why do we have such a discrimination here. Aren't buses and drivers > > created > > equal ? > > No, because the firmware runs on the device, while the driver runs > on the CPU and it's linked to the kernel. > > > -- > Giuliano. > > Look, "the device" a piece of metal, with electric motor(s) and a piece of plastic (the device PCB) on which the controller, which is also kind of CPU for the device, is installed. "The CPU" is also a CPU, which is installed onto a piece of plastic (the motherboard PCB); typically CPU works with an electric motor - its cooling fan. Or, by the way, the heatsink, and the computer case as a whole, are also pieces of metal. Should I go down to similarity between screws, voltage regulators, decoupling caps, resistors, etc. ? --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 24 Jan 2006 11:57:58 +0100 (CET) Giuliano Pochini <[EMAIL PROTECTED]> wrote: > > On 24-Jan-2006 Sergei Steshenko wrote: > > > 1) we have an IDE drive separated from the CPU by IDE bus. The IDE drive > > runs closed-source firmware, which is in terms of the controller inside the > > drive still software. There is no fuss about it; > > > > 2) we have a WiFi card or an audio card - both sitting on PCI bus, i.e. they > > are separated from the CPU by PCI bus. If the cards are running closed > > source > > software (their respective drivers) there is a fuss about it. > > > > Comparing the above two I'd say that the difference is IDE bus vs. PCI bus. > > > > So, why do we have such a discrimination here. Aren't buses and drivers > > created > > equal ? > > No, because the firmware runs on the device, while the driver runs > on the CPU and it's linked to the kernel. > > > -- > Giuliano. > > Look, "the device" a piece of metal, with electric motor(s) and a piece of plastic (the device PCB) on which the controller, which is also kind of CPU for the deive, is installed. "The CPU" is also a CPU, which is installed onto a piece of plastic (the motherboard PCB); typically CPU works with an electric motor - its cooling fan. Or, by the way, the heatsink, and the computer case as a whole, are also pieces of metal. Should I go down to similarity between screws, voltage regulators, decoupling caps, resistors, etc. ? --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 24 Jan 2006 10:54:33 + James Courtier-Dutton <[EMAIL PROTECTED]> wrote: > Sergei Steshenko wrote: > > We have already discussed this, here's yet another opinion: > > > > http://ask.slashdot.org/article.pl?sid=06/01/23/214258 -> > > > > " > > This is why we need a kernel api and abi > > (Score:2) > > by Billly Gates (198444) Alter Relationship on Tuesday January 24, @02:03AM > > (#14544582) > > (http://www.livejournal.com/users/sinistertim101 | Last Journal: Thursday > > December 22, @08:27PM) > > Flamebait all you want from the moderators reading this belonging to the > > pure gnu persusian but writing closed source drivers are tough for linux. > > > > > This has ZERO to do with ALSA, so why did you post it here? > > James > > > > > --- > 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 > 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. --- 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
Re: [Alsa-user] stable APIs and ABIs
On 24-Jan-2006 Sergei Steshenko wrote: > 1) we have an IDE drive separated from the CPU by IDE bus. The IDE drive > runs closed-source firmware, which is in terms of the controller inside the > drive still software. There is no fuss about it; > > 2) we have a WiFi card or an audio card - both sitting on PCI bus, i.e. they > are separated from the CPU by PCI bus. If the cards are running closed source > software (their respective drivers) there is a fuss about it. > > Comparing the above two I'd say that the difference is IDE bus vs. PCI bus. > > So, why do we have such a discrimination here. Aren't buses and drivers > created > equal ? No, because the firmware runs on the device, while the driver runs on the CPU and it's linked to the kernel. -- Giuliano. --- 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
Re: [Alsa-user] stable APIs and ABIs
Sergei Steshenko wrote: We have already discussed this, here's yet another opinion: http://ask.slashdot.org/article.pl?sid=06/01/23/214258 -> " This is why we need a kernel api and abi (Score:2) by Billly Gates (198444) Alter Relationship on Tuesday January 24, @02:03AM (#14544582) (http://www.livejournal.com/users/sinistertim101 | Last Journal: Thursday December 22, @08:27PM) Flamebait all you want from the moderators reading this belonging to the pure gnu persusian but writing closed source drivers are tough for linux. This has ZERO to do with ALSA, so why did you post it here? James --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tuesday 24 January 2006 07:37, Bill Unruh wrote: > > ?? And how many such suits have there been? > You are maybe going to take on Microsoft and see if their tcp stack > contains any of your GPL code ( you after all cannot sue for anyone else). > What is "versin controll system" btw, MS used the BSD stack. Nothing wrong with that. BSD lizence does allow you to do with the code, what you want to do. The GPL does not (it does not allow you to make closed source software out of open source software). So, if you are not happy with the GPL, go BSD. I bet, they will be happy about another GPL-hater and we have peace back on this list. Nobody is holding you back. NetBSD, FreeBSD, Dragonfly, OpenBSD, see, there are even several flavours, so you can choice the one you like the best. No need to deal with the linux kernel, if you can not stand the licence. --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tuesday 24 January 2006 07:37, Bill Unruh wrote: > On Tue, 24 Jan 2006, Hemmann, Volker Armin wrote: > > On Tuesday 24 January 2006 07:04, Bill Unruh wrote: > >> On Mon, 23 Jan 2006, Lee Revell wrote: > >>> On Tue, 2006-01-24 at 03:03 +0100, Hemmann, Volker Armin wrote: > btw, where are suddenly all this 'we need a fix binary abi' people are > coming > from? > > Until ca 2 month ago they never spoke up, and suddenly in every forum > or mailing lists are popping up people, most of them posting for the > first time, demanding a fix ABI. > >>> > >>> It seems to have coincided with the "Linux in a binary world (a > >>> doomsday scenario)" thread on LKML around the same time, when some > >>> kernel developers made it clear that the days of them tolerating > >>> proprietary drivers are numbered. Many people seem to be afraid they > >>> will lose support for their favorite binary-driver hardware, and are > >>> trying to put pressure on the kernel community, rather than on the > >>> vendors where it belongs. > >> > >> This being a religious statement? Most users want a system that works. > >> They really do not care that much exactly why and how. And when people > >> come out and declare that they do not care about the users, but that > >> their principles come first, people not unnaturally get upset. At both, > >> but unfortunately or otherwise, the developers are more public. > > > > no, the problem is, that a lot of people demand stupid things instead of > > thinking about the arguments made by the devs. > > binary drivers only hurt the development of linux in the long run. Nobody > > can debug a kernel with binary drivers. And there is a simple solution: > > get your drivers into the kernel, or make them completly userspace. > > > > Most users are ok with that, but some (and I suspect that most of them > > have a windows system full of pirated software) are crying, that the devs > > don't care. > > Which is a blatant lie. > > > >> What are they going to do? Do a SCO and sue everyone around? Rewrite the > >> kernel so that proprietary drivers do not work (boy that will make them > >> popular)? Maybe force everyone to send any drivers to Linus for his > >> personal imprimature before they run? > > > > there is no need to rewrite the kernel to make binary drivers unusable. > > The normal course of development means that binary drivers need ongoing > > maintance or don't work at all. > > The statement was "some kernel > developers made it clear that the days of them tolerating proprietary > drivers are numbered." > > "Not tolerate" is much stronger than "normal course of development" I was > asking what form their "not tolerate" was going to take. > > > Look at all the patches nvidia posts in their forums. > > "not tolerate" means that somehow they will stop nvidia from posting > patches. > > > Or think about the fact, that via released some unichrome drivers some > > weeks ago - for some redhat kernels only. > > "not tolerate" seems to mean that via cannot release any drivers. None. > For anyone's kernel. which would be less damaging than releasing them for two certain kernel versions, forcing everybody to use a certain distro with a certain kernel with certain, known security problems > > That is extrem user-unfriendly. I was so angry, I could have bite into my > > table - and I don't even use via. > > Because it is so wrong and harms every unichrome and not-redhat user. > > "not tolerate" is extemely user-unfriendly. 'some devs' (and not Linus T.) what do you not understand? And nvidia&co got only a shot in front of their feet, to wake them up. No harm has been done so far. So what are you whining about? > > > Oh, and because you mentioned SCO: > > scho had three years and have not shown anything, but set some > > interesstin precedence. > > Yes, I asked that question on purpose. > > > If some dev suspects a company to incorporate GPL'ed code, he is not only > > able to sue (because of violation of copyright law) but demand wide > > access to the versin controll system. > > ?? And how many such suits have there been? > You are maybe going to take on Microsoft and see if their tcp stack > contains any of your GPL code ( you after all cannot sue for anyone else). > What is "versin controll system" oh, and now we are at the 'if you don't have arguments, attack typing mistakes' level. version control system. You should know, what a version controll system is. > > > And that is not funny. > > > > btw, there have been a lot of violations. Corporations 'stealing' GPL'ed > > code. They got sued - they lost. > > Who got sued? What court case? Do you really expect me to search something for you, that you can easily find using google? Or heise.de? Believe me, there were several cases, and the offenders lost. gpl-violations.org will be a good first station on your research. > > > Think about that. If you are making a binary only driver which > > incorpor
Re: [Alsa-user] stable APIs and ABIs
On Mon, 2006-01-23 at 22:27 -0800, Bill Unruh wrote: > On Mon, 23 Jan 2006, Lee Revell wrote: > > > On Tue, 2006-01-24 at 06:02 +0200, Sergei Steshenko wrote: > >> I was talking about the moral/ideological issue. > >> > >> My point is that from moral/ideological point of view it doesn't make > >> sense to insist on OSS only in one case. > > > > It's not a moral or ideological issue, it's a technical one - there's no > > reasonable way to debug a program if the source code is not available. > > Sure there is. Most software is closed source and most software is also > debugged. Not by you or me, but by someone. And for the vast majority of > users, they have to wait for someone else to do it. I agree completely that > opensource is great and would love all software to be be opensource. But > that battle is not won by making silly statements. I have not made any silly statements. Yes, closed source is debugged, by the people who have the source code. If parts of the kernel are allowed to be closed source it becomes impossible for anyone except the people who have the source code to the closed part to debug it. Lee --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 24 Jan 2006, Hemmann, Volker Armin wrote: On Tuesday 24 January 2006 07:04, Bill Unruh wrote: On Mon, 23 Jan 2006, Lee Revell wrote: On Tue, 2006-01-24 at 03:03 +0100, Hemmann, Volker Armin wrote: btw, where are suddenly all this 'we need a fix binary abi' people are coming from? Until ca 2 month ago they never spoke up, and suddenly in every forum or mailing lists are popping up people, most of them posting for the first time, demanding a fix ABI. It seems to have coincided with the "Linux in a binary world (a doomsday scenario)" thread on LKML around the same time, when some kernel developers made it clear that the days of them tolerating proprietary drivers are numbered. Many people seem to be afraid they will lose support for their favorite binary-driver hardware, and are trying to put pressure on the kernel community, rather than on the vendors where it belongs. This being a religious statement? Most users want a system that works. They really do not care that much exactly why and how. And when people come out and declare that they do not care about the users, but that their principles come first, people not unnaturally get upset. At both, but unfortunately or otherwise, the developers are more public. no, the problem is, that a lot of people demand stupid things instead of thinking about the arguments made by the devs. binary drivers only hurt the development of linux in the long run. Nobody can debug a kernel with binary drivers. And there is a simple solution: get your drivers into the kernel, or make them completly userspace. Most users are ok with that, but some (and I suspect that most of them have a windows system full of pirated software) are crying, that the devs don't care. Which is a blatant lie. What are they going to do? Do a SCO and sue everyone around? Rewrite the kernel so that proprietary drivers do not work (boy that will make them popular)? Maybe force everyone to send any drivers to Linus for his personal imprimature before they run? there is no need to rewrite the kernel to make binary drivers unusable. The normal course of development means that binary drivers need ongoing maintance or don't work at all. The statement was "some kernel developers made it clear that the days of them tolerating proprietary drivers are numbered." "Not tolerate" is much stronger than "normal course of development" I was asking what form their "not tolerate" was going to take. Look at all the patches nvidia posts in their forums. "not tolerate" means that somehow they will stop nvidia from posting patches. Or think about the fact, that via released some unichrome drivers some weeks ago - for some redhat kernels only. "not tolerate" seems to mean that via cannot release any drivers. None. For anyone's kernel. That is extrem user-unfriendly. I was so angry, I could have bite into my table - and I don't even use via. Because it is so wrong and harms every unichrome and not-redhat user. "not tolerate" is extemely user-unfriendly. Oh, and because you mentioned SCO: scho had three years and have not shown anything, but set some interesstin precedence. Yes, I asked that question on purpose. If some dev suspects a company to incorporate GPL'ed code, he is not only able to sue (because of violation of copyright law) but demand wide access to the versin controll system. ?? And how many such suits have there been? You are maybe going to take on Microsoft and see if their tcp stack contains any of your GPL code ( you after all cannot sue for anyone else). What is "versin controll system" And that is not funny. btw, there have been a lot of violations. Corporations 'stealing' GPL'ed code. They got sued - they lost. Who got sued? What court case? Think about that. If you are making a binary only driver which incorporates or links into GPL'ed code you are on extremly thin ice. links into? means what? And which company was sued and lost for "liniking into GPL code". In that case I hope for you, that you have enough money for the lawyers (and your opponents lawyers if you get sued in Germany and loose). Me? You mean Microsoft? You mean Nvidia? Yes, they have enough money. --- 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
Re: [Alsa-user] stable APIs and ABIs
On Mon, 23 Jan 2006, Lee Revell wrote: On Tue, 2006-01-24 at 06:02 +0200, Sergei Steshenko wrote: I was talking about the moral/ideological issue. My point is that from moral/ideological point of view it doesn't make sense to insist on OSS only in one case. It's not a moral or ideological issue, it's a technical one - there's no reasonable way to debug a program if the source code is not available. Sure there is. Most software is closed source and most software is also debugged. Not by you or me, but by someone. And for the vast majority of users, they have to wait for someone else to do it. I agree completely that opensource is great and would love all software to be be opensource. But that battle is not won by making silly statements. --- 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
Re: [Alsa-user] stable APIs and ABIs
On Mon, 23 Jan 2006, Lee Revell wrote: On Tue, 2006-01-24 at 05:28 +0200, Sergei Steshenko wrote: " The difference is that the driver code is executed by the host CPU, while the firmware code is executed by the device " - kinda funny :-). OK, I propose to run a dual core or dual CPU computer. One CPU would be for opens source software and the other - for closed source software. Now, are the CPUs created equal ? And are the CPU and IDE driver controller created equal ? If not, why :-) ? You'd have to ask a lawyer. It depends on how "linking" is defined and you would have to go to case law for that. The consensus, presumably I do not believe there is any case law on that. Linking is a technical term in computer science. And it would have to be decided in the context of the GPL license. It is liable to come totally to grief if the courts are asked to decide what it means. You are liable to have the courts use marriage as an analogy for linking, with the whole gay marriage/ hetro marriage debate hauled in, with some totally off the wall decision made as to what counts as linking (eg that the two piece of code run on the same computer, which would mean that pine is linked to the kernel) based on what the kernel developers' lawyers have told them, is that the line is drawn between "driver" and "firmware" - firmware is not considered to be linked into the kernel, as it runs on a different CPU on the other side of a bus, while drivers are considered linked into the kernel, as they run on the same CPU in the same context as kernel code. CPUs now adays have many layers and independent sections. --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tuesday 24 January 2006 07:04, Bill Unruh wrote: > On Mon, 23 Jan 2006, Lee Revell wrote: > > On Tue, 2006-01-24 at 03:03 +0100, Hemmann, Volker Armin wrote: > >> btw, where are suddenly all this 'we need a fix binary abi' people are > >> coming > >> from? > >> > >> Until ca 2 month ago they never spoke up, and suddenly in every forum > >> or mailing lists are popping up people, most of them posting for the > >> first time, demanding a fix ABI. > > > > It seems to have coincided with the "Linux in a binary world (a doomsday > > scenario)" thread on LKML around the same time, when some kernel > > developers made it clear that the days of them tolerating proprietary > > drivers are numbered. Many people seem to be afraid they will lose > > support for their favorite binary-driver hardware, and are trying to put > > pressure on the kernel community, rather than on the vendors where it > > belongs. > > This being a religious statement? Most users want a system that works. They > really do not care that much exactly why and how. And when people come out > and declare that they do not care about the users, but that their > principles come first, people not unnaturally get upset. At both, but > unfortunately or otherwise, the developers are more public. no, the problem is, that a lot of people demand stupid things instead of thinking about the arguments made by the devs. binary drivers only hurt the development of linux in the long run. Nobody can debug a kernel with binary drivers. And there is a simple solution: get your drivers into the kernel, or make them completly userspace. Most users are ok with that, but some (and I suspect that most of them have a windows system full of pirated software) are crying, that the devs don't care. Which is a blatant lie. > > What are they going to do? Do a SCO and sue everyone around? Rewrite the > kernel so that proprietary drivers do not work (boy that will make them > popular)? Maybe force everyone to send any drivers to Linus for his > personal imprimature before they run? there is no need to rewrite the kernel to make binary drivers unusable. The normal course of development means that binary drivers need ongoing maintance or don't work at all. Look at all the patches nvidia posts in their forums. Or think about the fact, that via released some unichrome drivers some weeks ago - for some redhat kernels only. That is extrem user-unfriendly. I was so angry, I could have bite into my table - and I don't even use via. Because it is so wrong and harms every unichrome and not-redhat user. Oh, and because you mentioned SCO: scho had three years and have not shown anything, but set some interesstin precedence. If some dev suspects a company to incorporate GPL'ed code, he is not only able to sue (because of violation of copyright law) but demand wide access to the versin controll system. And that is not funny. btw, there have been a lot of violations. Corporations 'stealing' GPL'ed code. They got sued - they lost. Think about that. If you are making a binary only driver which incorporates or links into GPL'ed code you are on extremly thin ice. In that case I hope for you, that you have enough money for the lawyers (and your opponents lawyers if you get sued in Germany and loose). --- 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
Re: [Alsa-user] stable APIs and ABIs
On Mon, 23 Jan 2006, Lee Revell wrote: On Tue, 2006-01-24 at 03:03 +0100, Hemmann, Volker Armin wrote: btw, where are suddenly all this 'we need a fix binary abi' people are coming from? Until ca 2 month ago they never spoke up, and suddenly in every forum or mailing lists are popping up people, most of them posting for the first time, demanding a fix ABI. It seems to have coincided with the "Linux in a binary world (a doomsday scenario)" thread on LKML around the same time, when some kernel developers made it clear that the days of them tolerating proprietary drivers are numbered. Many people seem to be afraid they will lose support for their favorite binary-driver hardware, and are trying to put pressure on the kernel community, rather than on the vendors where it belongs. This being a religious statement? Most users want a system that works. They really do not care that much exactly why and how. And when people come out and declare that they do not care about the users, but that their principles come first, people not unnaturally get upset. At both, but unfortunately or otherwise, the developers are more public. What are they going to do? Do a SCO and sue everyone around? Rewrite the kernel so that proprietary drivers do not work (boy that will make them popular)? Maybe force everyone to send any drivers to Linus for his personal imprimature before they run? Lee --- 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 -- William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273 Physics&Astronomy | Advanced Research | Fax: +1(604)822-5324 UBC, Vancouver,BC | Program in Cosmology | [EMAIL PROTECTED] Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/ --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 2006-01-24 at 06:02 +0200, Sergei Steshenko wrote: > I was talking about the moral/ideological issue. > > My point is that from moral/ideological point of view it doesn't make > sense to insist on OSS only in one case. It's not a moral or ideological issue, it's a technical one - there's no reasonable way to debug a program if the source code is not available. Lee --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 2006-01-24 at 06:02 +0200, Sergei Steshenko wrote: > > I was trying to show that if we at all agree to live with closed > source > software, i.e. if agree to put extreme ideology aside, then we should > think > about finding a well defined place for closed source SW, so end users > will benefit from prompt release of HW drivers. Prompt release of drivers has nothing to do with open source. There are many vendors who promptly release open source drivers for their new hardware. Lee --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tuesday 24 January 2006 05:02, Sergei Steshenko wrote: > I was talking about the moral/ideological issue. > > My point is that from moral/ideological point of view it doesn't make > sense to insist on OSS only in one case. > there is no moral issue. Only a technical one. drivers are run in kernel context, firmwares run on their dedicated hardware. They are two totally different pairs of shoe. and please, do not top post. --- 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
Re: [Alsa-user] stable APIs and ABIs
I was talking about the moral/ideological issue. My point is that from moral/ideological point of view it doesn't make sense to insist on OSS only in one case. I do not argue with the definition of linking and its effect on GPL. I was trying to show that if we at all agree to live with closed source software, i.e. if agree to put extreme ideology aside, then we should think about finding a well defined place for closed source SW, so end users will benefit from prompt release of HW drivers. Furthermore, we may also think of some kind of Linux Hardware Quality Certification Lab, similar to the one Microsoft has (is it called WHQL ?). Probably OSDL (HQ in Beaverton, OR ?) can assist in this. On Mon, 23 Jan 2006 22:34:29 -0500 Lee Revell <[EMAIL PROTECTED]> wrote: > On Tue, 2006-01-24 at 05:28 +0200, Sergei Steshenko wrote: > > " > > The difference is that the driver code is executed by the > > host CPU, while the firmware code is executed by the device > > " > > > > - kinda funny :-). > > > > OK, I propose to run a dual core or dual CPU computer. > > > > One CPU would be for opens source software and the other - for closed > > source software. > > > > Now, are the CPUs created equal ? > > And are the CPU and IDE driver controller created equal ? > > > > If not, why :-) ? > > You'd have to ask a lawyer. It depends on how "linking" is defined and > you would have to go to case law for that. The consensus, presumably > based on what the kernel developers' lawyers have told them, is that the > line is drawn between "driver" and "firmware" - firmware is not > considered to be linked into the kernel, as it runs on a different CPU > on the other side of a bus, while drivers are considered linked into the > kernel, as they run on the same CPU in the same context as kernel code. > > Lee > --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 2006-01-24 at 05:28 +0200, Sergei Steshenko wrote: > " > The difference is that the driver code is executed by the > host CPU, while the firmware code is executed by the device > " > > - kinda funny :-). > > OK, I propose to run a dual core or dual CPU computer. > > One CPU would be for opens source software and the other - for closed > source software. > > Now, are the CPUs created equal ? > And are the CPU and IDE driver controller created equal ? > > If not, why :-) ? You'd have to ask a lawyer. It depends on how "linking" is defined and you would have to go to case law for that. The consensus, presumably based on what the kernel developers' lawyers have told them, is that the line is drawn between "driver" and "firmware" - firmware is not considered to be linked into the kernel, as it runs on a different CPU on the other side of a bus, while drivers are considered linked into the kernel, as they run on the same CPU in the same context as kernel code. Lee --- 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
Re: [Alsa-user] stable APIs and ABIs
" The difference is that the driver code is executed by the host CPU, while the firmware code is executed by the device " - kinda funny :-). OK, I propose to run a dual core or dual CPU computer. One CPU would be for opens source software and the other - for closed source software. Now, are the CPUs created equal ? And are the CPU and IDE driver controller created equal ? If not, why :-) ? On Mon, 23 Jan 2006 22:19:41 -0500 Lee Revell <[EMAIL PROTECTED]> wrote: > On Tue, 2006-01-24 at 05:12 +0200, Sergei Steshenko wrote: > > > > 1) we have an IDE drive separated from the CPU by IDE bus. The IDE drive > > > > runs closed-source firmware, which is in terms of the controller inside > > > > the > > > > drive still software. There is no fuss about it; > > > > > > > > 2) we have a WiFi card or an audio card - both sitting on PCI bus, i.e. > > > > they > > > > are separated from the CPU by PCI bus. If the cards are running closed > > > > source > > > > software (their respective drivers) there is a fuss about it. > > > > > > > > Comparing the above two I'd say that the difference is IDE bus vs. PCI > > > > bus. > > > > > > The PCI/IDE issue is irrelevant - both devices may require a driver and > firmware. The difference is that the driver code is executed by the > host CPU, while the firmware code is executed by the device. Therefore > the firmware is allowed to be closed source but not the driver. > > Lee > > > > --- > 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 > --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 2006-01-24 at 05:12 +0200, Sergei Steshenko wrote: > > > 1) we have an IDE drive separated from the CPU by IDE bus. The IDE drive > > > runs closed-source firmware, which is in terms of the controller inside > > > the > > > drive still software. There is no fuss about it; > > > > > > 2) we have a WiFi card or an audio card - both sitting on PCI bus, i.e. > > > they > > > are separated from the CPU by PCI bus. If the cards are running closed > > > source > > > software (their respective drivers) there is a fuss about it. > > > > > > Comparing the above two I'd say that the difference is IDE bus vs. PCI > > > bus. > > > The PCI/IDE issue is irrelevant - both devices may require a driver and firmware. The difference is that the driver code is executed by the host CPU, while the firmware code is executed by the device. Therefore the firmware is allowed to be closed source but not the driver. Lee --- 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
Re: [Alsa-user] stable APIs and ABIs
I do not see the point - malfunctioning hardware, regardless of openness or closeness of driver, can render the system unusable. So what ? My point was about interaction of open and closed source software. I still believe there is a discrimination (PCI <-> IDE attitude). By the way, both IDE drive (sitting on IDE bus) and sound card (sitting on PCI bus) can and do use interrupts and DMA, so, again, why is the difference in attitude ? On Mon, 23 Jan 2006 21:54:26 -0500 Lee Revell <[EMAIL PROTECTED]> wrote: > On Tue, 2006-01-24 at 04:49 +0200, Sergei Steshenko wrote: > > Regarding > > > > " > > firmwares are not drivers. Firmwares are an entity of their own. Please > > inform > > yourself about firmwares and what they do and where they live and compare > > them to drivers. And there are many firmware hacks or open firmwares if you > > use a search engine of your choice. > > ". > > > > Specifically, regarding "Please inform yourself about firmwares ..." I hope > > I am well informed - I used to write both firmware and drivers, in pre-Linux > > (and pre-Windows for that matter) era. > > > > You probably are missing my (implied) point, which is: > > > > 1) we have an IDE drive separated from the CPU by IDE bus. The IDE drive > > runs closed-source firmware, which is in terms of the controller inside the > > drive still software. There is no fuss about it; > > > > 2) we have a WiFi card or an audio card - both sitting on PCI bus, i.e. they > > are separated from the CPU by PCI bus. If the cards are running closed > > source > > software (their respective drivers) there is a fuss about it. > > > > Comparing the above two I'd say that the difference is IDE bus vs. PCI bus. > > > > So, why do we have such a discrimination here. Aren't buses and drivers > > created > > equal ? > > Because of things like DMA, and interrupts, where a misbehaved driver > can hang the machine, or write any data anywhere in the kernel's address > space, and driver code runs on the same CPU, in kernel context. > Misbehaving firmware can disable the device, but it does not have full > access to the kernel's internal data structures the way drivers do. > > Lee > --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 2006-01-24 at 04:49 +0200, Sergei Steshenko wrote: > Regarding > > " > firmwares are not drivers. Firmwares are an entity of their own. Please > inform > yourself about firmwares and what they do and where they live and compare > them to drivers. And there are many firmware hacks or open firmwares if you > use a search engine of your choice. > ". > > Specifically, regarding "Please inform yourself about firmwares ..." I hope > I am well informed - I used to write both firmware and drivers, in pre-Linux > (and pre-Windows for that matter) era. > > You probably are missing my (implied) point, which is: > > 1) we have an IDE drive separated from the CPU by IDE bus. The IDE drive > runs closed-source firmware, which is in terms of the controller inside the > drive still software. There is no fuss about it; > > 2) we have a WiFi card or an audio card - both sitting on PCI bus, i.e. they > are separated from the CPU by PCI bus. If the cards are running closed source > software (their respective drivers) there is a fuss about it. > > Comparing the above two I'd say that the difference is IDE bus vs. PCI bus. > > So, why do we have such a discrimination here. Aren't buses and drivers > created > equal ? Because of things like DMA, and interrupts, where a misbehaved driver can hang the machine, or write any data anywhere in the kernel's address space, and driver code runs on the same CPU, in kernel context. Misbehaving firmware can disable the device, but it does not have full access to the kernel's internal data structures the way drivers do. Lee --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tuesday 24 January 2006 03:22, Bill Unruh wrote: > On Tue, 24 Jan 2006, Hemmann, Volker Armin wrote: > > On Tuesday 24 January 2006 02:43, Bill Unruh wrote: > >> On Tue, 24 Jan 2006, Hemmann, Volker Armin wrote: > >>> On Tuesday 24 January 2006 02:15, Sergei Steshenko wrote: > " > The Linux developers DO NOT WANT to make it possible to write closed > source drivers. Many consider it a violation of the GPL. > " > > - GPL allows to run commercial closed source programs under a > GPL'ed OS. That is, it doesn't prohibit this. > >>> > >>> no, but it prohibits you from incorporating gpl'ed code into closed > >>> source programms. > >> > >> ... > >> > Likewise, closed source drivers can be implemented as separate > processes not linked to GPL kernel an thus not violating GPL. > >>> > >>> so why has no one done it so far? > >>> > >>> The userland ABI and API has been stable the last ten years. > >>> > >>> You can take a binary, compiled on a computer using kernel 2.0.X and > >>> run it on 2.6.X > >>> > >>> You may need some glibc-wrapper, but that is not the kernels fault. > >>> > >>> So if you want to implement a driver that is completly independent from > >>> the kernel, lives in userspace, does not use GPL code in any form and > >>> is closed source, do it. Noone will hinder you in doing that. > >>> But if you are using GPL-code, you have to open it. > >> > >> ??? Noone is talking about a driver using GPL code. The question is how > >> one can have drivers which talk directly to the hardware and link into > >> the kernel. The code inside the driver need not use any GPL code. > > > > oh, and suddenly you want to link into the kernel? > > Again the code inside the driver module need not use any GPL code. Do we > agree on that? > > > I thought, we were talking about userspace? > > No, I am talking about a module. What is it about the relation of the > module to the kernel that you call that "linking" while the relation of > "userspace" program which also interacts with the kernel is not "linking" > And what is it about the "linking" that makes it not OK wrt the GPL. > > > btw, X11 was able to talk to hardware without any kernel-drivers. > > But it has to talk via the video card drivers which are kernel drivers I > would assume. > > >>> the sense of reality says them, that it is stupid to have fix internal > >>> api&abis, because they get into the way of efficient bug fixing and > >>> development. > >> > >> They also introduce bugs. > > > > and they fix them. > > Different ones. > > > Every piece of software has bugs. > > That is not a license for bad design. "Oh well, bugs will always be with > us, so we do not need to do anything to make them rarer." no, but this is the licence for 'let us be flexible, we do not know at the moment what we might did wrong'. > > > Some yoears ago, there was a nice article in Scientific America, about > > bugs in software. > > They used a mathematical proof to show, that it is not possible to write > > bugfree non-trivial software. > > > > And because of bugs, it is important to fix them. > > And to design things so that bugs occur less frequently. Fixing bugs should > always play a distant second to proper design to make bugs unlikely. unlikely, but they are there, and they will pop up. And what if the bug is in the implementation, so you have to change the ABI? OOPS out of luck, sorry guys? > > > What do you do, when you find a bug in the 'holy' internal abi, that > > should not change? > > Add one wrapper after the other? > > I agree. That is a problem. But usually it is not the abi spec that is the > bug, but some implimentation. and that is why specs never get updated, right? *laughsevily* > There is a tradeoff. But as someone ignorant of driver development, surely > it is possible to design the system so that one both has stability and > flexibility. yep, it is the linux kernel development. Works fine. > > > You can see the unholy mess of drivers, when you try and install windows. > > > > > > I am glad, that linux is much more userfriendly. > > New graphic-card? I did not have to change anything or have to change > > one(!) line in xorg.conf. > > Ageed. you claim that the only way to accomplish this is to have an > unstable API/ABI? no, just in kernel drivers. And with inkernel drivers, you do not need a stable API/ABI problem solved, next please. > > > New sound-card? make modules modules_install and modprobe the drivers. No > > reboot, nothing. > > New mainboard? The old kernel boots perfectly, but sadly I need a > > different network driver. No problem. Make the module, modprobe it. > > > > That is easy. > > Agreed that is a great feature of Linux. > But surely the current method is not the only way of achieving this > objective. > It comes at the cost of > OK,new kernel, oops, my driver no longer works. > Load in the source code and > config for the kernel, get the source for the driver, and recompile the >
Re: [Alsa-user] stable APIs and ABIs
Regarding " firmwares are not drivers. Firmwares are an entity of their own. Please inform yourself about firmwares and what they do and where they live and compare them to drivers. And there are many firmware hacks or open firmwares if you use a search engine of your choice. ". Specifically, regarding "Please inform yourself about firmwares ..." I hope I am well informed - I used to write both firmware and drivers, in pre-Linux (and pre-Windows for that matter) era. You probably are missing my (implied) point, which is: 1) we have an IDE drive separated from the CPU by IDE bus. The IDE drive runs closed-source firmware, which is in terms of the controller inside the drive still software. There is no fuss about it; 2) we have a WiFi card or an audio card - both sitting on PCI bus, i.e. they are separated from the CPU by PCI bus. If the cards are running closed source software (their respective drivers) there is a fuss about it. Comparing the above two I'd say that the difference is IDE bus vs. PCI bus. So, why do we have such a discrimination here. Aren't buses and drivers created equal ? On Tue, 24 Jan 2006 02:29:08 +0100 "Hemmann, Volker Armin" <[EMAIL PROTECTED]> wrote: > On Tuesday 24 January 2006 02:15, Sergei Steshenko wrote: > > " > > The Linux developers DO NOT WANT to make it possible to write closed > > source drivers. Many consider it a violation of the GPL. > > " > > > > - GPL allows to run commercial closed source programs under a > > GPL'ed OS. That is, it doesn't prohibit this. > > no, but it prohibits you from incorporating gpl'ed code into closed source > programms. > > > > > SYNOPSYS and Cadence VLSI-related tools are a few examples, though, > > as far as SYNOPSYS is concerned, only 2.4.* (and NOT 2.6.*) kernels > > are supported because the former are considered to have stable API. > > the userland API is stable, please inform yourself. > > > > > Likewise, closed source drivers can be implemented as separate > > processes not linked to GPL kernel an thus not violating GPL. > > > > so why has no one done it so far? > > The userland ABI and API has been stable the last ten years. > > You can take a binary, compiled on a computer using kernel 2.0.X and run it > on > 2.6.X > > You may need some glibc-wrapper, but that is not the kernels fault. > > So if you want to implement a driver that is completly independent from the > kernel, lives in userspace, does not use GPL code in any form and is closed > source, do it. Noone will hinder you in doing that. > But if you are using GPL-code, you have to open it. > Easy, isn't it? > If you write code for Windows, you have to obey to their license too. > So where is your problem? > > I tell you: there is no problem, you only want to troll. > > > ... > > > > With all the fuss, why don't the same developers demand IDE drives > > firmware to become open ? CD/DVD ROM firmware to become open ? > > firmwares are not drivers. Firmwares are an entity of their own. Please > inform > yourself about firmwares and what they do and where they live and compare > them to drivers. And there are many firmware hacks or open firmwares if you > use a search engine of your choice. > > > > > That is, where does the developers' sense of reality begin and where > > does it end ? > > the sense of reality says them, that it is stupid to have fix internal > api&abis, because they get into the way of efficient bug fixing and > development. > > Stop trolling, start reading&thinking, > > thank you. > > > > --- > 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 > --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 2006-01-24 at 04:39 +0200, Sergei Steshenko wrote: > Regarding > > " > kernel > developers made it clear that the days of them tolerating proprietary > drivers are numbered. > " > > I am sorry I do not have time at the moment to try XEN (I've already > expressed this idea). > > The idea is: > > 1) in a user machine there will be at least two kernels running > - the main one, which will also be the most up to date one, and the guest > one; > > 2) the main kernel will be configured in a manner NOT to deal with > proprietary driver WiFi card, proprietary driver sound card, etc; > > 3) the guest kernel will be of the well tested older version with which > the proprietary driver WiFi card, proprietary driver sound card, etc. > did and do work, and this older guest kernel will take care of the > proprietary driver hardware; > > 4) interaction between the two kernels is as easy as between two > computers on network, i.e. the guest kernel can share its WiFi > connection with the main kernel, sound can be streamed to the guest kernel, > etc. > > As I said earlier, if I succeed in achieving this, this will be the > proof of possibility of absolutely stable ABI - the older guest kernel's > ABI will be the one. > It still seems like a lot less work to just make the kernel driver a thin layer over the hardware and put all the proprietary stuff in userspace. The kernel developers will guarantee that the API exported to userspace remains stable and maintain the kernel side of the driver so the vendor does not have to. The problem is some vendors insist that even the elementary information about their devices needed to write this thin HAL, like which register does what and how to enable interrupts, must be treated as a trade secret. Those vendors will eventually have to choose between this mindset and having their hardware supported. Lee --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tuesday 24 January 2006 03:22, Bill Unruh wrote: > > > btw, X11 was able to talk to hardware without any kernel-drivers. > > But it has to talk via the video card drivers which are kernel drivers I > would assume. > you may read up about Xfree86 3.6 and voodoo cards. There was no need for kernel modules. X is able to talk pretty direct to the card, everything else is about the correct opengl/mesa implementation. Kernel-modules are 'faster' but it is very possible to talk to the card's hardware without them. --- 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
Re: [Alsa-user] stable APIs and ABIs
Regarding " kernel developers made it clear that the days of them tolerating proprietary drivers are numbered. " I am sorry I do not have time at the moment to try XEN (I've already expressed this idea). The idea is: 1) in a user machine there will be at least two kernels running - the main one, which will also be the most up to date one, and the guest one; 2) the main kernel will be configured in a manner NOT to deal with proprietary driver WiFi card, proprietary driver sound card, etc; 3) the guest kernel will be of the well tested older version with which the proprietary driver WiFi card, proprietary driver sound card, etc. did and do work, and this older guest kernel will take care of the proprietary driver hardware; 4) interaction between the two kernels is as easy as between two computers on network, i.e. the guest kernel can share its WiFi connection with the main kernel, sound can be streamed to the guest kernel, etc. As I said earlier, if I succeed in achieving this, this will be the proof of possibility of absolutely stable ABI - the older guest kernel's ABI will be the one. On Mon, 23 Jan 2006 21:11:25 -0500 Lee Revell <[EMAIL PROTECTED]> wrote: > On Tue, 2006-01-24 at 03:03 +0100, Hemmann, Volker Armin wrote: > > btw, where are suddenly all this 'we need a fix binary abi' people are > > coming > > from? > > > > Until ca 2 month ago they never spoke up, and suddenly in every forum > > or mailing lists are popping up people, most of them posting for the > > first time, demanding a fix ABI. > > It seems to have coincided with the "Linux in a binary world (a doomsday > scenario)" thread on LKML around the same time, when some kernel > developers made it clear that the days of them tolerating proprietary > drivers are numbered. Many people seem to be afraid they will lose > support for their favorite binary-driver hardware, and are trying to put > pressure on the kernel community, rather than on the vendors where it > belongs. > > Lee > > > > --- > 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 > --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 24 Jan 2006, Hemmann, Volker Armin wrote: On Tuesday 24 January 2006 02:43, Bill Unruh wrote: On Tue, 24 Jan 2006, Hemmann, Volker Armin wrote: On Tuesday 24 January 2006 02:15, Sergei Steshenko wrote: " The Linux developers DO NOT WANT to make it possible to write closed source drivers. Many consider it a violation of the GPL. " - GPL allows to run commercial closed source programs under a GPL'ed OS. That is, it doesn't prohibit this. no, but it prohibits you from incorporating gpl'ed code into closed source programms. ... Likewise, closed source drivers can be implemented as separate processes not linked to GPL kernel an thus not violating GPL. so why has no one done it so far? The userland ABI and API has been stable the last ten years. You can take a binary, compiled on a computer using kernel 2.0.X and run it on 2.6.X You may need some glibc-wrapper, but that is not the kernels fault. So if you want to implement a driver that is completly independent from the kernel, lives in userspace, does not use GPL code in any form and is closed source, do it. Noone will hinder you in doing that. But if you are using GPL-code, you have to open it. ??? Noone is talking about a driver using GPL code. The question is how one can have drivers which talk directly to the hardware and link into the kernel. The code inside the driver need not use any GPL code. oh, and suddenly you want to link into the kernel? Again the code inside the driver module need not use any GPL code. Do we agree on that? I thought, we were talking about userspace? No, I am talking about a module. What is it about the relation of the module to the kernel that you call that "linking" while the relation of "userspace" program which also interacts with the kernel is not "linking" And what is it about the "linking" that makes it not OK wrt the GPL. btw, X11 was able to talk to hardware without any kernel-drivers. But it has to talk via the video card drivers which are kernel drivers I would assume. the sense of reality says them, that it is stupid to have fix internal api&abis, because they get into the way of efficient bug fixing and development. They also introduce bugs. and they fix them. Different ones. Every piece of software has bugs. That is not a license for bad design. "Oh well, bugs will always be with us, so we do not need to do anything to make them rarer." Some yoears ago, there was a nice article in Scientific America, about bugs in software. They used a mathematical proof to show, that it is not possible to write bugfree non-trivial software. And because of bugs, it is important to fix them. And to design things so that bugs occur less frequently. Fixing bugs should always play a distant second to proper design to make bugs unlikely. What do you do, when you find a bug in the 'holy' internal abi, that should not change? Add one wrapper after the other? I agree. That is a problem. But usually it is not the abi spec that is the bug, but some implimentation. There is a tradeoff. But as someone ignorant of driver development, surely it is possible to design the system so that one both has stability and flexibility. You can see the unholy mess of drivers, when you try and install windows. I am glad, that linux is much more userfriendly. New graphic-card? I did not have to change anything or have to change one(!) line in xorg.conf. Ageed. you claim that the only way to accomplish this is to have an unstable API/ABI? New sound-card? make modules modules_install and modprobe the drivers. No reboot, nothing. New mainboard? The old kernel boots perfectly, but sadly I need a different network driver. No problem. Make the module, modprobe it. That is easy. Agreed that is a great feature of Linux. But surely the current method is not the only way of achieving this objective. It comes at the cost of OK,new kernel, oops, my driver no longer works. Load in the source code and config for the kernel, get the source for the driver, and recompile the module. What, you discovered you had to change one thing in the config of the kernel-- oh, go ahead and recompile all your modules. Why is it not possible to compile a module once for 2.6 kernels, and then forget about it. Update the kernel? fine, just reuse the same module. --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 2006-01-24 at 03:03 +0100, Hemmann, Volker Armin wrote: > Newsflash: the userland abi&api is fix. There is nothing to whine > about. > Yes. No one is trying to tell Nvidia & co "you must open your libGL implementation if you want your hardware supported". The way forward is, as Arjan van de Ven said on LKML, to "put their hot IP in userspace". Look at alsa-lib/alsa-driver for an example - the drivers only need to implement the minimum functionality to talk to the hardware, and most of the work is done by alsa-lib. Nvidia could do the same, they just need to ship an open source kernel component for their driver that allows their proprietary userspace libGL implementation to talk to the hardware. Lee --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 2006-01-24 at 03:03 +0100, Hemmann, Volker Armin wrote: > btw, where are suddenly all this 'we need a fix binary abi' people are > coming > from? > > Until ca 2 month ago they never spoke up, and suddenly in every forum > or mailing lists are popping up people, most of them posting for the > first time, demanding a fix ABI. It seems to have coincided with the "Linux in a binary world (a doomsday scenario)" thread on LKML around the same time, when some kernel developers made it clear that the days of them tolerating proprietary drivers are numbered. Many people seem to be afraid they will lose support for their favorite binary-driver hardware, and are trying to put pressure on the kernel community, rather than on the vendors where it belongs. Lee --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tuesday 24 January 2006 02:52, Bill Unruh wrote: > On Mon, 23 Jan 2006, Lee Revell wrote: > > On Mon, 2006-01-23 at 17:34 -0800, Bill Unruh wrote: > >> Well, I also think that is a mistake. A Write once would also be far > >> more > >> stable as far as Linux itself is concerned. If every time the kernel > >> changes you have to worry whether or not your driver is broken, it > >> makes > >> for highly unstable drivers, even if they are open source. > >> Furthermore, > >> Linux is a tool for most of us, not a religion. > > > > It's not religion, it's the law. Drivers are part of the kernel so must > > Law? What law? No where in copyright law, which is the only law which > might apply is there anything about drivers or kernels. > And your statement was "Linux developers do not want to allow closed source > drivers" The wants of Linux developers are not law. no, but copyright law is all about licences. Read the licence. Read it again. If you do not understand it (and I have the feeling you do not understand copyright and licences) ask a lawyer to explain it to you. GPL software is under a licence with few but strict requirements. You have to follow them, or you are just as criminal, as the boys&girls downloading windows XP over bittorrent. btw, where are suddenly all this 'we need a fix binary abi' people are coming from? Until ca 2 month ago they never spoke up, and suddenly in every forum or mailing lists are popping up people, most of them posting for the first time, demanding a fix ABI. Newsflash: the userland abi&api is fix. There is nothing to whine about. --- 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
Re: [Alsa-user] stable APIs and ABIs
On Mon, 2006-01-23 at 17:52 -0800, Bill Unruh wrote: > On Mon, 23 Jan 2006, Lee Revell wrote: > > > On Mon, 2006-01-23 at 17:34 -0800, Bill Unruh wrote: > >> Well, I also think that is a mistake. A Write once would also be far > >> more > >> stable as far as Linux itself is concerned. If every time the kernel > >> changes you have to worry whether or not your driver is broken, it > >> makes > >> for highly unstable drivers, even if they are open source. > >> Furthermore, > >> Linux is a tool for most of us, not a religion. > > > > It's not religion, it's the law. Drivers are part of the kernel so must > > Law? What law? No where in copyright law, which is the only law which > might apply is there anything about drivers or kernels. > And your statement was "Linux developers do not want to allow closed source > drivers" The wants of Linux developers are not law. > As the kernel developers hold the copyright, their wants as expressed by the GPL do carry the force of law. > Drivers are part of the kernel-- in what sense. They are separate programs, > which the kernel interacts with. How would they be > different in userspace? What exactly makes them "part of the kernel" that a > userspace program would not be? > The kernel does not depend on them. Most are modules which the kernel can > take or leave. > > > be GPL. If you want closed source drivers they must not be part of the > > kernel, they have to run in userspace. > > Why? > A Linux kernel driver must use the kernel module API to interface with the kernel, and those APIs consist of GPL code. > > > > Lee > > > --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tuesday 24 January 2006 02:43, Bill Unruh wrote: > On Tue, 24 Jan 2006, Hemmann, Volker Armin wrote: > > On Tuesday 24 January 2006 02:15, Sergei Steshenko wrote: > >> " > >> The Linux developers DO NOT WANT to make it possible to write closed > >> source drivers. Many consider it a violation of the GPL. > >> " > >> > >> - GPL allows to run commercial closed source programs under a > >> GPL'ed OS. That is, it doesn't prohibit this. > > > > no, but it prohibits you from incorporating gpl'ed code into closed > > source programms. > > ... > > >> Likewise, closed source drivers can be implemented as separate > >> processes not linked to GPL kernel an thus not violating GPL. > > > > so why has no one done it so far? > > > > The userland ABI and API has been stable the last ten years. > > > > You can take a binary, compiled on a computer using kernel 2.0.X and run > > it on 2.6.X > > > > You may need some glibc-wrapper, but that is not the kernels fault. > > > > So if you want to implement a driver that is completly independent from > > the kernel, lives in userspace, does not use GPL code in any form and is > > closed source, do it. Noone will hinder you in doing that. > > But if you are using GPL-code, you have to open it. > > ??? Noone is talking about a driver using GPL code. The question is how one > can have drivers which talk directly to the hardware and link into the > kernel. The code inside the driver need not use any GPL code. oh, and suddenly you want to link into the kernel? I thought, we were talking about userspace? btw, X11 was able to talk to hardware without any kernel-drivers. > > > the sense of reality says them, that it is stupid to have fix internal > > api&abis, because they get into the way of efficient bug fixing and > > development. > > They also introduce bugs. and they fix them. Every piece of software has bugs. Some yoears ago, there was a nice article in Scientific America, about bugs in software. They used a mathematical proof to show, that it is not possible to write bugfree non-trivial software. And because of bugs, it is important to fix them. What do you do, when you find a bug in the 'holy' internal abi, that should not change? Add one wrapper after the other? You can see the unholy mess of drivers, when you try and install windows. You HAVE to install the mainboard driver first - and please, be sure that not one driver of the previous hardware is left - best to do is reinstallation, than you have to install the rest of the drivers in a certain sequence or you can start again. I surf enough forums, where I can see the daily carnage. Where computers are totally unusable, because the user forgot to deinstall some driver before removing the hardware, or did use the wrong driver (windows own driver instead the one from the vendors homepage), or just did not installed the drivers in the right order. I am glad, that linux is much more userfriendly. New graphic-card? I did not have to change anything or have to change one(!) line in xorg.conf. New sound-card? make modules modules_install and modprobe the drivers. No reboot, nothing. New mainboard? The old kernel boots perfectly, but sadly I need a different network driver. No problem. Make the module, modprobe it. That is easy. --- 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
Re: [Alsa-user] stable APIs and ABIs
On Mon, 23 Jan 2006, Lee Revell wrote: On Mon, 2006-01-23 at 17:34 -0800, Bill Unruh wrote: Well, I also think that is a mistake. A Write once would also be far more stable as far as Linux itself is concerned. If every time the kernel changes you have to worry whether or not your driver is broken, it makes for highly unstable drivers, even if they are open source. Furthermore, Linux is a tool for most of us, not a religion. It's not religion, it's the law. Drivers are part of the kernel so must Law? What law? No where in copyright law, which is the only law which might apply is there anything about drivers or kernels. And your statement was "Linux developers do not want to allow closed source drivers" The wants of Linux developers are not law. Drivers are part of the kernel-- in what sense. They are separate programs, which the kernel interacts with. How would they be different in userspace? What exactly makes them "part of the kernel" that a userspace program would not be? The kernel does not depend on them. Most are modules which the kernel can take or leave. be GPL. If you want closed source drivers they must not be part of the kernel, they have to run in userspace. Why? Lee -- William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273 Physics&Astronomy | Advanced Research | Fax: +1(604)822-5324 UBC, Vancouver,BC | Program in Cosmology | [EMAIL PROTECTED] Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/ --- 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
Re: [Alsa-user] stable APIs and ABIs
Probably the sysadmin was right - http://search.synopsys.com/search?q=linux+kernel+version&spell=1&site=www&output=xml_no_dtd&client=www&access=p&proxystylesheet=www shows mostly 2.4.* kernels. I didn't read every link, but that's what I see at first glance. Only in 2005 SYNOPSYS announced support of SUSE Linux, so maybe with that support of 2.6.* comes along. On Mon, 23 Jan 2006 20:37:01 -0500 Lee Revell <[EMAIL PROTECTED]> wrote: > On Tue, 2006-01-24 at 03:33 +0200, Sergei Steshenko wrote: > > The programs are userspace. > > > > The argument of 2.4.* <-> 2.6.* was given by a sysadmin, I do not > > know to which extent the sysadmin was competent. > > > > However, he said it was the cause of not upgrading company > > RHEL-servers to 2.6.* kernel. > > Well, it sounds like he's just obeying the Sysadmin Prime Directive: if > it ain't broke, don't fix it. > > Lee > > > > --- > 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 > --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 24 Jan 2006, Hemmann, Volker Armin wrote: On Tuesday 24 January 2006 02:15, Sergei Steshenko wrote: " The Linux developers DO NOT WANT to make it possible to write closed source drivers. Many consider it a violation of the GPL. " - GPL allows to run commercial closed source programs under a GPL'ed OS. That is, it doesn't prohibit this. no, but it prohibits you from incorporating gpl'ed code into closed source programms. ... Likewise, closed source drivers can be implemented as separate processes not linked to GPL kernel an thus not violating GPL. so why has no one done it so far? The userland ABI and API has been stable the last ten years. You can take a binary, compiled on a computer using kernel 2.0.X and run it on 2.6.X You may need some glibc-wrapper, but that is not the kernels fault. So if you want to implement a driver that is completly independent from the kernel, lives in userspace, does not use GPL code in any form and is closed source, do it. Noone will hinder you in doing that. But if you are using GPL-code, you have to open it. ??? Noone is talking about a driver using GPL code. The question is how one can have drivers which talk directly to the hardware and link into the kernel. The code inside the driver need not use any GPL code. the sense of reality says them, that it is stupid to have fix internal api&abis, because they get into the way of efficient bug fixing and development. They also introduce bugs. --- 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
Re: [Alsa-user] stable APIs and ABIs
On Mon, 2006-01-23 at 17:34 -0800, Bill Unruh wrote: > Well, I also think that is a mistake. A Write once would also be far > more > stable as far as Linux itself is concerned. If every time the kernel > changes you have to worry whether or not your driver is broken, it > makes > for highly unstable drivers, even if they are open source. > Furthermore, > Linux is a tool for most of us, not a religion. It's not religion, it's the law. Drivers are part of the kernel so must be GPL. If you want closed source drivers they must not be part of the kernel, they have to run in userspace. Lee --- 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
Re: [Alsa-user] stable APIs and ABIs
On Mon, 2006-01-23 at 17:34 -0800, Bill Unruh wrote: > > > > He is also incorrect about wireless, there are plenty of wireless > > chipsets with open drivers. > > Then why all the closed source firmware? I also recall reading that > the FCC > demanded closed source setting of the frequencies to prevent > inappropriate > frequency use. Of course I could not find the reference now. > Closed source firmware is fine, as it does not link with the GPL'ed code - it does not even run on the same CPU. Lee --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 2006-01-24 at 03:33 +0200, Sergei Steshenko wrote: > The programs are userspace. > > The argument of 2.4.* <-> 2.6.* was given by a sysadmin, I do not > know to which extent the sysadmin was competent. > > However, he said it was the cause of not upgrading company > RHEL-servers to 2.6.* kernel. Well, it sounds like he's just obeying the Sysadmin Prime Directive: if it ain't broke, don't fix it. Lee --- 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
Re: [Alsa-user] stable APIs and ABIs
On Mon, 23 Jan 2006, Lee Revell wrote: On Tue, 2006-01-24 at 02:59 +0200, Sergei Steshenko wrote: We have already discussed this, here's yet another opinion: http://ask.slashdot.org/article.pl?sid=06/01/23/214258 -> " This is why we need a kernel api and abi We need a consistant and stable abi's and api's for linux so hardware makers can release the drivers for linux. Also old solaris drivers work just fine under solaris10 because of consistant api's and abi's. I know VIA and several manufactors have requesting to Morton and Linus for this feature even though it divides then linux community. ". The Linux developers DO NOT WANT to make it possible to write closed source drivers. Many consider it a violation of the GPL. Well, I also think that is a mistake. A Write once would also be far more stable as far as Linux itself is concerned. If every time the kernel changes you have to worry whether or not your driver is broken, it makes for highly unstable drivers, even if they are open source. Furthermore, Linux is a tool for most of us, not a religion. Probably the worst violator of the GPL now adays is Redhat (see their enterprize license and their use of trademarks to limit copying). But I do not see the developers going after them. He is also incorrect about wireless, there are plenty of wireless chipsets with open drivers. Then why all the closed source firmware? I also recall reading that the FCC demanded closed source setting of the frequencies to prevent inappropriate frequency use. Of course I could not find the reference now. --- 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
Re: [Alsa-user] stable APIs and ABIs
The programs are userspace. The argument of 2.4.* <-> 2.6.* was given by a sysadmin, I do not know to which extent the sysadmin was competent. However, he said it was the cause of not upgrading company RHEL-servers to 2.6.* kernel. On Mon, 23 Jan 2006 20:25:08 -0500 Lee Revell <[EMAIL PROTECTED]> wrote: > On Tue, 2006-01-24 at 03:15 +0200, Sergei Steshenko wrote: > > SYNOPSYS and Cadence VLSI-related tools are a few examples, though, > > as far as SYNOPSYS is concerned, only 2.4.* (and NOT 2.6.*) kernels > > are supported because the former are considered to have stable API. > > The API exported to userspace via system calls IS stable. It's only the > internal kernel module API that's not stable. > > Aren't these userspace programs? If so they do not need to worry about > the kernel version. From the userspace POV 2.6 is binary compatible > with 2.4. > > Lee > --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tuesday 24 January 2006 02:15, Sergei Steshenko wrote: > " > The Linux developers DO NOT WANT to make it possible to write closed > source drivers. Many consider it a violation of the GPL. > " > > - GPL allows to run commercial closed source programs under a > GPL'ed OS. That is, it doesn't prohibit this. no, but it prohibits you from incorporating gpl'ed code into closed source programms. > > SYNOPSYS and Cadence VLSI-related tools are a few examples, though, > as far as SYNOPSYS is concerned, only 2.4.* (and NOT 2.6.*) kernels > are supported because the former are considered to have stable API. the userland API is stable, please inform yourself. > > Likewise, closed source drivers can be implemented as separate > processes not linked to GPL kernel an thus not violating GPL. > so why has no one done it so far? The userland ABI and API has been stable the last ten years. You can take a binary, compiled on a computer using kernel 2.0.X and run it on 2.6.X You may need some glibc-wrapper, but that is not the kernels fault. So if you want to implement a driver that is completly independent from the kernel, lives in userspace, does not use GPL code in any form and is closed source, do it. Noone will hinder you in doing that. But if you are using GPL-code, you have to open it. Easy, isn't it? If you write code for Windows, you have to obey to their license too. So where is your problem? I tell you: there is no problem, you only want to troll. > ... > > With all the fuss, why don't the same developers demand IDE drives > firmware to become open ? CD/DVD ROM firmware to become open ? firmwares are not drivers. Firmwares are an entity of their own. Please inform yourself about firmwares and what they do and where they live and compare them to drivers. And there are many firmware hacks or open firmwares if you use a search engine of your choice. > > That is, where does the developers' sense of reality begin and where > does it end ? the sense of reality says them, that it is stupid to have fix internal api&abis, because they get into the way of efficient bug fixing and development. Stop trolling, start reading&thinking, thank you. --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 2006-01-24 at 03:15 +0200, Sergei Steshenko wrote: > SYNOPSYS and Cadence VLSI-related tools are a few examples, though, > as far as SYNOPSYS is concerned, only 2.4.* (and NOT 2.6.*) kernels > are supported because the former are considered to have stable API. The API exported to userspace via system calls IS stable. It's only the internal kernel module API that's not stable. Aren't these userspace programs? If so they do not need to worry about the kernel version. From the userspace POV 2.6 is binary compatible with 2.4. Lee --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 2006-01-24 at 03:15 +0200, Sergei Steshenko wrote: > " > The Linux developers DO NOT WANT to make it possible to write closed > source drivers. Many consider it a violation of the GPL. > " > > - GPL allows to run commercial closed source programs under a > GPL'ed OS. That is, it doesn't prohibit this. > > SYNOPSYS and Cadence VLSI-related tools are a few examples, though, > as far as SYNOPSYS is concerned, only 2.4.* (and NOT 2.6.*) kernels > are supported because the former are considered to have stable API. > > Likewise, closed source drivers can be implemented as separate > processes not linked to GPL kernel an thus not violating GPL. > If Linux allowed drivers to be implemented in userspace you would be correct, but currently drivers must be linked into the kernel so the GPL applies to all driver code. In fact the solution that the kernel developers have proposed is to develop the infrastructure to run drivers in userspace so that Nvidia for example can keep the sensitive IP in their driver private and comply with the GPL. So basically it's a technical problem not a political one. Some work has been done on a userspace driver infrastructure but it's not usable yet. Lee --- 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
Re: [Alsa-user] stable APIs and ABIs
" The Linux developers DO NOT WANT to make it possible to write closed source drivers. Many consider it a violation of the GPL. " - GPL allows to run commercial closed source programs under a GPL'ed OS. That is, it doesn't prohibit this. SYNOPSYS and Cadence VLSI-related tools are a few examples, though, as far as SYNOPSYS is concerned, only 2.4.* (and NOT 2.6.*) kernels are supported because the former are considered to have stable API. Likewise, closed source drivers can be implemented as separate processes not linked to GPL kernel an thus not violating GPL. ... With all the fuss, why don't the same developers demand IDE drives firmware to become open ? CD/DVD ROM firmware to become open ? That is, where does the developers' sense of reality begin and where does it end ? On Mon, 23 Jan 2006 20:04:14 -0500 Lee Revell <[EMAIL PROTECTED]> wrote: > On Tue, 2006-01-24 at 02:59 +0200, Sergei Steshenko wrote: > > We have already discussed this, here's yet another opinion: > > > > http://ask.slashdot.org/article.pl?sid=06/01/23/214258 -> > > > > " > > This is why we need a kernel api and abi > > (Score:2) > > by Billly Gates (198444) Alter Relationship on Tuesday January 24, @02:03AM > > (#14544582) > > (http://www.livejournal.com/users/sinistertim101 | Last Journal: Thursday > > December 22, @08:27PM) > > Flamebait all you want from the moderators reading this belonging to the > > pure gnu persusian but writing closed source drivers are tough for linux. > > > > Blame the manufactors? Its the FCC that forces them to not give out details > > to hackers. Many other governments have similiar regulations on what > > hackers can and can not do to wireless. The government doesn't want people > > takign down airplanes are terrorists doing espianage on communication > > equipment. > > > > So they must stay closed source if they are an American company. Many > > manufactors are now using software and creating win-wlan cards to save > > money. Remember what happened to linux after modem makers only made > > software modems? Samething with winprinters that make up the majority of > > printers today. > > > > Under windows you write once and most likely the drivers will work with > > future versions of windows unless there is a major upgrade. That is because > > of NDIS and kernel and software level api's and device driver kits for > > windows. > > > > We need a consistant and stable abi's and api's for linux so hardware > > makers can release the drivers for linux. Also old solaris drivers work > > just fine under solaris10 because of consistant api's and abi's. > > > > I know VIA and several manufactors have requesting to Morton and Linus for > > this feature even though it divides then linux community. > > ". > > The Linux developers DO NOT WANT to make it possible to write closed > source drivers. Many consider it a violation of the GPL. > > He is also incorrect about wireless, there are plenty of wireless > chipsets with open drivers. > > Lee > > > > --- > 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 > --- 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
Re: [Alsa-user] stable APIs and ABIs
On Tue, 2006-01-24 at 02:59 +0200, Sergei Steshenko wrote: > We have already discussed this, here's yet another opinion: > > http://ask.slashdot.org/article.pl?sid=06/01/23/214258 -> > > " > This is why we need a kernel api and abi > (Score:2) > by Billly Gates (198444) Alter Relationship on Tuesday January 24, @02:03AM > (#14544582) > (http://www.livejournal.com/users/sinistertim101 | Last Journal: Thursday > December 22, @08:27PM) > Flamebait all you want from the moderators reading this belonging to the pure > gnu persusian but writing closed source drivers are tough for linux. > > Blame the manufactors? Its the FCC that forces them to not give out details > to hackers. Many other governments have similiar regulations on what hackers > can and can not do to wireless. The government doesn't want people takign > down airplanes are terrorists doing espianage on communication equipment. > > So they must stay closed source if they are an American company. Many > manufactors are now using software and creating win-wlan cards to save money. > Remember what happened to linux after modem makers only made software modems? > Samething with winprinters that make up the majority of printers today. > > Under windows you write once and most likely the drivers will work with > future versions of windows unless there is a major upgrade. That is because > of NDIS and kernel and software level api's and device driver kits for > windows. > > We need a consistant and stable abi's and api's for linux so hardware makers > can release the drivers for linux. Also old solaris drivers work just fine > under solaris10 because of consistant api's and abi's. > > I know VIA and several manufactors have requesting to Morton and Linus for > this feature even though it divides then linux community. > ". The Linux developers DO NOT WANT to make it possible to write closed source drivers. Many consider it a violation of the GPL. He is also incorrect about wireless, there are plenty of wireless chipsets with open drivers. Lee --- 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
