linux-kernel - Re: [Pv-drivers] [PATCH 04/10] VMCI: device driver implementaton.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20121025203148.GA28096@kroah.com>
Date:	Thu, 25 Oct 2012 13:31:48 -0700
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Andy King <acking@...are.com>
Cc:	pv-drivers@...are.com, vm-crosstalk@...are.com,
	linux-kernel@...r.kernel.org,
	virtualization@...ts.linux-foundation.org,
	George Zhang <georgezhang@...are.com>
Subject: Re: [Pv-drivers] [PATCH 04/10] VMCI: device driver implementaton.

On Thu, Oct 25, 2012 at 01:16:00PM -0700, Andy King wrote:
> Hi Greg,
> 
> > > +EXPORT_SYMBOL(vmci_device_get);
> > 
> > EXPORT_SYMBOL_GPL() for this, and all other exports?
> 
> We'd prefer to leave them as vanilla exports.  While we're committed
> to open-sourcing everything, including our non-upstreamed drivers,
> we don't really have a strong opinion regarding consuming our exports
> in closed-source (general GPL issues aside).

You can't just say "general GPL issues aside".  Honestly, given your
company's prior actions in regards to Linux kernel drivers and the
licenses of them, I don't trust them at all.  To help gain that trust
back, marking the exports in this manner will be a great improvement.

To insist otherwise is to only reinforce my doubts, and reduce my
wanting to even review or accept this code at all.  Sorry about that.

> > And it seems that you have a bunch of "unused" parameters for this,
> > and other public functions.  Please just remove them entirely.
> 
> Will do.
> 
> Also, regarding that particular public function, it seems to have slipped
> through the cracks.  It's an artifact of the API being cross-platform
> prior to upstreaming.  On Linux, it makes no sense whatsoever, so we'll
> just yank it completely.

What other calls can be removed?  Did you run sparse on all of these
files to ensure that things are "clean" with regards to static functions
and the like?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/