PCI NVRAM Memory Card

PCI NVRAM Memory Card

[Mike Jadon]

My company has released a PCI NVRAM memory card but we haven't developed a 
Linux driver for it yet.  We want the driver to be open to developers to 
build upon.  Is there a specific path we should follow with this being our 
goal?  In researching Linux driver development I have come across "GPL" or 
"LGPL".  Where do you recommend we go to find out more about this 
development process?

Thanks and my apologies for using a technical forum for this question, but 
wanted to go to the right source.


Mike



Mike Jadon
Micro Memory, Inc.
(US) Tel 818 998 0070 x 318
(US) Fax 818 998 4459
mikej@umem.com
www.umem.com
9540 Vassar
Chatsworth, Ca.
USA 91311 

Re: PCI NVRAM Memory Card

[Ignacio Vazquez-Abrams]

On Wed, 8 Aug 2001, Mike Jadon wrote:

> My company has released a PCI NVRAM memory card but we haven't developed a
> Linux driver for it yet.  We want the driver to be open to developers to
> build upon.  Is there a specific path we should follow with this being our
> goal?  In researching Linux driver development I have come across "GPL" or
> "LGPL".  Where do you recommend we go to find out more about this
> development process?
>
> Thanks and my apologies for using a technical forum for this question, but
> wanted to go to the right source.
>
>
> Mike

Real simple.

Anything that goes into the kernel should be GPLed, because the kernel is
GPLed and one of the clauses states that anything linked with or derived from
a GPLed work must also be GPLed.

User-mode libraries should be LGPLed, because software linked to LGPLed
software does not have to be GPLed or LGPLed (i.e., commercial packages), but
derivatives must be LGPLed.

There are also other licenses that you can consider, although GPL and LGPL are
usually considered the most fair (except by Microsoft, of course). You can get
more info at http://www.gnu.org/philosophy/license-list.html.

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

Re: PCI NVRAM Memory Card

[Nicholas Knight]

On Wednesday 08 August 2001 12:30 pm, Mike Jadon wrote:
> My company has released a PCI NVRAM memory card but we haven't
> developed a Linux driver for it yet.  We want the driver to be open to
> developers to build upon.  Is there a specific path we should follow
> with this being our goal?  In researching Linux driver development I
> have come across "GPL" or "LGPL".  Where do you recommend we go to find
> out more about this development process?
>

The LGPL is primarily ment for libraries so that non-GPL compatible 
products can link to a library (like glibc) without being GPL'd 
themselves, for a linux driver, I'm not sure this would make much sense, 
and licensing might get complex when trying to intigrate it with the 
kernel, I don't know for sure.
you can find a copy of the LGPL here:
http://www.fsf.org/copyleft/lesser.html
as well as reasons to not use it, here
http://www.fsf.org/licenses/why-not-lgpl.html

the GPL-specific FAQ is here:
http://www.fsf.org/licenses/gpl-faq.html
and the GPL itself is avalible here:
http://www.fsf.org/licenses/gpl.html

this is a list of various software Licenses, GPL compatible Free licenses 
are at the top, GPL-incompatible Free licenses are below that
http://www.fsf.org/licenses/license-list.html

> Thanks and my apologies for using a technical forum for this question,
> but wanted to go to the right source.
>
>
> Mike

Re: PCI NVRAM Memory Card

[H. Peter Anvin]

Followup to:  <5.1.0.14.0.20010622101907.03ac21b0@192.168.0.5>
By author:    Mike Jadon <mikej@umem.com>
In newsgroup: linux.dev.kernel
>
> My company has released a PCI NVRAM memory card but we haven't developed a 
> Linux driver for it yet.  We want the driver to be open to developers to 
> build upon.  Is there a specific path we should follow with this being our 
> goal?  In researching Linux driver development I have come across "GPL" or 
> "LGPL".  Where do you recommend we go to find out more about this 
> development process?
> 
> Thanks and my apologies for using a technical forum for this question, but 
> wanted to go to the right source.
> 

