linux-kernel - Re: [Pv-drivers] [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: Windows password security audit tool. GUI, reports in PDF.

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

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

On Friday, November 30, 2012 09:09:21 AM Greg KH wrote:
> 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.

Our schedule for releasing hosted products is not necessarily aligned
with mainline kernel releases.

Also, thinking about it some more, maybe we should simply keep the old
ioctls as is? Yes, they would not use the standard kernel style encoding
for direction, etc, but the encoding only important if ioctl handler
wants to parse and use it. Since we do not flat ioctl number is fine
with us.

That said we 'll clean up comments and numbers to remove stuff not
applicable to mainline.

Thanks,
Dmitry
--
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/