[GIT PULL] 9p changes fro merge window

[GIT PULL] 9p changes fro merge window

[Eric Van Hensbergen]

The following changes since commit c3b92c8787367a8bb53d57d9789b558f1295cc96:

  Linux 3.1 (2011-10-24 09:10:05 +0200)

are available in the git repository at:
  git://github.com/ericvh/linux.git for-next

Aneesh Kumar K.V (4):
      fs/9p: Update zero-copy implementation in 9p
      fs/9p: inode file operation is properly initialized init_special_inode
      fs/9p: Cleanup option parsing in 9p
      net/9p: Convert net/9p protocol dumps to tracepoints

Dan Carpenter (2):
      9p: move dereference after NULL check
      fs/9p: change an int to unsigned int

Nicolae Mogoreanu (1):
      9p: fix 9p.txt to advertise msize instead of maxdata

 Documentation/filesystems/9p.txt |    2 +-
 fs/9p/v9fs.c                     |   33 ++-
 fs/9p/vfs_dir.c                  |   14 +-
 fs/9p/vfs_inode.c                |    2 -
 include/net/9p/9p.h              |   14 +-
 include/net/9p/client.h          |    8 +-
 include/net/9p/transport.h       |   10 +-
 include/trace/events/9p.h        |  176 ++++++++++++++
 net/9p/client.c                  |  469 +++++++++++++++++++++++++++-----------
 net/9p/protocol.c                |   99 +-------
 net/9p/protocol.h                |    4 +-
 net/9p/trans_common.c            |   53 ++---
 net/9p/trans_common.h            |   21 +--
 net/9p/trans_virtio.c            |  319 +++++++++++++++-----------
 14 files changed, 772 insertions(+), 452 deletions(-)
 create mode 100644 include/trace/events/9p.h

Re: [GIT PULL] 9p changes fro merge window

[Linus Torvalds]

On Mon, Oct 24, 2011 at 6:28 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
>
> are available in the git repository at:
>  git://github.com/ericvh/linux.git for-next

So for the merge window, I *really* want the development trees I pull
from explicitly verified some way.

Now, the p9 patches seem to be small enough, and not core enough, for
me to care deeply, but I really *really* want to not see unsigned
github things.

Putting a signed tag on there somewhere that actually signs the top
commit *and* mentions the repository and branch it is on (ie github)
kis not wonderfully convenient, but it's at least relatively
straightforward (do I have a gpg key I can trust?).

Or using a host that I can trust is being maintained by you guys (or
some trusted third party like kernel.org).