Since you're willing to open the source, you are probably best off
making the kernel portion of your driver GPL and submit it for
integration into the main kernel tree.  The drivers included in the
main kernel tree tend to be the ones that work reliably over time, and
are therefore most valuable to your customers.

As someone else mentioned, user-space libraries should be LGPL.

It should be pointed out that you, as the copyright holder, can
"dual-license" the code if you want to use the same code for
closed-source projects.  If so, the mention of the dual license nature
should be specified in the open code, to keep you from getting in a
sticky situation when someone submits patches.  The most formal such
license is probably the MPL (Mozilla Public License); I do not know
if MPL'd code would be considered "GPL compatible" and therefore
eligible for inclusion in the main kernel.

Another possible license used in a few places is the "New BSD" license
(as opposed to the "Old BSD" license, with the so-called "advertising
clause".)  The BSD license allows *anyone* (including yourselves, of
course, but also your competitors) to take the code and use it in a
closed-source project.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: PCI NVRAM Memory Card

[Jesse Pollard]

"H. Peter Anvin" <hpa@zytor.com>:
> Followup to:  <5.1.0.14.0.20010622101907.03ac21b0@192.168.0.5>
> By author:    Mike Jadon <mikej@umem.com>
> In newsgroup: linux.dev.kernel
> >
> > My company has released a PCI NVRAM memory card but we haven't developed a 
> > Linux driver for it yet.  We want the driver to be open to developers to 
> > build upon.  Is there a specific path we should follow with this being our 
> > goal?  In researching Linux driver development I have come across "GPL" or 
> > "LGPL".  Where do you recommend we go to find out more about this 
> > development process?
> > 
> > Thanks and my apologies for using a technical forum for this question, but 
> > wanted to go to the right source.
> > 
> 
> Since you're willing to open the source, you are probably best off
> making the kernel portion of your driver GPL and submit it for
> integration into the main kernel tree.  The drivers included in the
> main kernel tree tend to be the ones that work reliably over time, and
> are therefore most valuable to your customers.
> 
> As someone else mentioned, user-space libraries should be LGPL.

Actually, the libraries only should be LGPL if you are still intending
to release the source to the library. You can use your own license if
they contain propriatary information, but you wish to allow other developers
to USE the library with new applications which may or may not be GPL.

It gets tricky to word the license such that you don't take over any license
used for the other applications that link with your propriatary library.

Applications can be GPL or propriatary with whatever license you choose.

Please check with real lawyers for the truly "right source".

> It should be pointed out that you, as the copyright holder, can
> "dual-license" the code if you want to use the same code for
> closed-source projects.  If so, the mention of the dual license nature
> should be specified in the open code, to keep you from getting in a
> sticky situation when someone submits patches.  The most formal such
> license is probably the MPL (Mozilla Public License); I do not know
> if MPL'd code would be considered "GPL compatible" and therefore
> eligible for inclusion in the main kernel.
> 
> Another possible license used in a few places is the "New BSD" license
> (as opposed to the "Old BSD" license, with the so-called "advertising
> clause".)  The BSD license allows *anyone* (including yourselves, of
> course, but also your competitors) to take the code and use it in a
> closed-source project.
> 
> 	-hpa

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: PCI NVRAM Memory Card

[Eric W. Biederman]

Mike Jadon <mikej@umem.com> writes:

> My company has released a PCI NVRAM memory card but we haven't developed a Linux
> 
> driver for it yet.  We want the driver to be open to developers to build upon.
> Is there a specific path we should follow with this being our goal?  

You might want to check out the development of the mtd subsystem.
http://www.linux-mtd.infradead.org/

This is probably what you want to write a driver for for your NVRAM PCI card.

Eric

Re: PCI NVRAM Memory Card

[Johannes Erdfelt]

