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/