[LWN Logo]

Date:	Wed, 11 Nov 1998 09:28:18 -0800
From:	David Hinds <dhinds@zen.stanford.edu>
To:	Jes Sorensen <Jes.Sorensen@cern.ch>
Subject: Re: pre*-6 breaks PCMCIA again

On Wed, Nov 11, 1998 at 09:35:28AM +0100, Jes Sorensen wrote:
> 
> Whats the problem, it is supposedly GPL anyway!  Except for the fact
> that it is good behavior to credit someone for it there shouldn't be
> any problem with it. Afaik the apne driver supports a subset because
> the PCMCIA port in the Amiga 600+1200 is not fully PCMCIA 2 compliant
> on the hardware level and not all cards will work.

I'm not seriously complaining in this instance.  However, my code is
*not* GPL, and never has been.  It has *always* been under a license
that required that attributions be retained.

> David> As for other architectures, my PCMCIA package is already being
> David> used on the alpha and powerpc platforms.
> 
> Still doesn't change the fact that it is a pain for someone making a
> modification to the kernel which affects all/other subsystems to get
> everything done right. I don't want to apply a large PCMCIA patch on
> top of my CVS tree if I cannot send it all off to Linus when I am
> finished fixing all the bugs.

Part of my problem is that people making modifications that affect all
subsystems, rarely ever do so in a way that is consistent with the
goals of the PCMCIA package (which include backward compatibility
across kernel versions).  As it stands, when people send me patches
for kernel changes, I usually need to tweak them to achieve this.
This supports both my points: in the current scheme, there are already
quite a few people who can and do work on the Linux PCMCIA source tree
and propagate kernel tree changes, however, my role as patch-filter is
clearly required based on the patches I get.

Another argument is that the Linux PCMCIA package is now multi
platform (it is also the BeOS PCMCIA package, and has been ported to
HPUX, and may be ported to Solaris).  Inclusion in the kernel tree
risks forking a Linux-specific version.

> but PCMCIA is
> bus and parts of the drivers in the current kernel will need to know
> about it.

I think facts have proved otherwise.  Can you give an example of
functionality that could be achieved by integration into the kernel
source tree, that is currently not available?

In the long run, as Linux matures, I think the model of putting all
drivers in the kernel is going to have to change one way or another.
It is only apparently-feasible at the moment because Linux doesn't
have all that many drivers.  The driver subtree has roughly doubled in
going from 2.0.* to 2.1.*.  I'd expect that trend to continue.  What
do we do when vendors start taking a serious interest and start
writing drivers?  (I've heard rumors that a number of major vendors
are now committed to developing Linux drivers)

-- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/