Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 25 Nov 2012 12:18:55 -0700
From:      Ian Lepore <freebsd@damnhippie.dyndns.org>
To:        Oleksandr Tymoshenko <gonzo@bluezbox.com>
Cc:        arch@freebsd.org
Subject:   Porting linux drivers [was: Re: [RFC] sema_wait_sig]
Message-ID:  <1353871135.69940.77.camel@revolution.hippie.lan>
In-Reply-To: <E5FE70A7-D2D2-4021-950B-48FD84F11F08@bluezbox.com>
References:  <E5FE70A7-D2D2-4021-950B-48FD84F11F08@bluezbox.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2012-11-22 at 22:12 -0800, Oleksandr Tymoshenko wrote:
> Hello,
> 
> Is there any particular reason FreeBSD does not have sema_wait_sig
> function? It seems to be easily implementable using cv_wait_sig
> function. 
> 
> The reason I'm asking is that I'm getting some Linux drivers
> ported to FreeBSD and the code in question relies on semaphores
> and there is no obvious alternative to down_interruptible function.
> I realize that not all approaches to driver development are easily
> mappable from OS to OS but in this case lack of cv_wait_sig seems 
> like gap in API. Unless of course there is strong rationale behind it.

As if this thread weren't contentious enough already, it seems to me to
be the perfect lead-in to a question I've long wondered about...

Given that linux drivers are pretty much universally GPL licensed,
what's the legality of "porting" them (whatever that means) to freebsd?
Just how much can you cobble from a GPL'd linux driver in creating a
BSD-licensed freebsd driver?

I've done my best to avoid EVER looking at linux driver code when
working on freebsd drivers, because I don't know the legalistic answers
to such questions.  I know the "what feels right to my moral sense"
answer, which is if you study the linux driver and then write
essentially the same driver for freebsd, it doesn't matter if you've
re-typed the code with different variable names, you've copied it.

I've peeked at the linux code from time to time, mostly to confirm my
understanding of poorly-written chip datasheets, or to find the meaning
of some status register bit that doesn't seem to be documented
elsewhere.  But it would be nice to know where the proper lines are that
should not be crossed.

-- Ian





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1353871135.69940.77.camel>