linux-kernel - Re: [PATCH 12/12] VMCI: Some header and config files.

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 30 Nov 2012 09:09:21 -0800
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Andy King <acking@...are.com>
Cc:	George Zhang <georgezhang@...are.com>,
	linux-kernel@...r.kernel.org,
	virtualization@...ts.linux-foundation.org, pv-drivers@...are.com,
	Dmitry Torokhov <dmitry.torokhov@...il.com>
Subject: Re: [PATCH 12/12] VMCI: Some header and config files.

On Fri, Nov 30, 2012 at 08:47:46AM -0800, Andy King wrote:
> I didn't get the resend either, so it seems our corporate mail really is
> eating messages.  Lovely.
> 
> > > > +#define IOCTLCMD(_cmd) IOCTL_VMCI_ ## _cmd
> > > 
> > > I don't recall ever getting a valid answer for this (if you did, my
> > > appologies, can you repeat it).  What in the world are you talking
> > > about here?  Why is your driver somehow special from the thousands
> > > of other ones that use the in-kernel IO macros properly for an
> > > ioctl?
> 
> Because we're morons.  And unfortunately, we've shipped our product
> using those broken definitions: our VMX uses them to talk to the driver.
> So here's what we'd like to do.  We will send out a patch soon that
> fixes the other issues you mention and also adds IOCTL definitions the
> proper way using _IOBLAH().  But we'd also like to retain these broken
> definitions for a short period, commented as such, at least until we
> can get out a patch release to Workstation 9, at which point we can
> remove them.  Does that sound reasonable?

It has been my experience, that when people say "We will remove that api
sometime in the future", it never happens.  So why not just do it now?

Especially given that this code will be coming out in 3.9 at the
earliest, and that is 6 months away, so that should be plenty of time to
get this fixed up.

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/