mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Greg KH <greg@kroah.com>
Cc: Arve Hj?nnev?g <arve@android.com>,
	kernel list <linux-kernel@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Brian Swetland <swetland@google.com>
Subject: Re: staging/dream: add gpio and pmem support
Date: Tue, 27 Oct 2009 20:33:30 +0100	[thread overview]
Message-ID: <20091027193330.GB19379@elf.ucw.cz> (raw)
In-Reply-To: <20091027165750.GA24477@kroah.com>

Hi!

> > Could we perhaps use -I to let it build before I find time to do
> > search&replace of 100 #includes? Yes, I'm working on that, but no, it
> > obviously does not progress as fast as I expected...
> > 
> > Add missing files/includes neccessary for Dream compilation.
> >     
> > Signed-off-by: Pavel Machek <pavel@ucw.cz>
> 
> Ick, no.  I'm not going to take the wakelock and other header files that
> are "generic" to android into the dream subdir.  That's not ok.

What is so wrong with wakelocks? They are just nops in this case.

> If this code requires this mess to build, I think we should just delete
> the whole thing and start over with patches that add code that can
> actually build properly.

Well, crap is easier to clean up when it compiles (and is in tree --
that's point of staging -- right?), and it is not particulary bad crap
in this case.

> Any objection to that?

Yes; dropping the code now will not help anything. Merging it to this
point was not easy, and forcing me to redo it will just delay me from
cleaning it up.

Merging crappy Windows driver to staging is easy:

1) you verify it is GPL

2) you submit it

[and then, clean it in tree].

I tried same process with dream support:

1) driver was GPLed

2) I tried submitting

3) I was told to split it according to authors. In Windows driver
world, that would be show-stopper. Thanks to Google support, I figured
authors.

4) I'm told that -I is not acceptable, not even inside
staging. Windows drivers regulary have way worse build system
abuses. (Of course, those need to be fixed before merging into kernel
proper; fortunately they are easy to do incrementally).

Now, I see that wakelocks are show-stopper for merging into kernel
proper, but what is the problem for staging? We merged drivers with
OS_MEMORY_ALLOCATE(); wakelocks are just nops in this case.

Could we please clean this driver in-tree? (Wakelocks are already nops
due to #ifdef magic, cleaning them incrementally is easy.)

(Plus, of course I'd like some help, but google people seem very
silent :-( ).
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

  reply	other threads:[~2009-10-27 19:33 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-22  9:13 Pavel Machek
2009-10-26 23:43 ` Greg KH
2009-10-27  0:17   ` Pavel Machek
2009-10-27  3:00     ` Greg KH
2009-10-27  8:19       ` Pavel Machek
2009-10-27 16:57         ` Greg KH
2009-10-27 19:33           ` Pavel Machek [this message]
2009-10-27 20:44             ` Greg KH
2009-10-27 23:25               ` Pavel Machek
2009-10-28 15:51                 ` Greg KH
2009-10-28 21:56                   ` Pavel Machek
2009-10-28 22:11                     ` Greg KH
2009-10-28 22:41                       ` Pavel Machek
2009-10-27 22:03             ` Brian Swetland
2009-10-28 21:22               ` Pavel Machek
2009-10-28  8:59 ` Paulius Zaleckas
2009-10-28  9:05   ` Pavel Machek

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=20091027193330.GB19379@elf.ucw.cz \
    --to=pavel@ucw.cz \
    --cc=arve@android.com \
    --cc=greg@kroah.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=swetland@google.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®