From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Michael Thayer <michael.thayer@oracle.com>
Cc: "devel@driverdev.osuosl.org" <devel@driverdev.osuosl.org>,
vbox-dev@virtualbox.org,
dri-devel <dri-devel@lists.freedesktop.org>,
Hans de Goede <hdegoede@redhat.com>,
Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [PATCH v2] staging: vboxvideo: Add vboxvideo to drivers/staging
Date: Mon, 12 Jun 2017 14:56:40 +0200 [thread overview]
Message-ID: <20170612125640.GA24858@kroah.com> (raw)
In-Reply-To: <5bfcf51d-03e9-cda6-2461-876613fb1147@oracle.com>
On Mon, Jun 12, 2017 at 02:46:54PM +0200, Michael Thayer wrote:
> Hello Greg,
>
> 12.06.2017 13:47, Greg Kroah-Hartman wrote:
> > On Mon, Jun 12, 2017 at 01:44:09PM +0200, Greg Kroah-Hartman wrote:
> > > On Mon, Jun 12, 2017 at 12:07:41PM +0200, Hans de Goede wrote:
> > > > > The most important thing is for the driver to be atomic if it's KMS
> > > > > only, and it would be good to have someone review that properly.
> > > >
> > > > I believe it does not use the atomic APIs atm, so that would be one
> > > > of the first things to fix then. Another question is if people
> > > > (you and Daniel at least) can live with the non kernel-coding
> > > > style shared files under the osindependent dir ?
> > >
> > > Why not just spend a few days and fix up all of the kernel-style issues
> > > so it can be a "real" driver? It shouldn't take all that long,
> > > especially for someone with Linux kernel experience (hint, hint...)
>
> The idea was that bits which are device-specific and which there would be no
> interest in sharing with other drivers in the kernel could stay in the
> VirtualBox coding style. Since most updates to this code are likely to come
> from us and it is shared with our drivers for other platforms, that would
> make it easier for the in-kernel driver maintainer to pull fixes from the
> VirtualBox tree.
Sorry, but no, in-kernel code has to follow the in-kernel style guide,
we do this for a very good reason (i.e. so others can fix your bugs.)
Why not just use the kernel style rules for your code as well? That way
no need to be confused when switching between the two :)
> > > Only put stuff in staging for a good reason, and that reason can be "I
> > > don't know how to clean this stuff up", but I don't think that is the
> > > case here...
> >
> > And why are you cc:ing a mailing list that does not accept non-members
> > to post? that's just annoying...
>
> Isn't dri-devel members only too?
I don't get any bounces from it complaining, so I doubt it. If it is,
that's the correct way to manage a mailing list, don't have it bounce
nasty messages back at you...
thanks,
greg k-h
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2017-06-12 12:56 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-12 6:56 [PATCH v2] staging: vboxvideo: Add vboxvideo to drivers/staging Hans de Goede
2017-06-12 7:27 ` Dave Airlie
2017-06-12 10:07 ` Michael Thayer
2017-06-12 12:07 ` Dan Carpenter
2017-06-12 10:07 ` Hans de Goede
2017-06-12 11:44 ` Greg Kroah-Hartman
2017-06-12 11:47 ` Greg Kroah-Hartman
2017-06-12 12:46 ` Michael Thayer
2017-06-12 12:56 ` Greg Kroah-Hartman [this message]
2017-06-12 15:40 ` Hans de Goede
2017-06-12 16:03 ` Greg Kroah-Hartman
2017-06-12 16:23 ` Hans de Goede
2017-06-13 11:50 ` Michael Thayer
2017-06-13 12:48 ` Greg Kroah-Hartman
2017-06-13 13:45 ` Michael Thayer
2017-06-13 13:59 ` Greg Kroah-Hartman
2017-06-13 15:00 ` Michael Thayer
2017-06-13 15:41 ` Greg Kroah-Hartman
2017-06-14 9:07 ` Michael Thayer
2017-06-13 18:03 ` Sean Paul
2017-06-14 9:34 ` Michael Thayer
2017-06-14 13:30 ` Hans de Goede
2017-06-14 13:40 ` Michael Thayer
2017-06-14 15:03 ` Hans de Goede
2017-06-14 14:42 ` Sean Paul
2017-06-14 15:01 ` Michael Thayer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170612125640.GA24858@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=daniel.vetter@intel.com \
--cc=devel@driverdev.osuosl.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=hdegoede@redhat.com \
--cc=michael.thayer@oracle.com \
--cc=vbox-dev@virtualbox.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.