[bk patch] Make cardbus compile in -pre4

[bk patch] Make cardbus compile in -pre4

[Patrick Mochel]

I broke cardbus compile in -pre4 on accident. Sorry about that...

(I don't have a public repository yet, so there's no place to pull form)

diffstat results: 
 drivers/pcmcia/cardbus.c |    3 +--
 1 files changed, 1 insertion, 2 deletions

ChangeSet
  1.231 02/02/08 18:22:27 mochel@segfault.osdlab.org +1 -0
  Doh! 
  struct device has no ->sysdata
  and ->device should be ->dev
   

  drivers/pcmcia/cardbus.c
    1.7 02/02/08 18:22:27 mochel@segfault.osdlab.org +1 -2
    Doh! 
    struct device has no ->sysdata
    and ->device should be ->dev
     


diff -Nru a/drivers/pcmcia/cardbus.c b/drivers/pcmcia/cardbus.c
--- a/drivers/pcmcia/cardbus.c	Fri Feb  8 18:23:08 2002
+++ b/drivers/pcmcia/cardbus.c	Fri Feb  8 18:23:08 2002
@@ -279,8 +279,7 @@
 		pci_readw(dev, PCI_DEVICE_ID, &dev->device);
 		dev->hdr_type = hdr & 0x7f;
 
-		dev->dev.parent = bus->device;
-		dev->dev.sysdata = bus->sysdata;
+		dev->dev.parent = bus->dev;
 		strcpy(dev->dev.name, dev->name);
 		strcpy(dev->dev.bus_id, dev->slot_name);
 		device_register(&dev->dev);

Re: [bk patch] Make cardbus compile in -pre4

[Andreas Dilger]

On Feb 08, 2002  18:25 -0800, Patrick Mochel wrote:
> (I don't have a public repository yet, so there's no place to pull form)

I don't see why everyone who is using BK is expecting Linus to do a pull.
In the non-BK case, wasn't it always a "push" model, and Linus would not
"pull" from URLs and such?  Why are people not simply doing:

!bk send -r+ (other options) - 

from within their editor (or equivalent) to inline the CSET in the email?
This has the added advantage that other people reading the email can also
import the CSET immediately if they so desire.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: [bk patch] Make cardbus compile in -pre4

[Jeff Garzik]

Andreas Dilger wrote:
> 
> On Feb 08, 2002  18:25 -0800, Patrick Mochel wrote:
> > (I don't have a public repository yet, so there's no place to pull form)
> 
> I don't see why everyone who is using BK is expecting Linus to do a pull.
> In the non-BK case, wasn't it always a "push" model, and Linus would not
> "pull" from URLs and such?  Why are people not simply doing:
> 
> !bk send -r+ (other options) -
> 
> from within their editor (or equivalent) to inline the CSET in the email?
> This has the added advantage that other people reading the email can also
> import the CSET immediately if they so desire.

This is a good point...

'bk pull' is probably most useful to high volume submitters, where the
contents of most patches is either obvious and/or uninteresting.  'bk
send -d -r<rev> -' should be fine for importing.

But this is still a trial run of BK, so who knows what will wind up to
be the best policy for casual submitters.

And there's nothing wrong at all with sending GNU patches...

	Jeff



-- 
Jeff Garzik      | "I went through my candy like hot oatmeal
Building 1024    |  through an internally-buttered weasel."
MandrakeSoft     |             - goats.com

Re: [bk patch] Make cardbus compile in -pre4

[Andreas Dilger]

On Feb 08, 2002  23:02 -0500, Jeff Garzik wrote:
> Andreas Dilger wrote:
> > I don't see why everyone who is using BK is expecting Linus to do a pull.
> > In the non-BK case, wasn't it always a "push" model, and Linus would not
> > "pull" from URLs and such?  Why are people not simply doing:
> > 
> > !bk send -r+ (other options) -
> > 
> > from within their editor (or equivalent) to inline the CSET in the email?
> > This has the added advantage that other people reading the email can also
> > import the CSET immediately if they so desire.
> 
> 'bk pull' is probably most useful to high volume submitters, where the
> contents of most patches is either obvious and/or uninteresting.

The problem is that (AFAIK) bk pull does not let Linus pick-and-choose
which patches he wants to accept as easily as importing them at the time
he reads each email.  It basically assumes that he wants everything that
is in the repository he is pulling from.

> 'bk send -d -r<rev> -' should be fine for importing.

Yes, that would be my thought as well.  Sadly, running the command

bk send -d -r+ -wgzip_uu -

does not work as I would _hope_ it would, namely putting a regular context
diff at the beginning of the email, and gzip_uu for only the CSET.  That
would give us the best of both worlds, namely a diff to look at (which
most people can read easily), and the compressed CSET for people who
have BK.

I suppose it is possible to do exactly what I want by running both:

bk changes -r<rev>			# generates Changelog
bk export -tpatch -h -du -r<rev>	# generates context diff
bk send -wgzip_uu -r<rev> -		# generates gzipped/uuencoded CSET

This has the added benefit that 'bk export' does not contain changes to
the BK files themselves, only the real changes.

I have no idea if this would confuse BK if you tried to recieve from
a file which had both of these in it...

> But this is still a trial run of BK, so who knows what will wind up to
> be the best policy for casual submitters.
> 
> And there's nothing wrong at all with sending GNU patches...

Oh, I agree that for people without BK they can keep sending patches.
I would prefer that people who _do_ have BK to send the CSET along with
the patch to the mailing list so that you don't have to go hunting for a
specific CSET, or if you can't because you are not currently connected.

This might also be possible if BK could export/import a whole changeset
in patch form, plus some magic stuff at the beginning/end (gzip_uu) which
had all of the BK metadata in it, but I don't know if that is possible or
desirable.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: [bk patch] Make cardbus compile in -pre4

[Larry McVoy]

On Sat, Feb 09, 2002 at 12:29:20AM -0700, Andreas Dilger wrote:
> Yes, that would be my thought as well.  Sadly, running the command
> 
> bk send -d -r+ -wgzip_uu -
> 
> does not work as I would _hope_ it would, namely putting a regular context
> diff at the beginning of the email, and gzip_uu for only the CSET.  

Whoops, that's a bug.  Type "bk sendbug" and send us a bug report, we'll
fix it.  Sorry about that.

> > But this is still a trial run of BK, so who knows what will wind up to
> > be the best policy for casual submitters.
> > 
> > And there's nothing wrong at all with sending GNU patches...
> 
> Oh, I agree that for people without BK they can keep sending patches.

It occurs to me that there is no reason you can't generate a regular
patch from BK and mail it to the list w/ the changeset comments.  That
keeps all the non-BK users perfectly happy, nothing has changed for
them and they can use BK or not as they see fit.  In addition, you can
send off a BK patch to Linus and/or stuff a patch into a publicly
available BK tree and point him at it.

If you all can reach any sort of concensus on what is a pleasant patch
format for non-BK users, just tell me, and I'll make sure BK can generate
that sort of patch easily.

> This might also be possible if BK could export/import a whole changeset
> in patch form, plus some magic stuff at the beginning/end (gzip_uu) which
> had all of the BK metadata in it, but I don't know if that is possible or
> desirable.

Well, send -d is essentially that - it's two patches, a GNU patch and a
BK patch.  It was a mistake for us to wrap the whole thing, we should
leave the regular diffs alone and just wrap the BK stuff.  We can do
that.  
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: [bk patch] Make cardbus compile in -pre4

[Jeff Garzik]

Andreas Dilger wrote:
> The problem is that (AFAIK) bk pull does not let Linus pick-and-choose
> which patches he wants to accept as easily as importing them at the time
> he reads each email.  It basically assumes that he wants everything that
> is in the repository he is pulling from.

Yes and no.  'bk pull' does indeed make the presumption that Linus will
like or dislike the entire patchset being pulled.  That's why one wants
to separate different types of changes into different BK trees.  For
example you might have a BK clone with just ext2 fixes, then a BK clone
off of your ext2-fixes tree which contains your ext2 resize work.  Or,
if you wanted those separate and not parent-child, you could clone both
ext2-fixes and ext2-resize trees off of Linus's standard tree.

But I disagree a bit.  Basically, if you organize the trees from which
Linus would do a 'bk pull' then he can easily (a) 'bk unpull' if he
dislikes everything, and (b) easily inspect each changeset.

I personally plan on sending Linus GNU patches simply for his review, as
I did with the recent swap_device cleanup patch, as well as giving him a
location for doing the 'bk pull'.  In that specific case, there was a
tree http://gkernel.bkbits.net/vm-2.5 which contained nothing but that
one change.

Used in this sense, 'bk pull' is really the primary merging tool, and
e-mail is simply a reminder to Linus that he should do a pull.

	Jeff



-- 
Jeff Garzik      | "I went through my candy like hot oatmeal
Building 1024    |  through an internally-buttered weasel."
MandrakeSoft     |             - goats.com

Re: [bk patch] Make cardbus compile in -pre4

[Linus Torvalds]

In article <20020209002920.Z15496@lynx.turbolabs.com>,
Andreas Dilger  <adilger@turbolabs.com> wrote:
>
>The problem is that (AFAIK) bk pull does not let Linus pick-and-choose
>which patches he wants to accept as easily as importing them at the time
>he reads each email.  It basically assumes that he wants everything that
>is in the repository he is pulling from.

Yes and no.

I hope that the developers that I work enough with for it to matter tend
to be fairly good at keeping things separate (ie separate BK trees for
different development efforts etc), in which case it's not a big issue.

And yes, from at least one developer I have already done a partial pull,
ie taken only partial changes. In that case the changes I disagreed with
were at the end, so it was easy enough to just do a "bk pull" into
another tree, do a "bk undo", and only merge after that.

But I agree - if I end up having to do that more than occasionally, I'm
going to ask that developer to stop using bk at least as far as I'm
concerned (ie he can use bk for himself, but I wouldn't accept bk
patches from developers who cannot keep their stuff cleanly separated).

		Linus

Re: [bk patch] Make cardbus compile in -pre4

[Andreas Dilger]

Linus Torvalds <torvalds@transmeta.com> writes:
> from at least one developer I have already done a partial pull,
> ie taken only partial changes. In that case the changes I disagreed with
> were at the end, so it was easy enough to just do a "bk pull" into
> another tree, do a "bk undo", and only merge after that.
> 
> But I agree - if I end up having to do that more than occasionally, I'm
> going to ask that developer to stop using bk at least as far as I'm
> concerned (ie he can use bk for himself, but I wouldn't accept bk
> patches from developers who cannot keep their stuff cleanly separated).

What about BK CSET (or regular patch) submissions from non-core
developers?  Would you accept CSETs via email if they are preceeded
by a unified diff and explanation?  This would make it much easier
for any non-core developer to avoid having to re-sync their changes
with you if/when you accept that change into your tree.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: [bk patch] Make cardbus compile in -pre4

[Linus Torvalds]