On Fri, Aug 10, 2001, Eric W. Biederman <ebiederm@xmission.com> wrote:
> Mike Jadon <mikej@umem.com> writes:
> 
> > My company has released a PCI NVRAM memory card but we haven't developed a Linux
> > 
> > driver for it yet.  We want the driver to be open to developers to build upon.
> > Is there a specific path we should follow with this being our goal?  
> 
> You might want to check out the development of the mtd subsystem.
> http://www.linux-mtd.infradead.org/
> 
> This is probably what you want to write a driver for for your NVRAM PCI card.

Not really.

In their case, it's a bunch of standard SDRAM on a PCI card with a
battery backup. It's not flash.

A block device is all that's needed.

JE

Re: PCI NVRAM Memory Card

[Eric W. Biederman]

Johannes Erdfelt <johannes@erdfelt.com> writes:

> On Fri, Aug 10, 2001, Eric W. Biederman <ebiederm@xmission.com> wrote:
> > Mike Jadon <mikej@umem.com> writes:
> > 
> > > My company has released a PCI NVRAM memory card but we haven't developed a
> Linux
> 
> > > 
> > > driver for it yet.  We want the driver to be open to developers to build
> upon.
> 
> > > Is there a specific path we should follow with this being our goal?  
> > 
> > You might want to check out the development of the mtd subsystem.
> > http://www.linux-mtd.infradead.org/
> > 
> > This is probably what you want to write a driver for for your NVRAM PCI card.
> 
> Not really.
> 
> In their case, it's a bunch of standard SDRAM on a PCI card with a
> battery backup. It's not flash.
> 
> A block device is all that's needed.

O.k. that make sense, NVRAM has so many meanings...  It still might
make sense to support things like JFFS, and friends, though.  So the
reference isn't totally wasted.  

Somehow I missed the reference to a description of what kind of
hardware is being discussed.  I wonder if the card can do DMA.
Without bus mastering it looks tricky to get burts over the PCI bus,
which would intern mean the card would be relatively slow.  And for
things like keeping a journal for your filesystem generally the faster
the better.  Being able to get 128MB/s would be pretty cool.

Eric

Re: PCI NVRAM Memory Card

[Johannes Erdfelt]

On Fri, Aug 10, 2001, Eric W. Biederman <ebiederm@xmission.com> wrote:
> Johannes Erdfelt <johannes@erdfelt.com> writes:
> 
> > On Fri, Aug 10, 2001, Eric W. Biederman <ebiederm@xmission.com> wrote:
> > > Mike Jadon <mikej@umem.com> writes:
> > > 
> > > > My company has released a PCI NVRAM memory card but we haven't developed a
> > Linux
> > 
> > > > 
> > > > driver for it yet.  We want the driver to be open to developers to build
> > upon.
> > 
> > > > Is there a specific path we should follow with this being our goal?  
> > > 
> > > You might want to check out the development of the mtd subsystem.
> > > http://www.linux-mtd.infradead.org/
> > > 
> > > This is probably what you want to write a driver for for your NVRAM PCI card.
> > 
> > Not really.
> > 
> > In their case, it's a bunch of standard SDRAM on a PCI card with a
> > battery backup. It's not flash.
> > 
> > A block device is all that's needed.
> 
> O.k. that make sense, NVRAM has so many meanings...  It still might
> make sense to support things like JFFS, and friends, though.  So the
> reference isn't totally wasted.  

As a block device, anything is available to be used :)

> Somehow I missed the reference to a description of what kind of
> hardware is being discussed.  I wonder if the card can do DMA.
> Without bus mastering it looks tricky to get burts over the PCI bus,
> which would intern mean the card would be relatively slow.  And for
> things like keeping a journal for your filesystem generally the faster
> the better.  Being able to get 128MB/s would be pretty cool.

It can do DMA, even scatter gather. It's 64 bit too. It's pretty nice.

JE