From alsa-devel-owner@alsa.jcu.cz  Mon Mar  1 02:34:17 1999
Received: from neutrino.kek.jp (root@neutrino.kek.jp [130.87.218.139])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id CAA27266
	for <alsa-devel@alsa.jcu.cz>; Mon, 1 Mar 1999 02:32:45 +0100
Received: from lbscissors.kek.jp (root@lbscissors.kek.jp [130.87.218.173]) by neutrino.kek.jp (8.8.8+2.7Wbeta7/3.4W3) with ESMTP id KAA13773; Mon, 1 Mar 1999 10:32:23 +0900
Received: from lbscissors.kek.jp (really [127.0.0.1]) by neutrino.kek.jp
	via in.smtpd with esmtp (ident sharkey using rfc1413)
	id <m10HHZG-000sLNC@lbscissors.kek.jp> (Debian Smail3.2.0.102)
	for <alsa-devel@alsa.jcu.cz>; Mon, 1 Mar 1999 10:32:22 +0900 (JST) 
Message-Id: <m10HHZG-000sLNC@lbscissors.kek.jp>
To: alsa-devel@alsa.jcu.cz
Cc: kduffey@inprise.com
From: sharkey@ale.physics.sunysb.edu
Subject: Re: (SB Live) Free drivers or not? (fwd) 
In-reply-to: Your message of "Sun, 28 Feb 1999 14:04:02 PST."
             <3.0.32.19990228140401.0095b8f0@mail.inprise.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 01 Mar 1999 10:32:22 +0900
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

I know much of this has already been answered, but let me stress a few points.

> Am I to understand you correctly that at any time Linux can suddenly change
> the kernel to a point that current libraries ( I assume these are like .DLL
> files in MS Windows..Dynamic Linking Libraries..loaded by an app at
> run-time, instead of compile time..is this correct? .o is their name?) will
> no longer work at all?

Not libraries, just modules.  .DLL files correspond to .so (shared object)
files on Unix systems.  They shouldn't have any problems.  But most sound
drivers are compiled as .o (object) files which are inserted directly into
the kernel and use kernel-space functions.

Here is what Linus has recently said [edited for brevity]:

  To:     linux-kernel@vger.rutgers.edu
  From:   torvalds@transmeta.com (Linus Torvalds)
  Subject: Re: Kernel interface changes (was Re: cdrecord problems on
  Date:   7 Feb 1999 08:15:24 GMT

  I _refuse_ to even consider tying my hands over some binary-only module.

  I _want_ people to expect that interfaces change. I _want_ people to
  know that binary-only modules cannot be used from release to release.
  I want people to be really really REALLY aware of the fact that when
  they use a binary-only module, they tie their hands. 

  Basically, I want people to know that when they use binary-only modules,
  it's THEIR problem.  I want people to know that in their bones, and I
  want it shouted out from the rooftops.  I want people to wake up in a
  cold sweat every once in a while if they use binary-only modules. 

  Why? Because I'm a prick, and I want people to suffer? No.

  Because I _know_ that I will eventually make changes that break modules. 
  And I want people to expect them, and I never EVER want to see an email
  in my mailbox that says "Damn you, Linus, I used this binary module for
  over two years, and it worked perfectly across 150 kernel releases, and
  Linux-5.6.71 broke it, and you had better fix your kernel". 

  See?

  I refuse to be at the mercy of any binary-only module.  And that's why I
  refuse to care about them - not because of any really technical reasons,
  not because I'm a callous bastard, but because I refuse to tie my hands
  behind my back and hear somebody say "Bend Over, Boy, Because You Have
  It Coming To You". 

  I allow binary-only modules, but I want people to know that they are
  _only_ ever expected to work on the one version of the kernel that they
  were compiled for. Anything else is just a very nice unexpected bonus if
  it happens to work.

  And THAT, my friend, is why when somebody complains about AFS, I tell
  them to go screw themselves, and not come complaining to me but complain
  to the AFS buys and girls.  And why I'm not very interested in changing
  that. 

                  Linus


> I am a bit worried about this because I plan to
> support the Linux community, but I am not giving my actual program away for
> free, or the source code.

That's a pity.  If you don't give away the source, you won't get bugfixes
or feature patches or anywhere near the level/quality of user feedback
you would otherwise.

If you want to support the entire Linux community with binaries of an app
that only resides in user-space, then you don't need to worry about changes
in the kernel internals, but you do have to worry about other things.

For example, some people will want versions linked against libc6, others
against libc5.  And you'll need a different binary for every architecture.
Try this:

ls -d /usr/src/linux/include/asm*

Are you planning on compiling binaries for all of these platforms, or are
you going to tell portions of the Linux community that they are not important
enough to be worth supporting?

Do you want to support other types of Unix?  FreeBSD?  Solaris?  The HURD?
BeOS?

When you release source, the potential audience is greatly expanded.  It's
a lot of work to compile binaries for everyone.  Porting code from one
Unix to another is frequently trivial.  (At least compared to Mac/Windows
porting).  You essentially get all that for free when you open the source.

Eric