On Sun, 10 Feb 2002, Andreas Dilger wrote:
>
> What about BK CSET (or regular patch) submissions from non-core
> developers?  Would you accept CSETs via email if they are preceeded
> by a unified diff and explanation?

What's the difference here with "bk send"?

I have worked with a few BK patches in email, and I have to say that I
pretty much detest them. The less I have to work with them, the better,
although that may just because I don't yet have the same kind of
infrastructure for them as I have for regulat patches.

Making the infrastructure is not that hard, so if people start sending me
bk patches by email, I can improve it, and I'll probably not dislike bk
send as much as I do now.

(But _please_ do a "bk send" to a file, and edit the file before you send
it, instead of sending directly with that "Bitkeeper patch" subject line.
It looks like "bk send" was really designed for automatic merges, not for
humans)

		Linus

Re: [bk patch] Make cardbus compile in -pre4

[Andreas Dilger]

On Feb 10, 2002  12:57 -0800, Linus Torvalds wrote:
> On Sun, 10 Feb 2002, Andreas Dilger wrote:
> > What about BK CSET (or regular patch) submissions from non-core
> > developers?  Would you accept CSETs via email if they are preceeded
> > by a unified diff and explanation?
> 
> I have worked with a few BK patches in email, and I have to say that I
> pretty much detest them. The less I have to work with them, the better,
> although that may just because I don't yet have the same kind of
> infrastructure for them as I have for regulat patches.
>
> (But _please_ do a "bk send" to a file, and edit the file before you send
> it, instead of sending directly with that "Bitkeeper patch" subject line.
> It looks like "bk send" was really designed for automatic merges, not for
> humans)

Yes, the first time I used "bk send" to send something directly to Ted it
happened that I was offline so I looked into my mail spool at the emails
and also hated it.  What I was proposing instead of just "bk send" is to
prepend the changelog entry, a real unified diff, and gzip_uu CSET at the
end.  Larry has agreed that "bk send -d -wgzip_uu" wrapping the diff part
of the patch is a bug to be fixed.

So, instead of the current layout of "'This is a BitKeeper patch' comment +
commented-out diff + BK stuff", I would send "CSET ChangeLog + unified diff +
gzip_uu wrapped BK stuff".  This would be the output of (probably in a script):

bk changes -r<rev>
bk export -tpatch -h -du -r<rev>
bk send -wgzip_uu -r<rev> -

For example, your recent 2.5.4 release would look like the below, and I
_think_ you could just accept this with "bk receive -a [repository path]",
but I'm not sure how good the BK heuristics are for finding a CSET at the
end of a long patch.  I'm only skeptical because the current "bk send"
output comments out the diff part of the output.

ChangeSet@1.262, 2002-02-10 19:24:03-08:00, torvalds@home.transmeta.com
  update version
  TAG: v2.5.4

diff -Nru a/Makefile b/Makefile
--- a/Makefile	Mon Feb 11 10:44:32 2002
+++ b/Makefile	Mon Feb 11 10:44:32 2002
@@ -1,7 +1,7 @@
 VERSION = 2
 PATCHLEVEL = 5
 SUBLEVEL = 4
-EXTRAVERSION =-pre6
+EXTRAVERSION =
 
 KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)
 
This BitKeeper patch contains the following changesets:
1.262
## Wrapped with gzip_uu ##