(Also, I'm only seeing about half the patches mentioned in linux-next. Hmm?)

Please? Not pulled.

                   Linus

Re: [GIT PULL] 9p changes fro merge window

[Eric Van Hensbergen]

On Tue, Oct 25, 2011 at 2:25 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, Oct 24, 2011 at 6:28 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
>>
>> are available in the git repository at:
>>  git://github.com/ericvh/linux.git for-next
>
> So for the merge window, I *really* want the development trees I pull
> from explicitly verified some way.
>
> Now, the p9 patches seem to be small enough, and not core enough, for
> me to care deeply, but I really *really* want to not see unsigned
> github things.
>
> Putting a signed tag on there somewhere that actually signs the top
> commit *and* mentions the repository and branch it is on (ie github)
> kis not wonderfully convenient, but it's at least relatively
> straightforward
>

just to make sure I understand:
I create a tag for the top commit of my for-linus branch using my new
4096 PGP key to sign it and in the description give the github.com URL
and branch name?

>
> (do I have a gpg key I can trust?).
>

We did a key-signing party in Austin a few weeks back, but we've only
got a single link to the larger web of trust (via Olaf).  Should that
be sufficient?

>
> (Also, I'm only seeing about half the patches mentioned in linux-next. Hmm?)
>

okay.  that's weird.  I thought linux-next has been pulling from my
github tree (I sent an updated URL some time back).  I guess I never
really checked to make sure he was getting the updated files.  I'll
rectify this as well.

        -eric

Re: [GIT PULL] 9p changes fro merge window

[Eric Van Hensbergen]

On Tue, Oct 25, 2011 at 3:14 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
> On Tue, Oct 25, 2011 at 2:25 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>> On Mon, Oct 24, 2011 at 6:28 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
>>
>> (Also, I'm only seeing about half the patches mentioned in linux-next. Hmm?)
>>
>
> okay.  that's weird.  I thought linux-next has been pulling from my
> github tree (I sent an updated URL some time back).  I guess I never
> really checked to make sure he was getting the updated files.  I'll
> rectify this as well.
>

okay, which linux-next tree are you looking at (and/or which patches
are they missing)? If I look at
/pub/scm/linux/kernel/git/next/linux-next.git on kernel.org I see all
the patches mentioned in my pull.  Sorry in advance if I'm doing
something stupid.

       -eric

Re: [GIT PULL] 9p changes fro merge window

[Geert Uytterhoeven]

On Tue, Oct 25, 2011 at 22:23, Eric Van Hensbergen <ericvh@gmail.com> wrote:
> On Tue, Oct 25, 2011 at 3:14 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
>> On Tue, Oct 25, 2011 at 2:25 AM, Linus Torvalds
>> <torvalds@linux-foundation.org> wrote:
>>> On Mon, Oct 24, 2011 at 6:28 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
>>>
>>> (Also, I'm only seeing about half the patches mentioned in linux-next. Hmm?)
>>
>> okay.  that's weird.  I thought linux-next has been pulling from my
>> github tree (I sent an updated URL some time back).  I guess I never
>> really checked to make sure he was getting the updated files.  I'll
>> rectify this as well.
>
> okay, which linux-next tree are you looking at (and/or which patches
> are they missing)? If I look at
> /pub/scm/linux/kernel/git/next/linux-next.git on kernel.org I see all
> the patches mentioned in my pull.  Sorry in advance if I'm doing
> something stupid.

Current linux-next is next-20111025, but the previous one was next-20111014.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [GIT PULL] 9p changes fro merge window

[Eric Van Hensbergen]

On Tue, Oct 25, 2011 at 3:46 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Tue, Oct 25, 2011 at 22:23, Eric Van Hensbergen <ericvh@gmail.com> wrote:
>> On Tue, Oct 25, 2011 at 3:14 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
>>> On Tue, Oct 25, 2011 at 2:25 AM, Linus Torvalds
>>> <torvalds@linux-foundation.org> wrote:
>>>> On Mon, Oct 24, 2011 at 6:28 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
>>>>
>>>> (Also, I'm only seeing about half the patches mentioned in linux-next. Hmm?)
>>>
>>
>> okay, which linux-next tree are you looking at (and/or which patches
>> are they missing)? If I look at
>> /pub/scm/linux/kernel/git/next/linux-next.git on kernel.org I see all
>> the patches mentioned in my pull.  Sorry in advance if I'm doing
>> something stupid.
>
> Current linux-next is next-20111025, but the previous one was next-20111014.
>

I think I see the requested changes in both of those versions:
   == next-20111025 ==
14211d0 9p: fix 9p.txt to advertise msize instead of maxdata
348b590 net/9p: Convert net/9p protocol dumps to tracepoints
ef6b080 fs/9p: change an int to unsigned int
4d5077f fs/9p: Cleanup option parsing in 9p
5635fd0 9p: move dereference after NULL check
464f5ec fs/9p: inode file operation is properly initialized init_special_inode
abfa034 fs/9p: Update zero-copy implementation in 9p
  == next-20111014 ==
662db18 9p: fix 9p.txt to advertise msize instead of maxdata
ebbfa91 net/9p: Convert net/9p protocol dumps to tracepoints
0c2f0c5 fs/9p: change an int to unsigned int
73bd290 fs/9p: Cleanup option parsing in 9p
99f4122 9p: move dereference after NULL check
402e032 fs/9p: inode file operation is properly initialized init_special_inode
6851475 fs/9p: Update zero-copy implementation in 9p

The ordering was a bit wacky in next-20111014, like stuff had been
shuffled around, but they were all there.

             -eric

[GIT PULL] [Attempt #2] 9p changes fro merge window

[Eric Van Hensbergen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The following changes since commit c3b92c8787367a8bb53d57d9789b558f1295cc96:

  Linux 3.1 (2011-10-24 09:10:05 +0200)

are available in the git repository at:
  git://github.com/ericvh/linux.git for-linus

Aneesh Kumar K.V (4):
      fs/9p: Update zero-copy implementation in 9p
      fs/9p: inode file operation is properly initialized init_special_inode
      fs/9p: Cleanup option parsing in 9p
      net/9p: Convert net/9p protocol dumps to tracepoints

Dan Carpenter (2):
      9p: move dereference after NULL check
      fs/9p: change an int to unsigned int

Nicolae Mogoreanu (1):
      9p: fix 9p.txt to advertise msize instead of maxdata

 Documentation/filesystems/9p.txt |    2 +-
 fs/9p/v9fs.c                     |   33 ++-
 fs/9p/vfs_dir.c                  |   14 +-
 fs/9p/vfs_inode.c                |    2 -
 include/net/9p/9p.h              |   14 +-
 include/net/9p/client.h          |    8 +-
 include/net/9p/transport.h       |   10 +-
 include/trace/events/9p.h        |  176 ++++++++++++++
 net/9p/client.c                  |  469 +++++++++++++++++++++++++++-----------
 net/9p/protocol.c                |   99 +-------
 net/9p/protocol.h                |    4 +-
 net/9p/trans_common.c            |   53 ++---
 net/9p/trans_common.h            |   21 +--
 net/9p/trans_virtio.c            |  319 +++++++++++++++-----------
 14 files changed, 772 insertions(+), 452 deletions(-)
 create mode 100644 include/trace/events/9p.h

The signed tag is: for-linus-3.2-merge-window in that branch

(sorry if I messed anything up in the signing process)

      -eric
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQIcBAEBAgAGBQJOpybdAAoJEGQ1yQUIRaTO0IkQAMax4r3FJBRvG+FpAs1sXgfq
AFiSBBLQ6Y5b/cr33o4l9Y6mL1j1A8QBFThSWEWHMxn6oz1h2lFbGHunWAJGVgOZ
Dvch7vK2ACQlwV/jFyN5CfbmDrFin15U/Olvhy78cTF2crKxCayMvrS/8h45++i1
DEcFcmHHzbPGJUiKrhiZEMw2di9JyNzmBz9jqg5FTmn8U8mESW/7B6uSIiu/CqFS
1hlQ7k8VoMguqXzdjQNPkZkP3iSBAwuv/rf3w6L9def4nPJ8SrV/ALGMXemNsLQF
MVuBOoPToXOEIl7M/fuBlcl21KxCF9Y74fKlKdMZQoSj/aTmULf4Z4Bl86WS717w
gdwIe6kxwLjONwDr546haklxf3pf+ovGgRGnrvaJ7nuYsfVOr7iIUG+WSiiT886G
SPsd07wKo+O1KmzzLKU5mLPiSBr2QFrYyRWxWmZ+GomAPMRbhGrNgk/GOR+GI0/Z
xE+/QNM41EMStvwRtXa6MJT63+9msNf8L2zDUgFSgfNedHHnCWZqCCWzeGwxgcK6
SHCnj7J6VWdqZBHFDYno0KDtwsRca72XZoei1kgUH+epSiWTvZdpgDNeSA0NCqTi
HnxI3vdbH95ptsM/lvljEA/vDo/nYg83LVvWcbFrLlUcUrmq03xftrItABCaQ4+D
mBTzEHrtFUvs7hw17n3N
=zUBe
-----END PGP SIGNATURE-----

Re: [GIT PULL] 9p changes fro merge window

[Linus Torvalds]

On Tue, Oct 25, 2011 at 10:14 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
>>
>> (Also, I'm only seeing about half the patches mentioned in linux-next. Hmm?)
>>
>
> okay.  that's weird.  I thought linux-next has been pulling from my
> github tree (I sent an updated URL some time back).  I guess I never
> really checked to make sure he was getting the updated files.  I'll
> rectify this as well.

This turns out to be just me being stupid. I just checked the changes
in fs/9p, and not net/9p, so I didn't find Dan Carpenters patches in
net. And because you had rebased them, I was looking at that (partial)
shortlog when comparing, rather than the full one.

Anyway, pulled now. I do wish people didn't rebase so much, it makes
all the commits different in linux-next wrt what I actually end up
getting..

                Linus

Re: [GIT PULL] 9p changes fro merge window

[Eric Van Hensbergen]

On Oct 26, 2011, at 7:28 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> Anyway, pulled now. I do wish people didn't rebase so much, it makes
> all the commits different in linux-next wrt what I actually end up
> getting..
> 

What's the preferred maintainer workflow?  I had been fetching and then rebasing, which seemed to keep my shortlog clean of merge commits and the outstanding patches towards the top.  Should I just be pulling from upstream and not caring about the merge commits?

Also, as a point of clarification, if I do get my kernel.org tree back, should I continue to sign tags for pull-requests or was that just for external repos like github?

         -eric

Re: [GIT PULL] 9p changes fro merge window

[Linus Torvalds]

On Wed, Oct 26, 2011 at 2:48 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
>
> What's the preferred maintainer workflow?  I had been fetching and then rebasing, which seemed to keep my shortlog clean of merge commits and the outstanding patches towards the top.  Should I just be pulling from upstream and not caring about the merge commits?

Hell no.

Why do you pull from upstream? What does that add to *your*
development? Don't do it. Pick a place to start, and just develop
things. Ask me to pull.

No merge commits, no rebases, no nothing. JUST ACTUAL WORK. It also
keeps the history clean, and means that what people test (in
linux-next _and_ in your own internal testing) is actually what you
ask me to pull, rather than something else.

> Also, as a point of clarification, if I do get my kernel.org tree back, should I continue to sign tags for pull-requests or was that just for external repos like github?

Just for external repos on sites that have no other verification.

We may want to do the whole git-level signing for everything
eventually, but only if/when git makes it easy to sign the pull
request (and verify it). Until then, the "make a separate signature"
is just a way to avoid the "I have no idea who you are" issue.

                     Linus

Re: [GIT PULL] 9p changes fro merge window

[Pekka Enberg]

Hi Eric,

On Wed, Oct 26, 2011 at 3:48 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
> What's the preferred maintainer workflow?  I had been fetching and then rebasing, which
> seemed to keep my shortlog clean of merge commits and the outstanding patches
> towards the top.  Should I just be pulling from upstream and not caring about the merge
> commits?

I don't know if mine is the preferred workflow but what I usually do is:

  1. Send a pull request to Linus in a separate throw-away branch
      that's an exact copy of my "next" branch.

  2. Wait until -rc1 is out and git reset my "next" branch to that.

  3. Apply patches on top of the "next" branch. I never rebase or
      do merges from Linus tree to the branch.

  4. Once the merge window opens, goto 1.

[ Actually, I sometimes have multiple "next" topic branches if there's a risk
  that I need to back out some of the changes from linux-next in the middle
   of the merge cycle. ]

                        Pekka

Re: [GIT PULL] 9p changes fro merge window

[Pekka Enberg]

On Wed, Oct 26, 2011 at 4:00 PM, Pekka Enberg <penberg@cs.helsinki.fi> wrote:
> I don't know if mine is the preferred workflow but what I usually do is:
>
>  1. Send a pull request to Linus in a separate throw-away branch
>      that's an exact copy of my "next" branch.
>
>  2. Wait until -rc1 is out and git reset my "next" branch to that.
>
>  3. Apply patches on top of the "next" branch. I never rebase or
>      do merges from Linus tree to the branch.
>
>  4. Once the merge window opens, goto 1.
>
> [ Actually, I sometimes have multiple "next" topic branches if there's a risk
>  that I need to back out some of the changes from linux-next in the middle
>   of the merge cycle. ]

And oh, I usually set up a local 'testing' branch when the merge
window opens merge latest release and my 'next' branch to it. It's
mostly a sanity check before I send a pull request to Linus to check
that everything still works. I never publish this branch nor make it
part of the pull request to Linus.

                        Pekka

Re: [GIT PULL] 9p changes fro merge window

[Ted Ts'o]

On Wed, Oct 26, 2011 at 07:48:59AM -0500, Eric Van Hensbergen wrote:
> 
> What's the preferred maintainer workflow?  I had been fetching and
> then rebasing, which seemed to keep my shortlog clean of merge
> commits and the outstanding patches towards the top.  Should I just
> be pulling from upstream and not caring about the merge commits?

Don't fetch or merge from upstream at all.  For this merge window I've
done all of my development based on v3.1-rc3.  Periodically I'll fetch
from upstream, and I'll do trail merges with upstream on a throwaway
patch just to make things will work or to be alerted of any merge
conflicts.  (Actually, linux-next is really good for that as well.)

> Also, as a point of clarification, if I do get my kernel.org tree
> back, should I continue to sign tags for pull-requests or was that
> just for external repos like github?

It's a good idea to to sign tags so that 3rd parties can verify your
pull requests if (God forbid) something like this were to happen
again.  I personally plan to use a tag like this: tytso-for-linus-20111026
(i.e., <username>-for-linus-<datestamp>).  It's not required, though.

						- Ted

Re: [GIT PULL] 9p changes fro merge window

[Eric Van Hensbergen]

On Wed, Oct 26, 2011 at 7:58 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Wed, Oct 26, 2011 at 2:48 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
>>
>> What's the preferred maintainer workflow?  I had been fetching and then rebasing, which seemed to keep my shortlog clean of merge commits and the outstanding patches towards the top.  Should I just be pulling from upstream and not caring about the merge commits?
>
> Hell no.
>
> Why do you pull from upstream? What does that add to *your*
> development? Don't do it. Pick a place to start, and just develop
> things. Ask me to pull.
>

okay, I guess I was always updating to make sure I was integration
testing against the tip, but I can do that in throw-away branches so
that the branch I ask you to pull from keeps somewhat more sane.

            -eric

Re: [GIT PULL] 9p changes fro merge window

[Geert Uytterhoeven]

On Wed, Oct 26, 2011 at 14:58, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Wed, Oct 26, 2011 at 2:48 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
>> What's the preferred maintainer workflow?  I had been fetching and then rebasing, which seemed to keep my shortlog clean of merge commits and the outstanding patches towards the top.  Should I just be pulling from upstream and not caring about the merge commits?
>
> Hell no.
>
> Why do you pull from upstream? What does that add to *your*
> development? Don't do it. Pick a place to start, and just develop
> things. Ask me to pull.
>
> No merge commits, no rebases, no nothing. JUST ACTUAL WORK. It also
> keeps the history clean, and means that what people test (in
> linux-next _and_ in your own internal testing) is actually what you
> ask me to pull, rather than something else.

That works if what you do is "small" and "fast".

"small":
  - There are no conflicts with anyone else who is e.g. restructuring
part of the tree,
  - You do not want to early submit parts that should go in through a different
    maintainer as soon as they're ready (and thus they disappear from
your patchset
    when you rebase),

"fast":
  - You started working on it after the last merge window, and not 3
releases ago.

If the above are not true, it's a hell of work to keep track of
everything without
rebasing. Not to mention that the reviewers don't like seeing patches that apply
to obsolete trees.

And of course I don't want to bother you with fixing the merge
conflicts that happen
when I would ask to pull e.g. the m68k genirq conversion based on the
state of your
tree when I started working on it ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds