Re: 2.6.17-rc6-mm2

Re: 2.6.17-rc6-mm2

[Chuck Ebbert]

Finally got around to downloading the broken-out 2.6.17-rc6-mm2 and when
I applied it a bunch of these came out:

  Applying patch documentation-ioctl-messtxt-start-tree-wide-ioctl-registry.patch
  missing header for unified diff at line 4854 of patch
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Applying patch post-halloween-doc.patch
  Applying patch kgdb-core-lite.patch
  missing header for unified diff at line 2614 of patch
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Applying patch lock-validator-special-locking-kgdb.patch
  Applying patch kgdb-core-lite-add-reboot-command.patch
  Applying patch kgdb-8250.patch
  Applying patch kgdb-8250-fix.patch
  Applying patch kgdb-netpoll_pass_skb_to_rx_hook.patch
  Applying patch kgdb-eth.patch
  Applying patch kgdb-i386-lite.patch
  Applying patch kgdb-cfi_annotations.patch
  missing header for unified diff at line 1423 of patch
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Seems mostly harmless, as the changes applied anyway, but those headers do
look strange: the '---' lines are missing a directory name:

  diff -puN Makefile~kgdb-cfi_annotations Makefile
  --- Makefile~kgdb-cfi_annotations       2006-06-09 15:18:45.000000000 -0700
  +++ devel-akpm/Makefile 2006-06-09 15:18:45.000000000 -0700

-- 
Chuck
 "You can't read a newspaper if you can't read."  --George W. Bush

Re: 2.6.17-rc6-mm2

[Linus Torvalds]

On Fri, 16 Jun 2006, H. Peter Anvin wrote:
> 
> Perhaps we shouldn't rely on stderr, and instead have a backchannel as part of
> the protocol itself.

Absolutely. I'm just irritated at myself for not going that way in the 
first place, but when I originally wrote it, I had my eyes on other 
issues, and the nice status updates got added later..

		Linus

Re: 2.6.17-rc6-mm2

[bert hubert]

On Thu, Jun 15, 2006 at 11:39:35PM -0700, Linus Torvalds wrote:

> Except they only work over ssh, where we have a separate channel (for 
> stderr), and with the native git protocol all that nice status work just 
> gets flushed to /dev/null :(

It won't help passing firewalls one bit, but you might consider using SCTP
with multiple datastreams for this - theoretically :-)

	Bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

Re: 2.6.17-rc6-mm2

[H. Peter Anvin]