begin 664 bkpatch3560
M'XL(`!\#:#P``[V4T6[;(!2&K\-3(/5RLG,.!H(M>5K71ENU=8V<==HMLFEL
MU;$K0[)6\L./6%U255.R1-LP<,'!1X?OY^>,WEK3)2-=5/7"=.2,?FRM2T;U
M4_,8/B^&5>-\(&M;'QBO;#>V73ZNJV;U&+!0$!^;:9>7=&TZFXPPC+8K[NG!
M)*-L^N'V\WE&2)K2BU(W"S,WCJ8I<6VWUG5AWVE7UFT3NDXW=FF<#O-VV6^W
M]@R`^4_@)`(A>Y3`)WV.!:+F:`I@7$F^RU:V2W,@%R(@CQGO47$AR"7%D$E&
M@8U]1Z`8)XPG$`6@$@"Z)S5]@S0`\I[^W<-<D)RN'@KMS("U:AORB?IBN2*S
M'402'-D(`0WD[8%BK_6]N:MJ\[+6.%(]@)K(OI"ZB'/4JA"QT&(?G->9//:(
M<8AZ%))+<JQDS_\.%*Y_+QF*/Y$,_H5D+W69T[6W1LB)I0L_:C^./2LJ$)ZX
M;R>HO+':+_:'G7:4WGM%>ZVWG[B*X@VR"1MLAE*=;#/\3S8;+N<-#;H?0_=`
M9UN:)XAQR2F2J\TT_?XU._\VS>97-U]HNGLY\]+D]W:U3/%.<B5B)#\!WOU:
%+9D%````
`
end



Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: [bk patch] Make cardbus compile in -pre4

[Larry McVoy]

On Fri, Feb 08, 2002 at 08:39:31PM -0700, Andreas Dilger wrote:
> On Feb 08, 2002  18:25 -0800, Patrick Mochel wrote:
> > (I don't have a public repository yet, so there's no place to pull form)

Read the second half below to see how to get one.

> I don't see why everyone who is using BK is expecting Linus to do a pull.

For one, he seems to like that model, if the data is in a well known
place, he can pull it when he is ready.  Makes it easy for him to not
worry about whether he has all the stuff Jeff wants to give him, pull
either says there is nothing to do or it doesn't.

The other issue is that if you do the "bk send -r+" thing, that assumes
that the receiver has the parent of the most recent change.  The patch
will not apply otherwise.  This is one difference between BK & diff/patch.
diff/patch will work in more cases, BK is insistent that the receiver has
everything that the sender had except the data sent.  So if you let Linus
pull from a known place then you know he can apply your patch using BK,
if you don't, then he might be able to apply your patch.

On to the "known place" issue.  One problem people have is having a
place to stash this stuff.  Since BK is a replicating system, you can
have the same data in lots of different places, like your laptop, your
home machine, work machine, whatever, but you need a place that other
people can pull from that is always there.  Anyone can install BK, read
the bkd man page and set up such a place.  For those people who either
don't want to do that, or don't have a place where they can run a BKD,
or they don't trust the BKD software to be secure, or whatever, we've set
up bkbits.net, it's somewhat like sourceforge but right now, at least,
mostly intended for the benefit of the kernel team.  We originally set it
up for the PPC team but anyone can stash a copy of their repository there.

To get the model, think of this as a staging area.  You don't work there,
you don't use that system to do your patches or really do very much at
all.  You work where you work right now.  Make your stuff work, test it
out, and when you are ready, push a copy of it up to bkbits.net and send
out mail.  People can go look at the changelogs, see the diffs, pull the
changes using BK, etc.  And Jeff asked for URL format that he can post 
so you can do a

	wget <URL> 

and you have the patch described in his posting.  That should keep the
non-BK users happy, in essense the BK users are adding the data and
BK may be viewed as a patchbot.  For those who don't like the license
or for whatever reason just like plain patches better, they can slurp
down the patches any time they want.

If you want to get a project space up there, send mail to
support@bitmover.com and we'll send you instructions, it's pretty easy
to set up, you log in and pick a name and add your identity.pub and
you're all set.  There is a little admin shell you can use to populate
your repository.  Then you may push your patches there and point Linus
at them and hope he pulls them.  I can see that in short order Linus
is going to be asking for the "show me everything I don't have on one
web page" tool, but that's cool, we've been meaning to build that one
for a while.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: [bk patch] Make cardbus compile in -pre4

[Andrew Morton]

Larry McVoy wrote:
> 
> On Fri, Feb 08, 2002 at 08:39:31PM -0700, Andreas Dilger wrote:
> > On Feb 08, 2002  18:25 -0800, Patrick Mochel wrote:
> > > (I don't have a public repository yet, so there's no place to pull form)
> 
> Read the second half below to see how to get one.
> 
> > I don't see why everyone who is using BK is expecting Linus to do a pull.
> 
> For one, he seems to like that model,

Well I don't.  I'd like to see as many kernel changes as possible
sent to this mailing list, as unified diffs, with an explanation.

-

Re: [bk patch] Make cardbus compile in -pre4

[Rob Landley]

On Saturday 09 February 2002 12:32 am, Andrew Morton wrote:
> Larry McVoy wrote:
> > For one, he seems to like that model,
>
> Well I don't.  I'd like to see as many kernel changes as possible
> sent to this mailing list, as unified diffs, with an explanation.

I personally hope one of the patchbot projects (patches-only lists, 
filtered/moderated) gets mature enough to use soon.

Optimizing the bandwidth of Linus and optimizing for the rest of the 
developer community are two seperate problems which may require two seperate 
toolchains.  Posting a patch to the list already isn't enough to get it to 
Linus.  Hasn't been for a while...

Rob

Re: [bk patch] Make cardbus compile in -pre4

[Momchil Velikov]

>>>>> "Rob" == Rob Landley <landley@trommello.org> writes:

Rob> Optimizing the bandwidth of Linus and optimizing for the rest of the 
Rob> developer community are two seperate problems which may require two seperate 
Rob> toolchains.  Posting a patch to the list already isn't enough to get it to 
Rob> Linus.  Hasn't been for a while...

Yeah, right, and now people hope that commiting to some obscure
repository will be enough get it to Linus ?

Lemme tell ya, the result is that it won't get not only to Linus, but
to the majority of the community.

Sorry, hoping that some _tool_ will solve the (supposed) problems in
the kernel development is just plain stupid.

Regards,
-velco

PS. Interesting trend to note is the usually the amount of whining is
inversely proportional to one's contribution to the kernel.

Re: [bk patch] Make cardbus compile in -pre4

[Alexander Viro]

On 9 Feb 2002, Momchil Velikov wrote:

> PS. Interesting trend to note is the usually the amount of whining is
> inversely proportional to one's contribution to the kernel.

<pedantic> to (constant + one's contribution to the kernel).  After all,
Rob has only finite bandwidth.  </pedantic>

Re: [bk patch] Make cardbus compile in -pre4

[Rob Landley]

On Saturday 09 February 2002 05:01 am, Alexander Viro wrote:
> On 9 Feb 2002, Momchil Velikov wrote:
> > PS. Interesting trend to note is the usually the amount of whining is
> > inversely proportional to one's contribution to the kernel.
>
> <pedantic> to (constant + one's contribution to the kernel).  After all,
> Rob has only finite bandwidth.  </pedantic>

And here I thought I was still in Al's killfile... :)

Rob

Re: [bk patch] Make cardbus compile in -pre4

[Daniel Phillips]

On February 9, 2002 10:57 am, Momchil Velikov wrote:
> PS. Interesting trend to note is the usually the amount of whining is
> inversely proportional to one's contribution to the kernel.

Complaining and whining are not the same thing.  Some major contributors
have complained, that's why Linus takes this seriously.

-- 
Daniel

Re: [bk patch] Make cardbus compile in -pre4

[Linus Torvalds]

In article <E16ZZ7M-0007Y7-00@starship.berlin>,
Daniel Phillips  <phillips@bonn-fries.net> wrote:
>
>Complaining and whining are not the same thing.  Some major contributors
>have complained, that's why Linus takes this seriously.

Well, in all honesty, it's not so much that I take it seriously - it's
not as if the complaints are in any way new (or even more serious than
before - I think we had a much more serious spat a few years ago).  The
fact is, people will _always_ complain about the way things are done.

[ This very _same_ "how to maintain" flameware is not only a regular
  topic on linux-kernel, it's a regular topic on the BSD lists, on the
  gcc lists, and probably on every single bigger software project,
  whether open source or not. Why do you think there are so many
  different source control packages? ;]

But I _have_ promised Larry for the last two years or so to give BK a
chance (the last time I promised him I'd start using it as of 2.5.0),
and the discussion to a large degree just made me feel I had a good
reason to take a week off and try it out. 

I doubt bk per se will really change any of the real issues.  It will
almost certainly make it somewhat easier to merge patches from some
people, but I also suspect that those are largely the same people that I
already was pretty good at merging patches from before. 

The fundamental issue that I think I (or any human, for that matter)
work best with just a few (on the order of ten) closer contacts, and
that I want people to "network" more is pretty independent of BK or not.

However, in the long run what BK may do is to make it easier to migrate
to a "group model", where the traditional "linus tree" doesn't even
exist any more. I'm not ready to do that yet, but clearly it has to
happen at _some_ point. Nobody lives forever.

And I do like BK so far.

			Linus

Re: [bk patch] Make cardbus compile in -pre4

[David Lang]

and if you keep doing this you will also need to cleanup and implement the
'hardlink for identical files' idea that was batted around a year or so
ago, otherwise with all the copies of the linus tree with a few K of
patches from different developers you'll start to notice the storage space
used, even at today's drive prices :-)

David Lang

 On Fri, 8 Feb 2002, Larry McVoy wrote:

> Date: Fri, 8 Feb 2002 21:12:57 -0800
> From: Larry McVoy <lm@bitmover.com>
> To: Patrick Mochel <mochel@osdl.org>, linux-kernel@vger.kernel.org
> Subject: Re: [bk patch] Make cardbus compile in -pre4
>
> On Fri, Feb 08, 2002 at 08:39:31PM -0700, Andreas Dilger wrote:
> > On Feb 08, 2002  18:25 -0800, Patrick Mochel wrote:
> > > (I don't have a public repository yet, so there's no place to pull form)
>
> Read the second half below to see how to get one.
>
> > I don't see why everyone who is using BK is expecting Linus to do a pull.
>
> For one, he seems to like that model, if the data is in a well known
> place, he can pull it when he is ready.  Makes it easy for him to not
> worry about whether he has all the stuff Jeff wants to give him, pull
> either says there is nothing to do or it doesn't.
>
> The other issue is that if you do the "bk send -r+" thing, that assumes
> that the receiver has the parent of the most recent change.  The patch
> will not apply otherwise.  This is one difference between BK & diff/patch.
> diff/patch will work in more cases, BK is insistent that the receiver has
> everything that the sender had except the data sent.  So if you let Linus
> pull from a known place then you know he can apply your patch using BK,
> if you don't, then he might be able to apply your patch.
>
> On to the "known place" issue.  One problem people have is having a
> place to stash this stuff.  Since BK is a replicating system, you can
> have the same data in lots of different places, like your laptop, your
> home machine, work machine, whatever, but you need a place that other
> people can pull from that is always there.  Anyone can install BK, read
> the bkd man page and set up such a place.  For those people who either
> don't want to do that, or don't have a place where they can run a BKD,
> or they don't trust the BKD software to be secure, or whatever, we've set
> up bkbits.net, it's somewhat like sourceforge but right now, at least,
> mostly intended for the benefit of the kernel team.  We originally set it
> up for the PPC team but anyone can stash a copy of their repository there.
>
> To get the model, think of this as a staging area.  You don't work there,
> you don't use that system to do your patches or really do very much at
> all.  You work where you work right now.  Make your stuff work, test it
> out, and when you are ready, push a copy of it up to bkbits.net and send
> out mail.  People can go look at the changelogs, see the diffs, pull the
> changes using BK, etc.  And Jeff asked for URL format that he can post
> so you can do a
>
> 	wget <URL>
>
> and you have the patch described in his posting.  That should keep the
> non-BK users happy, in essense the BK users are adding the data and
> BK may be viewed as a patchbot.  For those who don't like the license
> or for whatever reason just like plain patches better, they can slurp
> down the patches any time they want.
>
> If you want to get a project space up there, send mail to
> support@bitmover.com and we'll send you instructions, it's pretty easy
> to set up, you log in and pick a name and add your identity.pub and
> you're all set.  There is a little admin shell you can use to populate
> your repository.  Then you may push your patches there and point Linus
> at them and hope he pulls them.  I can see that in short order Linus
> is going to be asking for the "show me everything I don't have on one
> web page" tool, but that's cool, we've been meaning to build that one
> for a while.
> --
> ---
> Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: [bk patch] Make cardbus compile in -pre4

[Larry McVoy]

On Sat, Feb 09, 2002 at 02:14:52AM -0800, David Lang wrote:
> and if you keep doing this you will also need to cleanup and implement the
> 'hardlink for identical files' idea that was batted around a year or so
> ago, otherwise with all the copies of the linus tree with a few K of
> patches from different developers you'll start to notice the storage space
> used, even at today's drive prices :-)

bk clone -l
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: [bk patch] Make cardbus compile in -pre4

[Tom Rini]

On Sat, Feb 09, 2002 at 07:54:25AM -0800, Larry McVoy wrote:
> On Sat, Feb 09, 2002 at 02:14:52AM -0800, David Lang wrote:
> > and if you keep doing this you will also need to cleanup and implement the
> > 'hardlink for identical files' idea that was batted around a year or so
> > ago, otherwise with all the copies of the linus tree with a few K of
> > patches from different developers you'll start to notice the storage space
> > used, even at today's drive prices :-)
> 
> bk clone -l

Erm:
$ bk version
BitKeeper/Free version is bk-2.1.4 20020205155016 for x86-glibc22-linux
Built by: lm@redhat71.bitmover.com in /build/bk-2.1.x-lm/src
Built on: Tue Feb  5 08:01:19 PST 2002
$ bk clone -l
usage:  bk clone [-ql] [-E<env>=<val>] [-r<rev>] [-z[<d>]] <from> [<to>]

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: [bk patch] Make cardbus compile in -pre4

[Larry McVoy]

> > bk clone -l
> 
> $ bk version
> BitKeeper/Free version is bk-2.1.4 20020205155016 for x86-glibc22-linux
> Built by: lm@redhat71.bitmover.com in /build/bk-2.1.x-lm/src
> Built on: Tue Feb  5 08:01:19 PST 2002
> $ bk clone -l
> usage:  bk clone [-ql] [-E<env>=<val>] [-r<rev>] [-z[<d>]] <from> [<to>]

Tom, I can't believe you are running that ancient version of BK, why it is
already 4 days old!  Try and stay current :-)

There is a 2.1.4b release that has clone -l in it, along with some rollup
fixes/enhancements for Linus.

There is an undocumented version of clone -l in your release which works like

	bk lclone from to

and does the hardlinks.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: [bk patch] Make cardbus compile in -pre4

[David Lang]

do you have a script that can go back after the fact and see what can be
hardlinked?

I'm thinking specififcly of the type of thing that will be happening to
your server where you have a bunch of people putting in a clone of one
tree who will probably not be doing a clone -l to set it up, but who could
have and you want to clean up after the fact (and perhapse again on a
periodic basis, becouse after all of these trees apply a changeset from
linus they will all have changed (breaking the origional hardlinks) but
will still be duplicates of each other.

David Lang


On Sat, 9 Feb 2002, Larry McVoy wrote:

> Date: Sat, 9 Feb 2002 09:05:27 -0800
> From: Larry McVoy <lm@bitmover.com>
> To: Tom Rini <trini@kernel.crashing.org>
> Cc: David Lang <dlang@diginsite.com>, Larry McVoy <lm@bitmover.com>,
>      Patrick Mochel <mochel@osdl.org>, linux-kernel@vger.kernel.org
> Subject: Re: [bk patch] Make cardbus compile in -pre4
>
> > > bk clone -l
> >
> > $ bk version
> > BitKeeper/Free version is bk-2.1.4 20020205155016 for x86-glibc22-linux
> > Built by: lm@redhat71.bitmover.com in /build/bk-2.1.x-lm/src
> > Built on: Tue Feb  5 08:01:19 PST 2002
> > $ bk clone -l
> > usage:  bk clone [-ql] [-E<env>=<val>] [-r<rev>] [-z[<d>]] <from> [<to>]
>
> Tom, I can't believe you are running that ancient version of BK, why it is
> already 4 days old!  Try and stay current :-)
>
> There is a 2.1.4b release that has clone -l in it, along with some rollup
> fixes/enhancements for Linus.
>
> There is an undocumented version of clone -l in your release which works like
>
> 	bk lclone from to
>
> and does the hardlinks.
> --
> ---
> Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm
>

Re: [bk patch] Make cardbus compile in -pre4

[Larry McVoy]

On Sat, Feb 09, 2002 at 01:01:34PM -0800, David Lang wrote:
> do you have a script that can go back after the fact and see what can be
> hardlinked?
> 
> I'm thinking specififcly of the type of thing that will be happening to
> your server where you have a bunch of people putting in a clone of one
> tree who will probably not be doing a clone -l to set it up, but who could
> have and you want to clean up after the fact (and perhapse again on a
> periodic basis, becouse after all of these trees apply a changeset from
> linus they will all have changed (breaking the origional hardlinks) but
> will still be duplicates of each other.

We don't, but we can, and we should.  "bk relink tree1 tree2" seems like 
the right interface.

Right now we aren't too worried about the disk space, the data is sitting 
on a pair of 40GB drives and we're running the trees in gzip mode, so they
are 75MB each.  But yes, it's a good idea, we should do it, and probably
should figure out some way to make it automatic.  I'll add it to the
(ever growing) list, thanks.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: [bk patch] Make cardbus compile in -pre4

[Andreas Dilger]

On Feb 09, 2002  13:41 -0800, Larry McVoy wrote:
> We don't, but we can, and we should.  "bk relink tree1 tree2" seems like 
> the right interface.

Yes, this would be great.  It should probably only do this for files in
SCCS and BitKeeper directories, because vim (for example) will do the
wrong thing with hard-linked files if you edit them.  Maybe there could
be another option which would relink all of the checked-out files as well,
for people who use emacs?

> Right now we aren't too worried about the disk space, the data is sitting 
> on a pair of 40GB drives and we're running the trees in gzip mode, so they
> are 75MB each.  But yes, it's a good idea, we should do it, and probably
> should figure out some way to make it automatic.  I'll add it to the
> (ever growing) list, thanks.

One thing that I've noticed (got my first linux-2.5 clone last night) is
that the kernel build process is somewhat broken by the fact that not
everything that you need to build is checked out of the repository by
make.

It appears to handle .c files ok, but it failed for all of the .h files.
I take it this means that gcc doesn't know anything about SCCS, and it
would also appear that make is not properly checking dependencies for
these files, or it would have checked them out, right?

Also, things like "make menuconfig" and such also fail (because they are
doing stuff within scripts that have no concept of SCCS or BK).  Will
the new kernel build system take any of this into account?

I would prefer if we only checked out as much as we need (instead of
doing something like 'bk -r edit' which will use up a lot of space in
each clone for architectures and drivers which I don't need).

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: [bk patch] Make cardbus compile in -pre4

[Tom Rini]

On Sat, Feb 09, 2002 at 04:36:03PM -0700, Andreas Dilger wrote:
 
> One thing that I've noticed (got my first linux-2.5 clone last night) is
> that the kernel build process is somewhat broken by the fact that not
> everything that you need to build is checked out of the repository by
> make.
> 
> It appears to handle .c files ok, but it failed for all of the .h files.
> I take it this means that gcc doesn't know anything about SCCS, and it
> would also appear that make is not properly checking dependencies for
> these files, or it would have checked them out, right?

It's a 'feature' of the dependancy setup of the kernel.  bk -r get -q
will checkout all of the files everywhere, and the build _should_ work
(there's been times autogenerated files were in the kernel and thus
broke building from a bk repo).

> Also, things like "make menuconfig" and such also fail (because they are
> doing stuff within scripts that have no concept of SCCS or BK).  Will
> the new kernel build system take any of this into account?

I don't think they do now, but it wouldn't be too hard I'd think.  If of
course the files needed to build/run the tools get checked out :)

> I would prefer if we only checked out as much as we need (instead of
> doing something like 'bk -r edit' which will use up a lot of space in
> each clone for architectures and drivers which I don't need).

Don't -r edit, -r get.  You can go and selectively clean out some dirs,
but in short, no.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: [bk patch] Make cardbus compile in -pre4

[Andreas Dilger]

On Feb 09, 2002  16:45 -0700, Tom Rini wrote:
> On Sat, Feb 09, 2002 at 04:36:03PM -0700, Andreas Dilger wrote:
> > One thing that I've noticed (got my first linux-2.5 clone last night) is
> > that the kernel build process is somewhat broken by the fact that not
> > everything that you need to build is checked out of the repository by
> > make.
> > 
> > It appears to handle .c files ok, but it failed for all of the .h files.
> > I take it this means that gcc doesn't know anything about SCCS, and it
> > would also appear that make is not properly checking dependencies for
> > these files, or it would have checked them out, right?
> 
> It's a 'feature' of the dependancy setup of the kernel.  bk -r get -q
> will checkout all of the files everywhere, and the build _should_ work
> (there's been times autogenerated files were in the kernel and thus
> broke building from a bk repo).

Well, I looked at it some more, and "make dep" was totally broken
until I "bk get" the headers.  All of the .depend files were empty,
probably because "make dep" couldn't find/read any files.  It may
be enough to fix this by having "make dep" do something to "bk get"
each file if it is not there.  It still appears to be a bit of
a problem, because before you do "bk get", "find" does not return any
files for mkdep to look at, a bit of chicken-and-egg problem there.

We could also try to "make" each header file, because make is smart
enough to handle SCCS/BK, CVS, etc so we won't be putting BK-specific
knowledge into the make system (try "make -d include/linux/fs.h").  I
don't know for sure, since I've never worked with the build system much.

> > I would prefer if we only checked out as much as we need (instead of
> > doing something like 'bk -r edit' which will use up a lot of space in
> > each clone for architectures and drivers which I don't need).
> 
> Don't -r edit, -r get.

Well, write bits don't take up any space.  While I can alias vi='bk vim'
to check out a particular file for editing, VIM is not smart enough (or
I don't know how to configure it) to check out files for editing if I
open them from within the editor or use tags to jump to the file.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: [bk patch] Make cardbus compile in -pre4

[Larry McVoy]

On Sat, Feb 09, 2002 at 04:36:03PM -0700, Andreas Dilger wrote:
> On Feb 09, 2002  13:41 -0800, Larry McVoy wrote:
> > We don't, but we can, and we should.  "bk relink tree1 tree2" seems like 
> > the right interface.
> 
> Yes, this would be great.  It should probably only do this for files in
> SCCS and BitKeeper directories, because vim (for example) will do the

Correct.

> One thing that I've noticed (got my first linux-2.5 clone last night) is
> that the kernel build process is somewhat broken by the fact that not
> everything that you need to build is checked out of the repository by
> make.
> 
> It appears to handle .c files ok, but it failed for all of the .h files.

This is because the dependencies are incorrect in the makefiles.  If you
have correct dependencies in the makefiles, make will do the right thing.

One alternative would be to have a scripts/bk-get which takes as an arg
the architecture[s] you want and gets the files that make sense for
that architecture.  That would help somewhat.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: [bk patch] Make cardbus compile in -pre4

[Linus Torvalds]

In article <20020209155258.E18734@work.bitmover.com>,
Larry McVoy  <lm@bitmover.com> wrote:
>
>This is because the dependencies are incorrect in the makefiles.  If you
>have correct dependencies in the makefiles, make will do the right thing.

Modulo bugs.

For some reason, on my work machine, "make" will not correctly check out
files that are "include"d from the makefile.

On my home machine, it will.

The really interesting thing is, they're both make 3.79.1.

Besides, I'd at least personally rather do "bk -r get -q" than have to
watch those SCCS files and BitKeeper files. That way the filename
completion works inside the shell too..

			Linus

Re: [bk patch] Make cardbus compile in -pre4

[Tom Rini]

On Sat, Feb 09, 2002 at 03:52:58PM -0800, Larry McVoy wrote:
> On Sat, Feb 09, 2002 at 04:36:03PM -0700, Andreas Dilger wrote:
> > On Feb 09, 2002  13:41 -0800, Larry McVoy wrote:
> > > We don't, but we can, and we should.  "bk relink tree1 tree2" seems like 
> > > the right interface.
> > 
> > Yes, this would be great.  It should probably only do this for files in
> > SCCS and BitKeeper directories, because vim (for example) will do the
> 
> Correct.
> 
> > One thing that I've noticed (got my first linux-2.5 clone last night) is
> > that the kernel build process is somewhat broken by the fact that not
> > everything that you need to build is checked out of the repository by
> > make.
> > 
> > It appears to handle .c files ok, but it failed for all of the .h files.
> 
> This is because the dependencies are incorrect in the makefiles.  If you
> have correct dependencies in the makefiles, make will do the right thing.

Or more specifically, the 'dependancy' stage of the kernel knows
_nothing_ about SCCS.  It _might_ not be that hard to hack up the
scripts/mkdep.c program to check if an #include'd file exists (and if it
doesn't, if (any search patch)/SCCS exists, and if so, get it.

> One alternative would be to have a scripts/bk-get which takes as an arg
> the architecture[s] you want and gets the files that make sense for
> that architecture.  That would help somewhat.

If it's just a flat list of files, it'd be rather hellish to maintain
I'd think.  It _might_ not be too horrible to try and glean files from
CONFIG options (but isn't part of the point of the kernel's current dep
system to not depend on CONFIG_xxx options?) and assume all of include/
is needed.

Or kbuild-2.5 might just work since it does deps in a more 'correct'
manner.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: [bk patch] Make cardbus compile in -pre4

[William Stearns]

Good day, Larry,

On Sat, 9 Feb 2002, Larry McVoy wrote:

> On Sat, Feb 09, 2002 at 01:01:34PM -0800, David Lang wrote:
> > do you have a script that can go back after the fact and see what can be
> > hardlinked?
> > 
> > I'm thinking specififcly of the type of thing that will be happening to
> > your server where you have a bunch of people putting in a clone of one
> > tree who will probably not be doing a clone -l to set it up, but who could
> > have and you want to clean up after the fact (and perhapse again on a
> > periodic basis, becouse after all of these trees apply a changeset from
> > linus they will all have changed (breaking the origional hardlinks) but
> > will still be duplicates of each other.
> 
> We don't, but we can, and we should.  "bk relink tree1 tree2" seems like 
> the right interface.
> 
> Right now we aren't too worried about the disk space, the data is sitting 
> on a pair of 40GB drives and we're running the trees in gzip mode, so they
> are 75MB each.  But yes, it's a good idea, we should do it, and probably
> should figure out some way to make it automatic.  I'll add it to the
> (ever growing) list, thanks.

	Larry, I'll save you the time.
	"freedups -a -d /some/dir [/other/dirs]" will look for identical
files (the -d requires dates to be equal as well as the content) and
hardlink them.  It's not terribly efficient, but works marvelously well.  
Run it from cron once a week or so, perhaps?
	http://www.stearns.org/freedups/
	Cheers,
	- Bill

---------------------------------------------------------------------------
        "Patience is a minor form of despair, disguised as virtue."
        -- Ambrose Bierce, on qualifiers
--------------------------------------------------------------------------
William Stearns (wstearns@pobox.com).  Mason, Buildkernel, named2hosts, 
and ipfwadm2ipchains are at:                http://www.pobox.com/~wstearns
LinuxMonth; articles for Linux Enthusiasts! http://www.linuxmonth.com
--------------------------------------------------------------------------

Re: [bk patch] Make cardbus compile in -pre4

[Padraig Brady]

William Stearns wrote:
> Good day, Larry,
> 
> On Sat, 9 Feb 2002, Larry McVoy wrote:
> 
> 
>>On Sat, Feb 09, 2002 at 01:01:34PM -0800, David Lang wrote:
>>
>>>do you have a script that can go back after the fact and see what can be
>>>hardlinked?
>>>
>>>I'm thinking specififcly of the type of thing that will be happening to
>>>your server where you have a bunch of people putting in a clone of one
>>>tree who will probably not be doing a clone -l to set it up, but who could
>>>have and you want to clean up after the fact (and perhapse again on a
>>>periodic basis, becouse after all of these trees apply a changeset from
>>>linus they will all have changed (breaking the origional hardlinks) but
>>>will still be duplicates of each other.
>>>
>>We don't, but we can, and we should.  "bk relink tree1 tree2" seems like 
>>the right interface.
>>
>>Right now we aren't too worried about the disk space, the data is sitting 
>>on a pair of 40GB drives and we're running the trees in gzip mode, so they
>>are 75MB each.  But yes, it's a good idea, we should do it, and probably
>>should figure out some way to make it automatic.  I'll add it to the
>>(ever growing) list, thanks.
>>
> 
> 	Larry, I'll save you the time.
> 	"freedups -a -d /some/dir [/other/dirs]" will look for identical
> files (the -d requires dates to be equal as well as the content) and
> hardlink them.  It's not terribly efficient, but works marvelously well.  
> Run it from cron once a week or so, perhaps?
> 	http://www.stearns.org/freedups/
> 	Cheers,
> 	- Bill


Not terribly efficient? That's a bit of an understatement :-)
The findup component of fslint is MUCH quicker, and it's
also written in bash. A quick test against two 2.4.17 trees gives:

1m36s for  ./findup /usr/src/linux[12] | ./fstool/mergeDup
18m17s for ./freedups -a /usr/src/linux[12]

Note mergeDup was a quick hack and took 1m30s of findup's time!
I'm going to rewrite it in python ASAP to help with this.

You can download the current version of fslint from
http://developers.antefacto.net/~padraig/fslint.tar.gz

Padraig.

Re: [bk patch] Make cardbus compile in -pre4

[Padraig Brady]

Padraig Brady wrote:
> William Stearns wrote:
> 
>> Good day, Larry,
>>
>> On Sat, 9 Feb 2002, Larry McVoy wrote:
>>
>>
>>> On Sat, Feb 09, 2002 at 01:01:34PM -0800, David Lang wrote:
>>>
>>>> do you have a script that can go back after the fact and see what 
>>>> can be
>>>> hardlinked?
>>>>
>>>> I'm thinking specififcly of the type of thing that will be happening to
>>>> your server where you have a bunch of people putting in a clone of one
>>>> tree who will probably not be doing a clone -l to set it up, but who 
>>>> could
>>>> have and you want to clean up after the fact (and perhapse again on a
>>>> periodic basis, becouse after all of these trees apply a changeset from
>>>> linus they will all have changed (breaking the origional hardlinks) but
>>>> will still be duplicates of each other.
>>>>
>>> We don't, but we can, and we should.  "bk relink tree1 tree2" seems 
>>> like the right interface.
>>>
>>> Right now we aren't too worried about the disk space, the data is 
>>> sitting on a pair of 40GB drives and we're running the trees in gzip 
>>> mode, so they
>>> are 75MB each.  But yes, it's a good idea, we should do it, and probably
>>> should figure out some way to make it automatic.  I'll add it to the
>>> (ever growing) list, thanks.
>>>
>>
>>     Larry, I'll save you the time.
>>     "freedups -a -d /some/dir [/other/dirs]" will look for identical
>> files (the -d requires dates to be equal as well as the content) and
>> hardlink them.  It's not terribly efficient, but works marvelously 
>> well.  Run it from cron once a week or so, perhaps?
>>     http://www.stearns.org/freedups/
>>     Cheers,
>>     - Bill
> 
> 
> 
> Not terribly efficient? That's a bit of an understatement :-)
> The findup component of fslint is MUCH quicker, and it's
> also written in bash. A quick test against two 2.4.17 trees gives:
> 
> 1m36s for  ./findup /usr/src/linux[12] | ./fstool/mergeDup
> 18m17s for ./freedups -a /usr/src/linux[12]
> 
> Note mergeDup was a quick hack and took 1m30s of findup's time!
> I'm going to rewrite it in python ASAP to help with this.
> 
> You can download the current version of fslint from
> http://developers.antefacto.net/~padraig/fslint.tar.gz

OK I've updated fslint which can be downloaded @
http://www.iol.ie/~padraiga/fslint/fslint-1.11.tar.gz
To merge 2 linux trees you do: ./findup -m /usr/src/linux[12]
This will take about 37 seconds (note freedups takes 15
minutes to do the same). Note be careful that your editor
handles hardlinked files as you expect.

Padraig.

pull vs push (was Re: [bk patch] Make cardbus compile in -pre4)

[Rob Landley]

On Friday 08 February 2002 10:39 pm, Andreas Dilger wrote:
> On Feb 08, 2002  18:25 -0800, Patrick Mochel wrote:
> > (I don't have a public repository yet, so there's no place to pull form)
>
> I don't see why everyone who is using BK is expecting Linus to do a pull.
> In the non-BK case, wasn't it always a "push" model, and Linus would not
> "pull" from URLs and such?

I'm all for it.  I think it's a good thing.

In the absence of significant latency issues, pull scales better than push.  
It always has.  Push is better in low bandwidth situations with lots of idle 
capacity, but it breaks down when the system approaches saturation.

Pull data is naturally supplied when you're ready for it (assuming no 
significant latency to access it).  Push either scrolls by unread or piles up 
in your inbox and gets buried until it goes stale.  Web pages work on a pull 
model, "push" was an internet fad a few years ago that failed for a reason.  
When push models hit saturation it breaks down and you wind up with the old 
"I love lucy" episode with the chocolate factory.  Back in the days where 
ethernet used hubs instead of switches, going over 50% utilization could lock 
the whole network pretty easily, and these days with switched gigabit 
eithernet you still have network interfaces going into interrupt livelock but 
able to handle a higher load in polling mode.  The Linux scheduler itself 
pulls tasks from a pool of runnable tasks.  If each task had a timer that 
expired generating an interrupt that pushed it to a processor, things 
wouldn't work so well.  (I could go on...)

Linus has actually been using his mailbox to simulate pull by keeping the 
push model at saturation and having repeated retransmits of stuff he expects 
to repeatedly delete until he's ready to reach out and grab it as it passes 
by when the time is right.  The flood he's plucking stuff from is his inbox 
instead of the internet, but the fact remains 90% of it flows by unread 
(wasting attention to delete it, a small amount but it adds up), and isn't 
guaranteed to be there when he IS ready for it.

Humans naturally work by pull.  It just works better to grab stuff out of the 
fridge when you're hungry instead of having it crammed down your throat at 
random.  Push winds up going into a buffer which we pull from (which is how 
mail works), and if that buffer overflows during load spikes, or is just 
constantly filling faster than it drains in the long term, then you wind up 
retransmitting stuff that got dropped (increasing the bandwidth usage) and it 
all just falls apart...

Years ago, Linus wasn't regularly at saturation, so push was fine.  (Optimal 
even: interrupts are better than polling up until you approach livelock.)  
And with Linus's previous toolset, grabbing code from URLs was a significant 
interruption in his workflow, hence a bad thing.  But with bitkeeper, it 
isn't.  And if Linus is going to focus on taking the bulk of new patches from 
a dozen or so trusted lieutenants anyway, it makes sense for them to give him 
the option of a pull model.

I'd encourage this trend.  If in the future linus pulls from lieutenants and 
lieutenants pull from maintainers, the dropped patches problem basically goes 
away.  Just make sure that when the level above you IS ready to take it from 
your level, it's there and ready for them...

Rob

Standard disclaimer: it's 4:30am, who knows how much sense this will make in 
the morning? :)

Re: pull vs push (was Re: [bk patch] Make cardbus compile in -pre4)

[Andreas Dilger]

On Feb 09, 2002  04:27 -0500, Rob Landley wrote:
> On Friday 08 February 2002 10:39 pm, Andreas Dilger wrote:
> > I don't see why everyone who is using BK is expecting Linus to do a pull.
> > In the non-BK case, wasn't it always a "push" model, and Linus would not
> > "pull" from URLs and such?
> 
> I'd encourage this trend.  If in the future linus pulls from lieutenants and 
> lieutenants pull from maintainers, the dropped patches problem basically goes 
> away.  Just make sure that when the level above you IS ready to take it from 
> your level, it's there and ready for them...

OK, so Linus has been using BK for a couple of weeks now, and some of the
lieutenants have started setting up BK repositories at bkbits.net.  Is
there _any_ way that one can understand the heirarchy of repositories
at bkbits.net?  There's "linus", "linux", "linux25", and a bunch of other
obvious branch repositories.  Which one should kernel developers
clone/pull from?  It would be nice if there was a heirarchy or something
which showed the parent-child relationship.

I suppose (due to the BK design) that it is not fatal if you do your initial
clone from a URL that might go "dead" because you can always change your
parent URL and you haven't lost anything.

Clearly, all of the repositories need to start as clones of Linus'
repository, or there is no chance of them passing CSETs back and forth
among the developers.  Does the fact that 'linux-arm' is apparently not
a descendent from the 'official' linux-2.4 or linux-2.5 repository doom
that developer from not being able to send CSETs to any other kernel
developer or Linus?  Sure, they could send patches, but then they would
forever have to diff/patch and resolve conflicts on their end rather
than just pulling/pushing CSETs with all of the other kernel developers.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: pull vs push (was Re: [bk patch] Make cardbus compile in -pre4)

[Stelian Pop]

On Sat, Feb 09, 2002 at 03:08:25AM -0700, Andreas Dilger wrote:

> OK, so Linus has been using BK for a couple of weeks now, and some of the
> lieutenants have started setting up BK repositories at bkbits.net.  Is
> there _any_ way that one can understand the heirarchy of repositories
> at bkbits.net?  There's "linus", "linux", "linux25", and a bunch of other
> obvious branch repositories.  Which one should kernel developers
> clone/pull from?  It would be nice if there was a heirarchy or something
> which showed the parent-child relationship.

The 'linus' one seems to be the parent, because if I try to pull from
it bk tells me that the tree is for the private use of Linus only.

And all the other 2.5 repositories seem to be slighly out of date
(the linux/linux-2.5 one is at -pre3 instead of -pre5 etc).

So, what is supposed to be the definitive, public bk repository, 
to pull from in order to have the latest changes ? (the one which will
go on bk.kernel.org eventually) 

Stelian.
-- 
Stelian Pop <stelian.pop@fr.alcove.com>
Alcove - http://www.alcove.com

Re: pull vs push (was Re: [bk patch] Make cardbus compile in -pre4)

[Linus Torvalds]

On Sat, 9 Feb 2002, Stelian Pop wrote:
>
> So, what is supposed to be the definitive, public bk repository,
> to pull from in order to have the latest changes ? (the one which will
> go on bk.kernel.org eventually)

Right now the "definitive" bk repository is on master.kernel.org, which
can only be accessed by people who have accounts there.

I also push it to my private version on bkbits.net, and it is supposed to
be automatically then pushed onwards to the public one that is at
http://linux.bkbits.net:8080/linux-2.5, but the infrastructure for that
isn't yet working.

NOTE! If you're working on something that doesn't absolutely need the
stuff in -pre5, you can (and should) just take the pre3 tree, and work
there. When I pull stuff from people I don't require that they be
up-to-date with me - one of the advantages of bk is that it's really easy
to merge stuff.

We'll get the official tree out in a more timely manner, one of the issues
is actually just the scalability of pushing to lots of developers for the
first time.

So if you're interested in BK: get one of the "older" trees now (eg the
2.5.4-pre3 one that is public). Because that will make it a lot easier and
a lot faster to just "bk pull" once the more modern trees come on-line if
you have at least a base for it.

Oh - final comment: try to pull over a fast line, and don't bog down
bkbits.net more than necessary. For example, if you are behind a modem or
a slow DSL line and you want to clone the repository and you have an
account with faster speeds, I'd suggest you _first_ clone it to that other
account, and then later clone it from there over the slow line.

(After that you can re-parent your slow one and make all further "bk
pull"s directly - getting a few days or weeks of work with a "pull" is not
too costly, but when doing the whole clone it is better to get in and get
out faster to avoid clogging up the server with lots of bkd's that are
just waiting..)

			Linus

Re: pull vs push (was Re: [bk patch] Make cardbus compile in -pre4)

[Stelian Pop]

On Sat, Feb 09, 2002 at 12:59:16PM -0800, Linus Torvalds wrote:

> Right now the "definitive" bk repository is on master.kernel.org, which
> can only be accessed by people who have accounts there.
> 
> I also push it to my private version on bkbits.net, and it is supposed to
> be automatically then pushed onwards to the public one that is at
> http://linux.bkbits.net:8080/linux-2.5, but the infrastructure for that
> isn't yet working.

Ok, understood. While waiting for a 'proper' infrastructure', maybe
a simple cron entry will do the job ? (since the bk pull from your
private tree on bkbits to the public tree on bkbits is not supposed
to ever fail or have merge errors...)

Anyway, just did a 'bk pull' once again and noticed than linux.bkbits.net
has again the latest version. Thanks! (or thanks Larry, whatever is 
more appropriate :-)).

Stelian.
-- 
Stelian Pop <stelian.pop@fr.alcove.com>
Alcove - http://www.alcove.com

Re: pull vs push (was Re: [bk patch] Make cardbus compile in -pre4)

[Larry McVoy]

> > I also push it to my private version on bkbits.net, and it is supposed to
> > be automatically then pushed onwards to the public one that is at
> > http://linux.bkbits.net:8080/linux-2.5, but the infrastructure for that
> > isn't yet working.
> 
> Ok, understood. While waiting for a 'proper' infrastructure', maybe
> a simple cron entry will do the job ? (since the bk pull from your
> private tree on bkbits to the public tree on bkbits is not supposed
> to ever fail or have merge errors...)

This is my problem.  You could help if you could tell me what exactly 
are the magic wands to wave such that you can ssh in without typing
a password.  I know about ssh-agent but that doesn't help for this, 
I know that in certain cases ssh lets me in without anything.  I thought
there was some routine where you ssh-ed one way and then the other way
and it left enough state that it trusted you, does any ssh genuis out 
there know what I'm talking about?  If I have this, I can set up the
cron job, I'm sure this is obvious and I'm just overlooking something
but I can't find it.

> Anyway, just did a 'bk pull' once again and noticed than linux.bkbits.net
> has again the latest version. Thanks! (or thanks Larry, whatever is 
> more appropriate :-)).

Yeah, I did it by hand.  Hopefully automated by the end of the day.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: pull vs push (was Re: [bk patch] Make cardbus compile in -pre4)

[Stelian Pop]

On Sat, Feb 09, 2002 at 12:26:49PM -0800, Larry McVoy wrote:

> This is my problem.  You could help if you could tell me what exactly 
> are the magic wands to wave such that you can ssh in without typing
> a password. 

Set up $HOME/.shosts ? (man 1 ssh)

> > has again the latest version. Thanks! (or thanks Larry, whatever is 
> > more appropriate :-)).
> 
> Yeah, I did it by hand.  Hopefully automated by the end of the day.

Would it be possible to do something to keep the 2.4 tree up to date too ?
(something like checking if the latest incremental patch from kernel.org
was applied to the tree, and if not, apply it as a changeset and tag) ?

Stelian.
-- 
Stelian Pop <stelian.pop@fr.alcove.com>
Alcove - http://www.alcove.com

Re: pull vs push (was Re: [bk patch] Make cardbus compile in -pre4)

[Jeff Garzik]

Stelian Pop wrote:
> Would it be possible to do something to keep the 2.4 tree up to date too ?
> (something like checking if the latest incremental patch from kernel.org
> was applied to the tree, and if not, apply it as a changeset and tag) ?

Convince Marcelo to look at BK for merging :)

	Jeff, slowly getting spoiled by BK and Linus



-- 
Jeff Garzik      | "I went through my candy like hot oatmeal
Building 1024    |  through an internally-buttered weasel."
MandrakeSoft     |             - goats.com

Re: pull vs push (was Re: [bk patch] Make cardbus compile in -pre4)

[Larry McVoy]

On Sat, Feb 09, 2002 at 09:51:10PM +0100, Stelian Pop wrote:
> Would it be possible to do something to keep the 2.4 tree up to date too ?
> (something like checking if the latest incremental patch from kernel.org
> was applied to the tree, and if not, apply it as a changeset and tag) ?

Someone has to do the work, it's certainly possible.   That tree is up to date
with what Linus has done.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: pull vs push (was Re: [bk patch] Make cardbus compile in -pre4)

[Pau Aliagas]

On Sat, 9 Feb 2002, Larry McVoy wrote:

> This is my problem.  You could help if you could tell me what exactly 
> are the magic wands to wave such that you can ssh in without typing
> a password.  I know about ssh-agent but that doesn't help for this, 
> I know that in certain cases ssh lets me in without anything.  I thought
> there was some routine where you ssh-ed one way and then the other way
> and it left enough state that it trusted you, does any ssh genuis out 
> there know what I'm talking about?  If I have this, I can set up the
> cron job, I'm sure this is obvious and I'm just overlooking something
> but I can't find it.

Just get the .ssh/id_dsa.pub from the client you want to allow in without 
a password and copy it inside .ssh/authorized_keys2 in the server.

ssh-agent is useful if you protect your keys with a password so that you
don't have to retype the password to unblock you own key over and over.  
Nothing to do with accessing other sites.

If you need any help just tell me.
Pau

Re: pull vs push (was Re: [bk patch] Make cardbus compile in -pre4)

[David Lang]

I just set this up between a couple machines at work and one thing we
ended up doing to get it to work was to generate a key without a
passphrase on it to use for syncing, otherwise the ssh on the machine
inititing the connection wanted a password to start the connection. you
also need to do the stuff mentioned for the receiving end so that it
doesn't ask for a password.

David Lang


 On Sat, 9 Feb 2002, Pau Aliagas wrote:

> Date: Sat, 9 Feb 2002 21:57:50 +0100 (CET)
> From: Pau Aliagas <linuxnow@wanadoo.es>
> To: Larry McVoy <lm@bitmover.com>
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: pull vs push (was Re: [bk patch] Make cardbus compile in
>     -pre4)
>
> On Sat, 9 Feb 2002, Larry McVoy wrote:
>
> > This is my problem.  You could help if you could tell me what exactly
> > are the magic wands to wave such that you can ssh in without typing
> > a password.  I know about ssh-agent but that doesn't help for this,
> > I know that in certain cases ssh lets me in without anything.  I thought
> > there was some routine where you ssh-ed one way and then the other way
> > and it left enough state that it trusted you, does any ssh genuis out
> > there know what I'm talking about?  If I have this, I can set up the
> > cron job, I'm sure this is obvious and I'm just overlooking something
> > but I can't find it.
>
> Just get the .ssh/id_dsa.pub from the client you want to allow in without
> a password and copy it inside .ssh/authorized_keys2 in the server.
>
> ssh-agent is useful if you protect your keys with a password so that you
> don't have to retype the password to unblock you own key over and over.
> Nothing to do with accessing other sites.
>
> If you need any help just tell me.
> Pau
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: pull vs push (was Re: [bk patch] Make cardbus compile in -pre4)

[Pau Aliagas]

On Sat, 9 Feb 2002, David Lang wrote:

> I just set this up between a couple machines at work and one thing we
> ended up doing to get it to work was to generate a key without a
> passphrase on it to use for syncing, otherwise the ssh on the machine
> inititing the connection wanted a password to start the connection. you
> also need to do the stuff mentioned for the receiving end so that it
> doesn't ask for a password.

That's ok if you can't type the password as in batch jobs.

Pau

Re: pull vs push (was Re: [bk patch] Make cardbus compile in -pre4)

[Rob Landley]

On Saturday 09 February 2002 03:26 pm, Larry McVoy wrote:
> > > I also push it to my private version on bkbits.net, and it is supposed
> > > to be automatically then pushed onwards to the public one that is at
> > > http://linux.bkbits.net:8080/linux-2.5, but the infrastructure for that
> > > isn't yet working.
> >
> > Ok, understood. While waiting for a 'proper' infrastructure', maybe
> > a simple cron entry will do the job ? (since the bk pull from your
> > private tree on bkbits to the public tree on bkbits is not supposed
> > to ever fail or have merge errors...)
>
> This is my problem.  You could help if you could tell me what exactly
> are the magic wands to wave such that you can ssh in without typing
> a password.

You need three or four files in the .ssh directory of the account in 
question.  (This is assuming that ssh protocol 2 comes first in your 
ssh_config and sshd_config files.)

1) The file ~/.ssh/known_hosts2 lists the host keys.  If you just ssh to a 
box it'll prompt you if it should add an unknown key to the file.  (Just do 
this manually once in each direction and this file will be happy.  You can 
assemble it manually from /etc/ssh/ssh_host_key.pub if you want, but I doubt 
you need to.)

2) Generate a public/private pair of dsa encryption keys, with:

ssh-keygen -d -f ~/.ssh/id_dsa

Just press enter twice for the passphrase (you don't want one for 
passwordless sshing).

3) In the .ssh dir, copy "id_dsa.pub" to "authorized_keys2"

4) Copy the three files you just created (id_dsa, id_dsa.pub, and 
authorized_keys2) to the ~/.ssh directory on the other box.

This allows bidirectional passwordless sshing.  If you want to only ssh in 
one direction, keep the public keys (id_dsa.pub and authorized_keys2) but zap 
the private key on the appropriate box.

Now just try to ssh as the user in question.  (su username, then ssh 1.2.3.4)

If you're piping data from one box to another, you might want to use the -T 
option to tell it no controlling TTY.  (Largely a matter of personal 
taste...)  And sometimes -C "echo hello" works better than just having the 
commands explicitly on the end of the command line...

I have this working over here.  If I missed a step, email me.

Rob

Re: pull vs push (was Re: [bk patch] Make cardbus compile in -pre4)

[Andreas Dilger]

On Feb 09, 2002  12:26 -0800, Larry McVoy wrote:
> This is my problem.  You could help if you could tell me what exactly 
> are the magic wands to wave such that you can ssh in without typing
> a password.  I know about ssh-agent but that doesn't help for this, 
> I know that in certain cases ssh lets me in without anything.  I thought
> there was some routine where you ssh-ed one way and then the other way
> and it left enough state that it trusted you, does any ssh genuis out 
> there know what I'm talking about?  If I have this, I can set up the
> cron job, I'm sure this is obvious and I'm just overlooking something
> but I can't find it.

OK, so to log in or run a command on a remote machine R, from your local
machine L, you need to have a copy of your public key L:~/.ssh/identity.pub
in the file R:~/.ssh/authorized_keys.  You can have multiple keys in
R:~/.ssh/authorized_keys.  When ssh'ing from L to R, you also need to
have L:~/.ssh/identity available and possibly type in a pass-phrase if
needed (for automated systems you probably do not want a pass-phrase,
so you set it up with its own key).

Just FYI, the rest of the story goes like:

If your L:~/.ssh/identity has a pass-phrase (or if you want to do multi-
hop ssh'ing, I think) you will probably want to use an ssh-agent to hold
all of your private keys.  GDM (Gnome X login) will start ssh-agent for
you I believe, and then you have to do "ssh-add [identity file ...]" to
add one or more private keys to the ssh-agent, which will prompt you for a
pass-phrase if needed.  If you have multiple private keys (identity files)
then newer versions of ssh-add will try the same pass-phrase for all of
them before prompting you again.

Then, when you ssh over to another machine, and that machine is listed
in /etc/ssh/ssh_config or .ssh/config as "ForwardAgent yes" it will
pass on your private key(s) to a new agent started on the remote machine,
which will allow you to do passwordless ssh to another machine, etc.
Likewise, as long as you have "ForwardX11 yes" for each machine in the
chain, you will be able to start an X session at the far end and it
will tunnel through all of the ssh hops to display on L's screen.

You probably want to have a pass-phrase on all of your private keys,
because if anyone ever could read your ~/.ssh/identity file, they can
effectively do anything you can do, and connect anywhere that has your
corresponding identity.pub file in the authorized_keys file without
a password.

Note also, for most new versions of SSH, it will try SSH protocol 2
before it tries SSH 1.  This means that everywhere I said "identity"
it will use "id_dsa", "identity.pub" becomes "id_dsa.pub", and
"authorized_keys" becomes "authorized_keys2".  You can change the default
order if you want with "Protocol 1,2" in your ~/.ssh/config file, or
you can add both your L:~/.ssh/identity and L:~/.ssh/id_dsa to the
ssh-agent, and add the id_dsa.pub to authorized_keys2.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: pull vs push (was Re: [bk patch] Make cardbus compile in -pre4)

[Herbert Xu]

Larry McVoy <lm@bitmover.com> wrote:

> This is my problem.  You could help if you could tell me what exactly 
> are the magic wands to wave such that you can ssh in without typing
> a password.  I know about ssh-agent but that doesn't help for this, 

Setup your key with an empty passphrase should do the trick.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

ssh primer (was Re: pull vs push (was Re: [bk patch] Make cardbus compile in -pre4))

[Jeff Garzik]

Herbert Xu wrote:
> 
> Larry McVoy <lm@bitmover.com> wrote:
> 
> > This is my problem.  You could help if you could tell me what exactly
> > are the magic wands to wave such that you can ssh in without typing
> > a password.  I know about ssh-agent but that doesn't help for this,
> 
> Setup your key with an empty passphrase should do the trick.

Ug.  no.  That is way way insecure.

Most modern distros have an ssh-agent running as a parent of all
X-spawned processed (including processes spawned by xterms).  So, one
only needs to run
	ssh-add ~/.ssh/id_dsa ~/.ssh/identity
once, and input your password once.  After that, no passwords are
needed.


For those with multiple peer shells and no X-parented ssh-agent, you
will need to run ssh-agent ONCE, like so:

	ssh-agent > ~/tmp/ssh-agent.out

and then for each shell, you need to run:

	eval `cat ~/tmp/ssh-agent.out`

and then run the ssh-add command from above.

-- 
Jeff Garzik      | "I went through my candy like hot oatmeal
Building 1024    |  through an internally-buttered weasel."
MandrakeSoft     |             - goats.com

Re: ssh primer (was Re: pull vs push (was Re: [bk patch] Make cardbus compile in -pre4))

[Herbert Xu]

On Sat, Feb 09, 2002 at 07:54:29PM -0500, Jeff Garzik wrote:
> Herbert Xu wrote:
> > 
> > Setup your key with an empty passphrase should do the trick.
> 
> Ug.  no.  That is way way insecure.
> 
> Most modern distros have an ssh-agent running as a parent of all
> X-spawned processed (including processes spawned by xterms).  So, one
> only needs to run
> 	ssh-add ~/.ssh/id_dsa ~/.ssh/identity
> once, and input your password once.  After that, no passwords are
> needed.

This is fine for interactive use.  But for a daily cron job, it's
just as insecure as no passphrases at all.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: ssh primer (was Re: pull vs push (was Re: [bk patch] Make cardbus compile in -pre4))

[Jeff Garzik]

Herbert Xu wrote:
> 
> On Sat, Feb 09, 2002 at 07:54:29PM -0500, Jeff Garzik wrote:
> > Herbert Xu wrote:
> > >
> > > Setup your key with an empty passphrase should do the trick.
> >
> > Ug.  no.  That is way way insecure.
> >
> > Most modern distros have an ssh-agent running as a parent of all
> > X-spawned processed (including processes spawned by xterms).  So, one
> > only needs to run
> >       ssh-add ~/.ssh/id_dsa ~/.ssh/identity
> > once, and input your password once.  After that, no passwords are
> > needed.
> 
> This is fine for interactive use.  But for a daily cron job, it's
> just as insecure as no passphrases at all.

It is far easier to guess your private key with a blank passphrase.

	Jeff


-- 
Jeff Garzik      | "I went through my candy like hot oatmeal
Building 1024    |  through an internally-buttered weasel."
MandrakeSoft     |             - goats.com

Re: ssh primer (was Re: pull vs push (was Re: [bk patch] Make cardbus compile in -pre4))

[Herbert Xu]

On Sat, Feb 09, 2002 at 08:24:46PM -0500, Jeff Garzik wrote:
> 
> It is far easier to guess your private key with a blank passphrase.

Please show me how to do this without gaining access to the machine
in question.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: ssh primer (was Re: pull vs push (was Re: [bk patch] Make cardbus compile in -pre4))

[Aaron Lehmann]

On Sat, Feb 09, 2002 at 08:24:46PM -0500, Jeff Garzik wrote:
> It is far easier to guess your private key with a blank passphrase.

I challenge you to present a method for doing so.

Re: ssh primer (was Re: pull vs push (was Re: [bk patch] Make cardbus compile in -pre4))

[Rob Landley]

On Wednesday 13 February 2002 12:13 pm, Aaron Lehmann wrote:
> On Sat, Feb 09, 2002 at 08:24:46PM -0500, Jeff Garzik wrote:
> > It is far easier to guess your private key with a blank passphrase.
>
> I challenge you to present a method for doing so.

Your public/private key pair are pretty straightforward public key 
cryptography.  If you can brute force one given the other, it wouldn't be 
safe to use it over the wire in the first place.

The point of having a passphrase is that some really paranoid people want to 
have both a key AND a password to get into their box.  A password in and of 
itself isn't all that secure, since any human memorizable password contains 
so little information it would be trivial to break computationally via brute 
force (if you can arrange a brute force attack, which login tries to prevent 
with the ~3 second delay between attempts, but they still tend to get written 
down, or people watch keystrokes over your shoulder...).  And a key you carry 
around with you on a floppy or propogate to multiple boxes can be stolen 
(copied) from any of those places without you necessarily knowing about it.

In terms of brute forcing the key, the passphrase adds a fairly trivial 
number of bits to the key.  It's not "far" easer, an 8 character mixed case 
nonsense password with numbers and punctuation mixed in is still less than 6 
bits per character, or at best an extra 48 bits.  You can select a 1024 bit 
key if you want to be really really paranoid.

Not that it's worth it.  Keys get exponentially more difficult to brute force 
as the key length increases.  I read part of a book a long time ago (might 
have been called "applied cryptography") that figured out that if you could 
build a perfectly efficient computer that could do 1 bit's worth of 
calculation with the the amount of energy in the minimal electron state 
transition in a hydrogen atom, and you built a dyson sphere around the sun to 
capture its entire energy output for the however many billion years its 
expected to last, you wouldn't even brute-force exhaust a relatively small 
keyspace (128 bits?  256 bits?  Something like that).

Somebody else here is likely to recognize the above anecdote and give a more 
accurate reference.  Book title and page number would be good...

Rob

Re: ssh primer (was Re: pull vs push (was Re: [bk patch] Make cardbus compile in -pre4))

[Aaron Lehmann]

On Wed, Feb 13, 2002 at 07:22:57PM -0500, Rob Landley wrote:
> In terms of brute forcing the key, the passphrase adds a fairly trivial 
> number of bits to the key.  It's not "far" easer, an 8 character mixed case 
> nonsense password with numbers and punctuation mixed in is still less than 6 
> bits per character, or at best an extra 48 bits.  You can select a 1024 bit 
> key if you want to be really really paranoid.

I agree that it isn't worth it.

I assume that Jeff didn't understand the principles behind public key
cryptography that SSH uses which keep communications secure unless the
private key is compromised (and the private key should never leave
client machine). When you have a passphrase, you encrypt this private
key with a hash of it. Not having a passphrase removes this layer of
security, but if you include the passphrase in a script for automatic
use you're undoing any advantage that a passphrase gives you in the
first place.

In short, to compromise a private key without access to that key
(which presumably only you would have if the key was on your system,
and you must assume that if someone could access your private key they
could access any passphrase you were storing in a script to facilitate
automatic use of it), you'd have to either have unheard of amounts of
computational power and a few millenia on your hands, or come across a
mathematical breakthrough. I certainly hope that Mr. Garzik has not
broken public key cryptography!

Note that you can't compare public key bits to passphrase bits (which
are more like symmetric key bits). You probably know this.

> Not that it's worth it.  Keys get exponentially more difficult to brute force 
> as the key length increases.  I read part of a book a long time ago (might 
> have been called "applied cryptography") that figured out that if you could 
> build a perfectly efficient computer that could do 1 bit's worth of 
> calculation with the the amount of energy in the minimal electron state 
> transition in a hydrogen atom, and you built a dyson sphere around the sun to 
> capture its entire energy output for the however many billion years its 
> expected to last, you wouldn't even brute-force exhaust a relatively small 
> keyspace (128 bits?  256 bits?  Something like that).

That was Applied Cryptography. I believe he said that the energy
output of a supernova was insufficient to cycle a counter through
about 2^190, based on accepted thermodynamic principles and data. Of
course, this makes brute force of something like a 256 bit symmetric
key completely infeasible and bounded by physical law. Not that 128
bits is very shabby, but it only takes a few billion years of all the
current computing power on earth to brute force something like that.

Re: ssh primer (was Re: pull vs push (was Re: [bk patch] Make cardbus compile in -pre4))

[Harald Arnesen]

Rob Landley <landley@trommello.org> writes:

> Not that it's worth it. Keys get exponentially more difficult to
> brute force as the key length increases. I read part of a book a
> long time ago (might have been called "applied cryptography") that
> figured out that if you could build a perfectly efficient computer
> that could do 1 bit's worth of calculation with the the amount of
> energy in the minimal electron state transition in a hydrogen atom,
> and you built a dyson sphere around the sun to capture its entire
> energy output for the however many billion years its expected to
> last, you wouldn't even brute-force exhaust a relatively small
> keyspace (128 bits? 256 bits? Something like that).
>
> Somebody else here is likely to recognize the above anecdote and give a more 
> accurate reference.  Book title and page number would be good...

Bruce Schneier's "Applied Cryptography" (second edition, may be in the
first edition as well), pages 157-158 ("Thermodynamic Limitations").
-- 
Hilsen Harald.

Re: ssh primer (was Re: pull vs push (was Re: [bk patch] Make cardbus compile in -pre4))

[Ben Pfaff]

Jeff Garzik <jgarzik@mandrakesoft.com> writes:

> For those with multiple peer shells and no X-parented ssh-agent, you
> will need to run ssh-agent ONCE, like so:
> 
> 	ssh-agent > ~/tmp/ssh-agent.out
> 
> and then for each shell, you need to run:
> 
> 	eval `cat ~/tmp/ssh-agent.out`
> 
> and then run the ssh-add command from above.

I keep the following in my .bashrc and use the `agent' command to
initialize the ssh-agent.

