Re: releasing driver to kernel in source+binary format

[Matti Aarnio <matti.aarnio@zmailer.org>]

On Thu, Aug 23, 2001 at 12:43:05PM -0600, MEHTA,HIREN (A-SanJose,ex1) wrote:
> Well, Qlogic also has their firmware released in binary format.
> Any comment on that ?

	That firmware is something which is run by the card itself,
	and appears as series of services which plain source C code
	driver executed by the Linux kernel then uses.
	Linux writes/reads something at magic locations, sends and
	receives interrupts, all that fun.

	If the card firmware is binary, I don't see any real problems
	(aside of purity of 'all in source').  Properly written drivers
	can be compiled and RUN at any hardware where Linux runs,
	including future changes in driver infrastructure.
	(Interrupts, semaphores, ...)

	For Linux kernel there is a ABI to the card firmware.
	It might not be very well documented, or explained, but
	a ABI it is none the less.

	Linux runs on lots of different processors/architectures/systems.
	A PCI card should be workable at any of them.

	Consider i386 series, and ia64.  Linux kernel won't be running
	in i386 mode for drivers, for just one example from intel
	product lines.


	What we are seeing with one particular .o  driver in Linux
	kernel is that users who use it are having problems due to
	*SOMETHING*, but we (linux kernel hacker community) can't
	figure it out when the vendor is unable to fix it.

	In recent hardware purchase this particular driver problem
	detail guided me to choose different component for the system.


> -hiren

	/Matti Aarnio

> -----Original Message-----
> From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk]
> Sent: Thursday, August 23, 2001 11:14 AM
> To: hiren_mehta@agilent.com
> Cc: linux-kernel@vger.kernel.org; linux-scsi@vger.kernel.org
> Subject: Re: releasing driver to kernel in source+binary format
> 
> > HBAs and make it part of the kernel source tree. Because of IP 
> > related issues, we can only release one part of the sources with 
> > GPL. We want to release the other part in the binary format (.o)
> > as a library which needs to be linked with the first part.
> > If somebody can advise me on how to go about this, I would
> > appreciate it. 
> 
> Very simple. You can't link GPL and proprietary code together. You may be
> able to make your code a non free module distributed by yourselves if you
> can satisfy your lawyers that it is a seperate work. Take that one up with
> your lawyers. Also remember that the kernel code is GPL, so if you based
> your driver on existing GPL code (eg by copying an existing scsi drivers
> code as a basis) you will also have to sort that issue out too.
> 
> > I went through the "SubmittingDrivers" file
> > which does not talk about this kind of special cases.
> 
> Thats becase Linux is free software. We don't merge binary only drivers, and
> only maintain source level compatibility between different compiles of the
> kernel.
> 
> The whole Linux concept is geared around free software, that means source
> code, source level compatibility, the ability for people to recompile and
> for sane debugging because we have all the sources.
> 
> Alan
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html