Linus Torvalds wrote:
> 
> Actually, the really irritating thing is that we actually generate all 
> these nice status updates, which just makes pulling and cloning a lot more 
> comfortable, because you actually see what is going on, and what to 
> expect. 
> 
> Except they only work over ssh, where we have a separate channel (for 
> stderr), and with the native git protocol all that nice status work just 
> gets flushed to /dev/null :(
> 
> Dang. It's literally the most irritating part of the thing: the protocol 
> itself is exactly the same whether you go over ssh:// or over git://, but 
> that visual information about what is going on is missing, and it's 
> surprisingly important from a usability standpoint.
> 

Perhaps we shouldn't rely on stderr, and instead have a backchannel as part of the 
protocol itself.  After all, the protocol already does packetization, so all it needs is a 
reliable way to pick out the error/status packets; we could even combine that with a 
machine-readable code (like SMTP et al) that could get interpreted by the other side as 
needed.

	-hpa

Re: 2.6.17-rc6-mm2

[Linus Torvalds]

On Fri, 16 Jun 2006, Goo GGooo wrote:
> 
> Thanks for explanation. Unfortunately I can't use git:// with "git
> pull" (at least in git-1.3.2). First it does some traffic, that
> suddenly stops - I guess the server starts doing *something*, perhaps
> preparing the update for me or whatnot.

Yeah, for a big pull, the server will have to think about the objects it 
is going to send you.

> I suggest adding SO_KEEPALIVE option on the git socket.

Actually, the really irritating thing is that we actually generate all 
these nice status updates, which just makes pulling and cloning a lot more 
comfortable, because you actually see what is going on, and what to 
expect. 

Except they only work over ssh, where we have a separate channel (for 
stderr), and with the native git protocol all that nice status work just 
gets flushed to /dev/null :(

Dang. It's literally the most irritating part of the thing: the protocol 
itself is exactly the same whether you go over ssh:// or over git://, but 
that visual information about what is going on is missing, and it's 
surprisingly important from a usability standpoint.

And in your case, the usability downside actually turned into a real 
accessibility bug.

Oh, well.

		Linus

Re: 2.6.17-rc6-mm2

[Goo GGooo]

On 6/16/06, Linus Torvalds <torvalds@osdl.org> wrote:

> So to recap:
>  - http is fundamentally weaker, and needs some server-side help to work
>  - rsync is fine for the initial clone, but doesn't actually know what
>    it's doing, so the end result can actually even be a corrupted
>    repository, because you happened to rsync just as it was updating.
>  - the native git protocol generally should be considered the golden
>    standard, where the other ones are just fallbacks in case of problems
>    (like firewalls that don't let git:// through, or more commonly hosted
>    servers that don't do the git protocol at all).
>
> Which hopefully clarifies the issue a bit.

Thanks for explanation. Unfortunately I can't use git:// with "git
pull" (at least in git-1.3.2). First it does some traffic, that
suddenly stops - I guess the server starts doing *something*, perhaps
preparing the update for me or whatnot. After a pretty long while it
sends some more data but in the meanwhile my ADSL router dropped the
NAT entry and git sits on my side waiting for data forever. Recently I
tried the same on a system with direct Inet connection and that worked
just fine.

I suggest adding SO_KEEPALIVE option on the git socket.

Goo

Re: 2.6.17-rc6-mm2

[Linus Torvalds]

On Fri, 16 Jun 2006, Goo GGooo wrote:
> 
> That's confusing - I believed all protocols should behave the same way...?

Not really. The primary protocol is the native git one, and the others try 
to do a best effort, but the http protocol really can't do a very good 
job unless the server side has run "git update-server-info" to help the 
http client along.

I suspect that the -mm git tree simply doesn't do that. In fact, even the 
main tree didn't use to do it, but I finally just broke down and added the 
proper hook to make it always do it automatically when I push.

(In case Andrew wants to do that, the way to do it is:

	echo -e "#!/bin/sh\nexec git-update-server-info" > hooks/post-update
	chmod +x hooks/post-update

inside the git repository - all it will do is always execute that script, 
and this "git-update-server-info", after you've updated the repo).

Finally, the rsync protocol just copies all objects over, and since it 
doesn't even know _which_ objects it is getting, it doesn't do the normal 
tag following that the native git protocol does.

So to recap:
 - http is fundamentally weaker, and needs some server-side help to work
 - rsync is fine for the initial clone, but doesn't actually know what 
   it's doing, so the end result can actually even be a corrupted 
   repository, because you happened to rsync just as it was updating.
 - the native git protocol generally should be considered the golden 
   standard, where the other ones are just fallbacks in case of problems 
   (like firewalls that don't let git:// through, or more commonly hosted 
   servers that don't do the git protocol at all).

Which hopefully clarifies the issue a bit.

		Linus

Re: 2.6.17-rc6-mm2

[Goo GGooo]

On 6/15/06, Goo GGooo <googgooo@gmail.com> wrote:
> Andrew Morton wrote:
>
> > - To fetch an -mm tree using git, use (for example)
> >
> >  git fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git
> > v2.6.16-rc2-mm1
>
> I'm not able to get -mm tree from GIT. In
> http://git.kernel.org/.../smurf/linux-trees.git/refs/tags/ I can see
> the most recent tags like v2.6.17-rc6-mm2 but cg-clone
> http://git.kernel.org/.../smurf/linux-trees.git gives me only
> 2.6.16-rc3 :(
>
> I tried "cg-fetch v2.6.17-rc6-mm2" which seemed to fetch some more
> tags, then played with git-checkout & friends but still can't get the
> most recent source tree.

All right, finally this worked out:
git pull rsync://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git \
      tag v2.6.17-rc6-mm2

Strange enough with http:// instead of rsync:// I got some message
about nonexistent tag.

Now when I try git pull with http:// again it says the tree is up to
date. However with git:// it started downloading more things and tags.

That's confusing - I believed all protocols should behave the same way...?

Goo

Re: 2.6.17-rc6-mm2

[Goo GGooo]

Andrew Morton wrote:

> - To fetch an -mm tree using git, use (for example)
>
>  git fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git v2.6.16-rc2-mm1

I'm not able to get -mm tree from GIT. In
http://git.kernel.org/.../smurf/linux-trees.git/refs/tags/ I can see
the most recent tags like v2.6.17-rc6-mm2 but cg-clone
http://git.kernel.org/.../smurf/linux-trees.git gives me only
2.6.16-rc3 :(

I tried "cg-fetch v2.6.17-rc6-mm2" which seemed to fetch some more
tags, then played with git-checkout & friends but still can't get the
most recent source tree.

How do I do that? Best if I could still fetch updates in the same tree later.

RTFM is all right if followed by a link to TFM ;-)

Thanks

Goo