# Allow `agent' to start the ssh-agent usefully on all running
# bash instances.  SIGQUIT was chosen because it is ignored by
# bash by default, even in non-interactive shells, so that a
# shell not trapping it by some chance won't be terminated.
if test -f ~/.ssh/agent; then 
    . ~/.ssh/agent
fi
function agent {
    killall -q ssh-agent
    ssh-agent > ~/.ssh/agent
    killall -QUIT bash >/dev/null 2>&1
    ssh-add ~/.ssh/identity
    ssh-add ~/.ssh/id_dsa
}
trap -- '. ~/.ssh/agent' SIGQUIT

-- 
"Be circumspect in your liaisons with women.
 It is better to be seen at the opera with a man
 than at mass with a woman."
--De Maintenon

Re: ssh primer (was Re: pull vs push (was Re: [bk patch] Make cardbus compile in -pre4))

[David Lang]

how does this work when running something from cron? (I think that's the
type of thing Larry is trying to do)

David Lang

On Sat, 9 Feb 2002, Jeff Garzik wrote:

> Date: Sat, 09 Feb 2002 19:54:29 -0500
> From: Jeff Garzik <jgarzik@mandrakesoft.com>
> To: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: Larry McVoy <lm@bitmover.com>, linux-kernel@vger.kernel.org
> Subject: ssh primer (was Re: pull vs push (was Re: [bk patch] Make
>     cardbus  compile in -pre4))
>
> Herbert Xu wrote:
> >
> > Larry McVoy <lm@bitmover.com> wrote:
> >
> > > This is my problem.  You could help if you could tell me what exactly
> > > are the magic wands to wave such that you can ssh in without typing
> > > a password.  I know about ssh-agent but that doesn't help for this,
> >
> > Setup your key with an empty passphrase should do the trick.
>
> Ug.  no.  That is way way insecure.
>
> Most modern distros have an ssh-agent running as a parent of all
> X-spawned processed (including processes spawned by xterms).  So, one
> only needs to run
> 	ssh-add ~/.ssh/id_dsa ~/.ssh/identity
> once, and input your password once.  After that, no passwords are
> needed.
>
>
> For those with multiple peer shells and no X-parented ssh-agent, you
> will need to run ssh-agent ONCE, like so:
>
> 	ssh-agent > ~/tmp/ssh-agent.out
>
> and then for each shell, you need to run:
>
> 	eval `cat ~/tmp/ssh-agent.out`
>
> and then run the ssh-add command from above.
>
> --
> Jeff Garzik      | "I went through my candy like hot oatmeal
> Building 1024    |  through an internally-buttered weasel."
> MandrakeSoft     |             - goats.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: ssh primer (was Re: pull vs push (was Re: [bk patch] Make cardbuscompile in -pre4))

[Jeff Garzik]

David Lang wrote:
> how does this work when running something from cron? (I think that's the
> type of thing Larry is trying to do)

A simple mutation of this:


> > For those with multiple peer shells and no X-parented ssh-agent, you
> > will need to run ssh-agent ONCE, like so:
> >
> >       ssh-agent > ~/tmp/ssh-agent.out
> >
> > and then for each shell, you need to run:
> >
> >       eval `cat ~/tmp/ssh-agent.out`


Run ssh-agent and ssh-add once per reboot, such as from
/usr/local/bin/login-bkpull.

>From the cron script, run the eval line shown.

No passwords are prompted for.

	Jeff



-- 
Jeff Garzik      | "I went through my candy like hot oatmeal
Building 1024    |  through an internally-buttered weasel."
MandrakeSoft     |             - goats.com

Re: pull vs push (was Re: [bk patch] Make cardbus compile in -pre4)

[Alan Cox]

> a password.  I know about ssh-agent but that doesn't help for this, 
> I know that in certain cases ssh lets me in without anything.  I thought
> there was some routine where you ssh-ed one way and then the other way
> and it left enough state that it trusted you, does any ssh genuis out 
> there know what I'm talking about?  If I have this, I can set up the
> cron job, I'm sure this is obvious and I'm just overlooking something
> but I can't find it.

For the paranoid 

You ssh from the source to an untrusted chrooted nopriv uid on the target
using a ssh pass phrase and ipchains static ip rules to allow only some
IP's access

A cron or other triggered job on the receiving machine checks the GPG
signatures of the uploaded data and moves/processes it if it matches or
if the key matches blocks off that machine and ID and mails the admin.

Alan

Re: pull vs push (was Re: [bk patch] Make cardbus compile in -pre4)

[Pavel Machek]

Hi!

> > I don't see why everyone who is using BK is expecting Linus to do a pull.
> > In the non-BK case, wasn't it always a "push" model, and Linus would not
> > "pull" from URLs and such?
> 
> I'm all for it.  I think it's a good thing.
> 
> In the absence of significant latency issues, pull scales better than push.  
> It always has.  Push is better in low bandwidth situations with lots of idle 
> capacity, but it breaks down when the system approaches saturation.
> 
> Pull data is naturally supplied when you're ready for it (assuming no 
> significant latency to access it).  Push either scrolls by unread or piles up 
> in your inbox and gets buried until it goes stale.  Web pages work on a pull 
> model, "push" was an internet fad a few years ago that failed for a reason.  
> When push models hit saturation it breaks down and you wind up with the old 
> "I love lucy" episode with the chocolate factory.  Back in the days where 

What's "i love lucy" episode?
									Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: pull vs push (was Re: [bk patch] Make cardbus compile in -pre4)

[John Alvord]

On Mon, 11 Feb 2002 11:51:04 +0000, Pavel Machek <pavel@suse.cz>
wrote:

>Hi!
>
>> > I don't see why everyone who is using BK is expecting Linus to do a pull.
>> > In the non-BK case, wasn't it always a "push" model, and Linus would not
>> > "pull" from URLs and such?
>> 
>> I'm all for it.  I think it's a good thing.
>> 
>> In the absence of significant latency issues, pull scales better than push.  
>> It always has.  Push is better in low bandwidth situations with lots of idle 
>> capacity, but it breaks down when the system approaches saturation.
>> 
>> Pull data is naturally supplied when you're ready for it (assuming no 
>> significant latency to access it).  Push either scrolls by unread or piles up 
>> in your inbox and gets buried until it goes stale.  Web pages work on a pull 
>> model, "push" was an internet fad a few years ago that failed for a reason.  
>> When push models hit saturation it breaks down and you wind up with the old 
>> "I love lucy" episode with the chocolate factory.  Back in the days where 
>
>What's "i love lucy" episode?
>									Pavel
"I Love Lucy" was a 1950s sitcom on television, one of the first and
very good indeed.

