RE: releasing driver to kernel in source+binary format

RE: releasing driver to kernel in source+binary format

[MEHTA,HIREN (A-SanJose,ex1)]

Well, Qlogic also has their firmware released in binary format.

Any comment on that ?

-hiren

-----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

Re: releasing driver to kernel in source+binary format

[Alan Cox]

> Well, Qlogic also has their firmware released in binary format.

Firmware that runs on the processor in the card is somewhat of a different
item. If its just a binary firmware image to load into the card and that
is run by the card I dont think its an issue.

If its code run on the host processor then there is an issue.

A good rule of thumb test for that is "could you write a seperate program
that loaded the firmware and wasnt part of the kernel". 


Alan

Re: releasing driver to kernel in source+binary format

[Jes Sorensen]

>>>>> "Alan" == Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

>> Well, Qlogic also has their firmware released in binary format.
Alan> Firmware that runs on the processor in the card is somewhat of a
Alan> different item. If its just a binary firmware image to load into
Alan> the card and that is run by the card I dont think its an issue.

Alan> If its code run on the host processor then there is an issue.

One might even want to add that opening up firmware has some positive
side effects: Look at how Alteon completely ruled the Gigabit Ethernet
world with their NIC and open firmware programme (until they decided
to bug out before the big players started picking up and squeezing
them out on price).

Jes

Re: releasing driver to kernel in source+binary format

[Matti Aarnio]

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

releasing driver to kernel in source+binary format

[MEHTA,HIREN (A-SanJose,ex1)]

Hi list,

We want to release a linux scsi hba-driver for our fibre-channel
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. 

I went through the "SubmittingDrivers" file
which does not talk about this kind of special cases.

Regards,
-hiren
Agilent Technologies.

Re: releasing driver to kernel in source+binary format

[Alan Cox]

> 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

Re: releasing driver to kernel in source+binary format

[Ignacio Vazquez-Abrams]

On Thu, 23 Aug 2001, MEHTA,HIREN (A-SanJose,ex1) wrote:

> Hi list,
>
> We want to release a linux scsi hba-driver for our fibre-channel
> 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.
>
> I went through the "SubmittingDrivers" file
> which does not talk about this kind of special cases.
>
> Regards,
> -hiren
> Agilent Technologies.

It's probably just easier to supply a non-GPLed binary-only driver. Realize,
though, that if you have any sort of binary-only driver in any way, there are
those who will a) refuse to buy or use your product(s), and b) persuade others
to do the same.

-- 
Ignacio Vazquez-Abrams  <ignacio@openservices.net>

Re: releasing driver to kernel in source+binary format

[Disconnect]

On Thu, 23 Aug 2001, Ignacio Vazquez-Abrams did have cause to say:

> 
> It's probably just easier to supply a non-GPLed binary-only driver. Realize,
> though, that if you have any sort of binary-only driver in any way, there are
> those who will a) refuse to buy or use your product(s), and b) persuade others
> to do the same.

And don't forget c) every single bug or problem report about any machine
with that driver will get sent to you - none of the developers and very
few of the others (especially on LKML) will touch it if the problem occurs
while that driver is loaded.

(For references, check the mail archives for issues from people w/ nvidia
cards - you'll see the occasional help request, followed by quite a lot of
"go talk to nvidia about it, its a binary driver so we can't help"...)

---
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C++++$ ULBS*++++$ P- L+++>+++++ 
E--- W+++ N+@ o+>$ K? w--->+++++ O- M V-- PS+() PE Y+@ PGP++() t
5--- X-- R tv+@ b++++>$ DI++++ D++(+++) G++ e* h(-)* r++ y++
------END GEEK CODE BLOCK------

Re: releasing driver to kernel in source+binary format

[Steve Underwood]

"MEHTA,HIREN (A-SanJose,ex1)" wrote:
> 
> Hi list,
> 
> We want to release a linux scsi hba-driver for our fibre-channel
> 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.
> 
> I went through the "SubmittingDrivers" file
> which does not talk about this kind of special cases.

I for one would not buy such a thing, for the most practical of reasons.
Open source advocates are often seem as idealists. In general they are
the most pragmatic of people.

In the past year 90% of my serious problems have come from three pieces
of software - 2 text to speech packages, and Dialogic's driver from
Linux. These are the only three "binary only" things I have used, and I
am powerless to fix any of the issues causing me grief. My experience is
not unique - its commonplace.

If there is an open source alternative I think most serious Linux users
will choose that over any closed option. The closed option seldom has
enough advantage to overcome the severe risk inherent in an option that
means trusting someone who does not have your best interests at heart.
If you make your driver completely open source, we would still have to
trust your hardware. Experience says that isn't such a big problem. Few
pieces of computer hardware, which actually reach the market, have
proven so bad that the problems cannot be worked around (perhaps with a
little performance loss) in software. Closed hardware doesn't scare
seasoned users like closed software.

That said.... If your closed code actually consists of something
dwownloaded to the card, you may still be able to supply a GPL kernel
bit, and a binary only downloaded bit. If you want an integral part of
your host driver code to be binary only, you can't do that.

Regards,
Steve