In the episode referred to, Lucy and her friend Ethel get hired as
candy-packers in a candy factory. The candies come by on a conveyer
belt and the girls put them in boxes. Everything went smoothly... the
manager reviewed the situation, and congratulated them. Then they
increased the conveyer belt flow. After a few more cycles, the candy
was coming too fast. So they started taking the candies, stuffing them
into pockets, blouses, mouths... and the scene ends with the manager
arriving back madder then heck.

john

Re: [bk patch] Make cardbus compile in -pre4

[Peter Osterlund]

Patrick Mochel <mochel@osdl.org> writes:

> I broke cardbus compile in -pre4 on accident. Sorry about that...

It compiles in -pre5 but doesn't work unless you also apply the patch
below. Without this patch, bus_id will be empty which makes
device_register fail.

--- linux/drivers/pcmcia/cardbus.c.old	Sat Feb  9 12:39:49 2002
+++ linux/drivers/pcmcia/cardbus.c	Sat Feb  9 12:14:36 2002
@@ -279,13 +279,13 @@
 		pci_readw(dev, PCI_DEVICE_ID, &dev->device);
 		dev->hdr_type = hdr & 0x7f;
 
+		pci_setup_device(dev);
+
 		dev->dev.parent = bus->dev;
 		strcpy(dev->dev.name, dev->name);
 		strcpy(dev->dev.bus_id, dev->slot_name);
 		device_register(&dev->dev);
 
-		pci_setup_device(dev);
-
 		/* FIXME: Do we need to enable the expansion ROM? */
 		for (r = 0; r < 7; r++) {
 			struct resource *res = dev->resource + r;

-- 
Peter Osterlund - petero2@telia.com
http://w1.894.telia.com/~u89404340

Re: ssh primer (was Re: pull vs push (was Re: [bk patch] Make cardbus compile in -pre4))

[Jesse Pollard]

------HEADER END-DONT REMOVE------ 
> Rob Landley <landley@trommello.org> writes:
> 
> > Not that it's worth it. Keys get exponentially more difficult to
> > brute force as the key length increases. I read part of a book a
> > long time ago (might have been called "applied cryptography") that
> > figured out that if you could build a perfectly efficient computer
> > that could do 1 bit's worth of calculation with the the amount of
> > energy in the minimal electron state transition in a hydrogen atom,
> > and you built a dyson sphere around the sun to capture its entire
> > energy output for the however many billion years its expected to
> > last, you wouldn't even brute-force exhaust a relatively small
> > keyspace (128 bits? 256 bits? Something like that).
> >
> > Somebody else here is likely to recognize the above anecdote and give a more 
> > accurate reference.  Book title and page number would be good...
> 
> Bruce Schneier's "Applied Cryptography" (second edition, may be in the
> first edition as well), pages 157-158 ("Thermodynamic Limitations").
Remember - this is a dated example, since some theories are beginning
to consider storing & computing data with photons/interference patterns...
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.