Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Kernel Traffic #159 For 25 Mar 2002

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 1976 posts in 8611K.

There were 500 different contributors. 241 posted more than once. 180 posted last week too.

The top posters of the week were:

1. Status Of Linux 386 Support

4 Mar 2002 - 20 Mar 2002 (84 posts) Archive Link: "[PATCH] Futexes IV (Fast Lightweight Userspace Semaphores)"

Topics: SMP

People: H. Peter AnvinAlan CoxLinus Torvalds

In the course of something completely different, Linus Torvalds and others were debating a way to deal with the idiosyncrasies of the 386 processor (not all x86, but the 386 specifically). At one point H. Peter Anvin said:

Perhaps it's time to drop i386 support?

It seems to me that the i386 support has been around mostly on a "until we have a reason to do otherwise" basis, but perhaps this is the reason?

There certainly are enough little, nagging reasons... CMPXCHG, BSWAP, and especially WP...

Alan Cox replied:

They don't really arise in most normal situations. Bswap is trivial to the extreme. Cmpxchg only comes up on SMP boxes. Right now the one big hit is cmpxchg8 if you use direct rendering. And quite frankly if you use the direct rendering infrastructure on a 386 its going to be a teeny bit slow anyway 8)

So if anything its just not worth the effort of breaking the 386 setup either 8). 386 SMP is a different issue but I don't see any lunatics doing a 386 based sequent port thankfully.

And Linus replied:

Since the only person that comes to mind that would be crazy enough to even _try_ to use Linux on 386-SMP is you, Alan, I'm really relieved to hear you say that ;)

And no, it's not worth discontinuing i386 support. It just isn't painful enough to maintain.

Note that the i386 has _long_ been a "stepchild", though: because of the lack of WP, the kernel simply doesn't do threaded MM correctly on a 386. Never has, and never will.

However, the known "incorrect" case is so obscure that it's not even an issue - although I suspect that it means that you should not let untrusted users run on a i386 server machine that contains any sensitive data. I could cerrtainly come up with exploits that would work at least in theory (whether they are workable in practice I don't know).

Using i386's for network servers is fine, of course. Just don't use them for cpu farms (not that I think anybody is - it takes quite a big farm of i386 machines to equal even _one_ PII ;)

2. Some Developers Unhappy With BitKeeper License

5 Mar 2002 - 14 Mar 2002 (109 posts) Archive Link: "Petition Against Official Endorsement of BitKeeper by Linux Maintainers"

Topics: Version Control

People: The Open Source Club at The Ohio State UniversityAndrew MortonRik van RielAlan CoxColin WaltersZwane MwaikamboAlexander ViroDave JonesCort DouganLinus TorvaldsLarry McVoyRandy DunlapEric W. BiedermanPau AliagasAndi Kleen

In Issue #158, Section #2  (6 Mar 2002: Some Dissent Over BitKeeper) , I reported that some off-list BitKeeper discussion had finally made it to the mailing list. Actually the thread was always on linux-kernel, but was still ongoing, and so had been pushed into my next week's mail box. The thread I saw had pealed away from the main branch and ended in time for me to catch it.

Anyway, here is the rest of that discussion. The Open Source Club At The Ohio State University (embodied by Michael Benedict, Colin Walters, Matt Curtin, Martin Jansche, Balbir Thomas, Nicholas Hurley, Ryan McCormack, and Shaun Rowland) said:

We, the undersigned members and officers of the Open Source Club at the Ohio State University, are unhappy with the advocacy of the proprietary ( BitKeeper software for use in maintaining the Linux kernel. The Linux kernel is an important symbol of Open Source and Free Software for many people, and a project in which many thousands have participated in active development. It is fine if some kernel developers choose to use BitKeeper on their own machines, but officially endorsing proprietary software as the means of working on the kernel is a large step backwards for Linux, and for the Open Source and Free Software communities.

If the core Linux maintainers begin to advocate using BitKeeper, then there will be strong pressure on these peripheral developers to use BitKeeper too, since it would likely be easier than browsing the web-exported changelogs or fetching the latest diff from

Using a closed-source, proprietary source control system for the kernel is even worse than using other forms of proprietary software such as source code analysis systems, because the revision control metadata (version numbers, branches, changelog comments, etc.), would be stored in a format defined by the proprietary software. This metadata is really a part of Linux, because people will want to use it when talking about the kernel. Those who can't (Perhaps they aren't connected to the internet regularly enough, for instance.) or don't want to use BitKeeper are left out in the cold. One of the most important parts of Open Source and Free Software is that we, the community, are in control. But by using and advocating BitKeeper, we would lose part of that control.

In summary, please do not advocate BitKeeper for use by the general community. The Linux development process seems to have worked up till now, and we can wait a little longer until Arch ( or Subversion ( are completed. Moreover, full-featured, completely functional free versioning sytems are currently available, such as PRCS ( and CVS ( We respect the kernel maintainer's freedom to use proprietary software for their own purposes. And we ask the kernel maintainers to respect the community's freedom from entrapment by proprietary software.

Andrew Morton replied:

fwiw, I prefer to not use bitkeeper, for the reasons which you outline.

That's my choice. Others have made a different one. I ask that they ensure that their choice not inhibit my ability to contribute to Linux.

(At this point Andi Kleen began the subthread covered last week.)

Randy Dunlap also replied to Andrew, with complete agreement. Elsewhere, Eric W. Biederman suggested that the people protesting BitKeeper do more to create a free replacement instead of writing petitions. Rik van Riel also agreed with that, saying, "the choice between a not-quite-free tool and no useful tool at all is easy." Pau Aliagas suggested trying Arch, but Rik didn't reply. Elsewhere, Alan Cox also replied to the Ohio group, saying:

Right from the start Linus has always said he isn't going to force anyone to use bitkeeper. End of story. If you think its free enough - use it, if you don't (or you just think its crap software, dont use it)

In fact if it offends you enough to start a petition take the list of names you get at the end and between you go write a better one under a licence you prefer between the signatures.

Colin replied that development was already underway on those replacements. He added, "The petition never mentioned "force". And even if Linus (and the other core maintainers) wanted to, they couldn't *force* anyone to use BitKeeper. The issue at hand is the strong pressure the official advocacy places on the perhipheral developers. We (the signers of the petition), and others are unhappy with this. That's what the petition says." Zwane Mwaikambo replied, "Already in development? Good stuff! Be sure to make an announcement when its ready for production use, till then be a sport and hop along."

Elsewhere and in the course of discussion, Alexander Viro said:

some of us are interested in creation of _WORKING_ software. Free is preferable; GPL is usually tolerable; but all that isn't worth anything is the design and code are crap.

Hypocrisy (or lunacy - take your pick) is coming from those who insist that politically correct tools should be prefered even when they clearly suck.

If you feel that the worst problem is that non-free software exists - that's your right. And your problem. IMNSHO the fact that majority of both free and non-free software is choke-full of crap is slightly more troubling. YMMV.

He added, "BTW, bitkeeper doesn't solve the problems I have. Ditto for CVS. So I use neither. FWIW, BK is closer to what I need. If it will ever get the things I need right - I'll use it and damned if I'll hide that." And Dave Jones replied:

Preach on brother Viro. Faced with the mammoth task of somehow syncing a 6MB diff with Linus, I decided it was time to devote an afternoon (which then turned into an evening) to seeing if bk can make this easier.

There's nothing in bk that makes my life any more difficult, and potential for it to make it a *lot* easier. And Larry seems open to suggestions, dispelling the "its closed commercial blah" myth.

Splitting bits up could become even easier soon if Larry and I figure out a way to implement some of my perverse ideas for bending csets into something more flexable than what they currently are.

Syncing from Linus to my tree isn't difficult, its the splitting bits up to push his way that takes time. bk is halfway towards almost automating this for me. CVS and friends don't even get to the start line here.

Hours of diff/grepdiff/filterdiff/vim, vs a few clicky clicky bits in bk citool.

If you don't like the license, fine. Don't use it, but at least give everyone else the option of making up their own mind before you try to force _your_ opinion on others.

Elsewhere, in a completely different subthread, Andrew said:

I don't think anyone has been criticising bk featureset or reliability. A few performance mumblings, maybe. It seems to be a fantastic piece of software.

But that's not the point! Nobody, repeat nobody is happy with the licensing thing. For some people, the day-to-day benefits outweigh the philosophical concerns. For others they do not. That is what is being discussed here.

I see two things being discussed here:

  1. I don't want bitkeeper use to *decrease* my ability to do Linux work. Linus will continue to push patches at the same rate, so I have no problem. I'm OK with others using bitkeeper. EOT.
  2. Kernel has a leading role in free software development. Other people do not want kernel's use of bitkeeper to weaken that movement.

    Me, I don't think the "movement" is weak enough for damage to come about. And SCM is a space where the free tools are weak. It's a once-off special-case and it's hard to see how anything bad will come about from it.

Also elsewhere, Cort Dougan said, "I move the PPC tree over to BitKeeper and it was worthwhile. I made rsync updates and plain old 'diff' patches against Linus' tree available nightly. It was easy and very quick to do that, I had it running for nearly 2 years very well. In fact, you can still grab the patches from What is your problem with BK apart from the license religion? Linus has made it clear he'll provide patches in the same old style. I don't see what you think you lose here. The gain for people who ship him patches is well worth it. Before I handed the PPC tree over to Paul I would have killed to get Linus to use BK so shipping him patches would be easier for everyone involved. If I were still a maintainer my response would be a lot less mild to those people that fight against BK on something so intangible as "feelings" about the license. I put in a lot of hours shipping patches that were for nothing, BK is helping avoid that for the current crew."

Elsewhere, Linus Torvalds said:

Guys, calm down.

A few points:

In short: nobody requires BK of anybody else. A lot of people really like using it, though, and it does make some things easier. Some people aren't convinced - David Miller is trying it out, and I haven't heard all happy sounds from him about it. Others have taken to BK like fish to water, and you'll pry it out of their dead cold hands.

The most productive thing people could do might be to just do a BK->CVS gateway, if you really feel like it. Or just go on and ignore the fact that some people are using BK - you don't actually have to ever even know.

Larry McVoy replied, "We've thought of making a readonly CVS pserver interface to BK which would at least make it easy to get the source in some form that the GPL folks like. Somebody else should be able to do that with a perl script. You could attempt a read/write interface as well, that's a lot harder, the impedance mismatch between BK and CVS becomes much more apparent in the read/write case."

3. Some Work On Event Logging

12 Mar 2002 - 18 Mar 2002 (15 posts) Archive Link: "[PATCH-RFC] POSIX Event Logging, kernel 2.5.6 & 2.4.18"

Topics: POSIX, Security

People: Larry KesslerBrian BeattieBernd EckenfelsDominik Kubla

Larry Kessler announced:

This patch, in combination with the event logging and event notification user library, provides a comprehensive event logging package based on the draft POSIX standard 1003.25. See for details and downloads.

A summary of the kernel patch:

  1. A static kernel buffer is implemented for POSIX events logged in the kernel. Size is configurable during kernel build.
  2. If the buffer overruns the oldest events are kept, newest discarded, and a count of discarded events is reported.
  3. Optionally, POSIX events can be created from printk messages (printk messages still go to /var/log/messages, as before)
  4. Functions are provided for:

    • logging directly to kernel event buffer (text string or binary data which gets formatted outside of the kernel)
    • registering facilities beyond the standard ones in syslog.h (device drivers can have facility other than KERN)

  5. Events are displayed on the system console as single-line summary messages (based on printk's default console logging level).

Please be clear that this is NOT intended to replace printk and syslog, but to coexist with them and provide additional capabilities not available with printk/syslog that are highly desirable in large servers and Telecom environments (to name a few).

Dominik Kubla felt that the buffer overrun handling posed a security problem, in that an attacker could simply fill up the buffer and then perform exploits that wouldn't be logged. Larry replied, "Good point, but if the buffer is sized appropriately for the incoming volume of events and the logging daemon is reading the events out of the kernel buffer (as should normally be the case), then you would see the events." He added, "The reasoning behind this approach is to increase the liklihood that events indicating "root cause" would be logged and not over-written by a flood of secondary events. Keep in mind that only events originating in the kernel (or kernel module) are stored in this buffer."

Elsewhere, Bernd Eckenfels thought Larry's patch would be quite useful, but only if it were a replacement for netlink and printk, rather than something intended to coexist with them. He felt that just adding another framework would lead to kernel clutter. But Larry replied that it would be impossible to get every maintainer to cooperate in switching the 41000 printk calls already in the kernel, into his write functions. He said, "Instead we want to provide enhanced logging features for new and updated device drivers and other kernel code--more of a "slow migration over time" approach. We provided the feature that creates POSIX event records from printks so that System Admins, field service, developers testing and debugging their code (just to name a few) could still take advantage of the new tools provided with the user lib (too numerous to mention, but see the spec on the website) for handling printk messages."

He added, "Of course, even with better tools there may still be those who only want to see printks in /var/log/messages. It has even been suggested that events in the event log which did not originate with printk should also be written to /var/log/messages, for this very reason." He and Bernd went back and forth on this for awhile, and at one point Brian Beattie interjected:

I wonder if a slightly different approach might not be better. Instead of adding extra kernel functionality, would it not be possible to define a text format to messages and some SIMPLE macros, to allow printk's to generate the desired information.

I understand about POSIX standards, but POSIX standards are not the infallible word of of the diety of computing and sometimes are completely bogos. While they do provide a thoughtful plan, they are not IMHO some holy grail. for silly standards, see the recent stuff about names for K = 10^6 vs. K= 2^10.

So if one drops strict POSIX compliamce and goes for providing the information, it maye be possible to provide some formating guidelines and support to printk and some log analysis tools to provide 99% solution.

One thing to remember, is that the really hard and important part of logging is not the part that can be legislated, or automated, it is making sure that the correct events are reported in a accurate manner, and this is not a one time job. This being the case, I would rather see effort expended in rationalizing the current printk's and improving their use, than adding some new infrastructure that may well be a perfromance drain and might even be more prone to loss of log messages, than the current method.

Larry agreed that it was important to be skeptical of standards, but said, "in this case the POSIX standard is not a standard, but currently only a draft, and we (the Linux event logging team) have been (and are continuing to be) directly involved it its writing, editing, and (eventual, we hope) adoption as a standard." He went on to say that Brian's idea, while perhaps or perhaps not the way to go, was interesting. He said, "we have, in fact, been discussing how to somehow get more information out of printk without asking kernel maintainers to use a different API. Specifically, we thought about renaming the printk() function and creating a printk macro. In the printk macro you would collect source file name, line number and function name (and maybe some other useful info), and then call the renamed printk function with the original message plus the additional stuff (actually we were thinking call posix_log_write() with the orig. message+addl. info and call the renamed printk with just the original message)." At this point, the discussion petered out.

4. 2.4 Migrates To BitKeeper; BitKeeper Feature Discussion

13 Mar 2002 - 16 Mar 2002 (30 posts) Archive Link: "Linux 2.4 and BitKeeper"

Topics: Kernel Build System, Version Control

People: Marcelo TosattiStephen TorriBen GreearDavid WoodhouseLinus TorvaldsLarry McVoy

Marcelo Tosatti announced, "I've started using BitKeeper to control Linux 2.4 source code. My latest tree can be found at" Stephen Torri replied sarcastically, "If it was not enough that "bleeding-edge" required a pint of blood but now we get BitKeeper access to the latest and greatest. Cool! Maybe I should be on the regular shipment list from the local blood bank. Keep up the good work. I certainly appreciate it." There was no reply to this, but elsewhere, some folks had some problems grabbing Marcelo's tree. At one point, Ben Greear said he'd used 'bk clone bk://' to clone the tree, but added, "However, I see no files, only directories. The files do seem to be in the SCCS directories, but I don't know how to make them appear in their normal place." David Woodhouse replied:

Type 'make config'. Make is clever enough to get the Makefile from SCCS for you. Add the missing dependencies to the Makefile so that make will fetch stuff like scripts/Configure before trying to run it, etc.

Making it get all the files by parsing arch/$(ARCH)/ is a fairly trivial task... but you do need to explicitly check out all the include directories, because we don't know how to deal with that yet. With kbuild-2.4, make dep won't work very well, but kbuild-2.5 ought to be OK with everything but the include files, I think.

Or you could just check it all out beforehand with bk -r co.

Larry McVoy asked if anyone had successfully used the 'make config' incantation in that situation, saying that it would save a lot of space and performance if it worked. But Linus Torvalds replied:

Hey, the _sane_ way to do it is to not have all those crappy SCCS dependencies in all the tools, but to simply make a bk work area be a real file tree!

Larry, your argument that there are tools that are SCCS-aware is just not sane. For each tool that is SCCS-aware, I will name a hundred that are not, and that you're not going to fix. The only sane way to make _everything_ bitkeeper-aware is to keep the tree checked out and to keep the bitkeeper files somewhere else.

Right now simple things like command-line completion and

find . -name '*.[chS]' | xargs grep xxxx

do not work, because they either don't find files or they find the wrong ones (the internal bitkeeper files etc).

I'd much rather have a separate working area, ie if my repository is under ~/BK/repository/kernel/linux-2.5, then the checked out tree would be under ~/BK/repository/kernel/linux-2.5/workarea, and I would just have a simple symbolic link from ~/v2.5 to the workarea (and never even _see_ the BitKeeper files unless I thought I needed to).

None of this "special tools for normal actions" crap.

A couple of posts later, he went on:

The fact is, mixing up the revision control directories and the working area is a design mistake, and one that BK perpetuated due to Larry's infatuation with the fact that "make" and "patch" already know how SCCS works.

(It should be noted that this design mistake is also one of the stumbling blocks for ever improving the BK databases. It limits your viability in the long run, which is why I'm trying to prod Larry into fixing it).

Larry replied:

The "design mistake" was made so that I could have BK generate pure SCCS files and test that I did the same thing as a known working tool, ATT SCCS. By doing that, I easily saved myself a year of design. Making interleaved deltas work is hard for me (we have Rick here now and he's forgotten more about this stuff than I'll ever know, but we didn't have him when I wrote the SCCS compat weave).

At this point, I trust our implementation of the weave more than I trust the ATT one, and ours handles several cases that theirs doesn't, so I'm a lot less concerned about that compatibility.

And we know that we can get better performance, and dramatically reduce fragmentation, by sticking all the files in one big file, and we've known this for a long time. We're gonna do it, you're gonna love, it's less filling, it tastes great. There is only so many things that we can do at once and this is on our short list, but it isn't at the top. Keep that in mind as you push us to make enhancements, there is no free lunch, so prioritize.

I'm gonna hack at least make & patch to know about the new format and work the way they do now. So I can have your cake and eat it too. If I can't get the FSF to take the changes, we'll just ship 'em, we ship diff & patch already, so it's not so hard to alias make='bk make'.

5. Dummy Port Conflicts

14 Mar 2002 - 19 Mar 2002 (49 posts) Archive Link: "IO delay, port 0x80, and BIOS POST codes"

People: Martin WilckRichard B. Johnson

Martin Wilck reported:

the BIOS on our machines (Phoenix) uses IO-port 0x80 for storing POST codes, not only during sytem startup, but also for messages generated during SMM (system management mode) operation. I have been told other BIOSs do the same.

Unfortunately we can't read this information because Linux uses port 80 as "dummy" port for delay operations. (outb_p and friends, actually there seem to be a more hard-coded references to port 0x80 in the code).

It seems this problem was always there, just nobody took notice of it yet (at least in our company). Sometimes people wondered about the weird POST codes displayed in the LCD panel, but who cares once the machine is up...

Would it be too outrageous to ask that this port number be changed, or made configurable?

Richard B. Johnson replied, "This is a 'N' year-old question. Do you know of a port that is guaranteed to exist on the Intel/PC/AT class machine? If so, submit a patch. I proposed using 0x19h (DMA scratch register) several years ago, but it was shot down for some reason. Then I proposed 0x42 (PIT Misc register), that too was declared off-limits. So I suggested that the outb to 0x80 be changed to an inp, saving %eax on the stack first. That too was shot down. So, you try something... and good luck."

Someone suggested making it a config option, but Martin Wilck said even a #define and a comment in the source, explaining how to change the port for a given setup would be sufficient. Later, Martin announced:

this patch makes the use of the "dummy" port 0x80 globally configurable through a macro in the (new) file asm-i386/iodelay.h. I think nobody wants to see this in the configuration menus.

I have tried to capture all accesses to port 0x80, although some may have escaped.

Even if nobody wants to use anything other than 0x80 in the near future, I think the patch is useful because grepping the source for 0x80 is really no fun.

With the patch, our BIOS post code LEDs really stand still.

Some folks went back and forth on the implementation for awhile.

6. BitKeeper Feature Discussion

14 Mar 2002 - 18 Mar 2002 (23 posts) Archive Link: "Problems using new Linux-2.4 bitkeeper repository."

Topics: Version Control

People: James BottomleyJeff GarzikLarry McVoyChrister Weinigel

James Bottomley reported:

How do those of us who've been using the

for development resync against the tree? It looks like the changes from 2.4.18-pre8 onwards all have different patch IDs in the new tree; so when I try to do a pull from my current repository I get tons of conflicts, if I try to do a receive of just the patch set I get a resync error:

takepatch: can't find parent ID|ChangeSet|20020225230300|18879
in RESYNC/SCCS/s.ChangeSet

The thought of taking everything back to the common ancestor and then trying to apply the changes one at a time and adding the change logs by hand isn't that appealing (I have 3 2.4 repositories, some with upwards of 10 additional change sets in them).

Jeff Garzik replied, "Just do a 'bk pull' on my marcelo-2.4 tree. Since it is based on the original linux-2.4 tree just like Marcelo's tree, I was able to merge from my 2.4 line to his 2.4 line." But James said when he'd tried this he got a slew of initial rename conflicts. Jeff replied, "This is normal, you just need to accept the remote changes for all those new/renamed files. BitKeeper doesn't support doing this automatically for all files, so I had to highlight the expected BitKeeper response in another window, and then click <paste> on my mouse around 300 times... (~300 new files)."

Larry McVoy retched into his hand, and offered to add an option to allow automatic acceptance. But he added that he suspected there was some sort of problem. He asked what Jeff's situation had been. Jeff replied:

I started with Linus's linux-2.4 repo and so did Marcelo. We independently checked in 2.4.recent patches (including proper renametool use), which included the ia64 and mips merges, which added a ton of files. When you do a 'bk pull' from Marcelo's linux-2.4 into my old marcelo-2.4 repo, you have to individually tell BitKeeper that you really do want to trust Marcelo's copy over my own, for each of the ~300 new files that were added between Linus's linux-2.4 repo creation and 2 days ago. So I highlighted "rl\ny\n" in another window, and wore out my middle mouse button... Renames could have been handled similarly, but there were few renames, so I just typed "r\ny\n" manually maybe 10 or 20 times.

One could argue that a "rla" or "lla" command would be useful when resolving a conflict between two new files, telling BitKeeper to accept remote (or local) additions in this case _and_ all succeeding cases.

One could also argue that BitKeeper needs to be twacked on the head because it is not detecting that the file-creates and file-renames are 100% the same, content-wise.

Larry replied to the fact that Jeff and Marcelo had independently checked in some recent patches. He said:

OK, so there is the root cause. It's time to talk about duplicate changes. You know how Linus hates bad csets in the history and doesn't want them there? Well, I hate duplicate csets and don't want them there. There are lots of reasons. One reason is that it means revtool is a lot less useful for debugging. If you are trying to track down the change which caused a bug but it is obscured by a duplicate patch, you just got hosed. Another reason is file creates. Suppose you and Marcelo both created a file called "foo". You pull, there is a file conflict, you remove one of the two files. It isn't actually removed, it's just moved to BitKeeper/deleted. Time passes and you or someone else is fixing bugs in a pre-merged copy of the tree and you are updating "foo". You later pull that bugfix into the merged tree and the bugfix happily is applied to the *deleted* copy of the file, since the changes follow the "inode", not the pathname. Bummer, you are now scratching your head wondering where your bugfix went.

There are things we can do in BK to deal with this, but they are not easy and are going to take several months, is my guess. I'd like to see if you can work around this by avoiding duplicate patches. If you can, do so, you will save yourself lots of grief.

If you get into a duplicate patch situation, you are far better off to pick one tree or the other tree as the official tree, and cherrypick the changes that the unofficial tree has and place them in the official tree. Then toss the unofficial tree. I can make you a "bk portpatch" command which does this, we have that already, it needs a bit of updating to catch the comments.

You really want to listen to this, I'm trying to head you off from screwing up the history. If you get 300 renames like this, it's almost always a duplicate patch scenario.

Jeff replied:

I know why it happened, silly.

This was just an example of a real world example that actually happened, where BK sucked ass :)

Marcelo's BK tree did not exist when I created my marcelo-2.4 tree. marcelo-2.4 repo existed for a while and people started using it. Once Marcelo appeared with his "official" BK tree, people naturally want to migrate. There were two migration paths: (1) export everything to GNU patches, or (2) click the mouse 300 times.

So, knowing that duplicate patches are a bad thing helps not in the least here...

A post or two later, he went on:

a fair question would be, is this scenario going to occur often? I don't know. But I'll bet you -will- see it come up again in kernel development. Why? We are exercising the distributed nature of the BitKeeper system. The system currently punishes Joe in Alaska and Mikhail in Russia if they independently apply the same GNU patch, and then later on wind up attempting to converge trees.

Do you see what I'm getting at? In a widely distributed SCM system for an open source project, chances are -good- that some random two or more people will independently apply the same patch.

Larry replied:

The real problem is N sets of diffs being applied and then merged. The revision history ends up with the data inserted N times.

I'm not sure what to do about it. I can handle the duplicate inode case more gracefully but it's a heavy duty rewack.

We could play games where we detect the same patch inserted multiple times and refuse to merge them. Hmm. Hmm. Not sure that helps.

Jeff said:

Hence my suggestion for a short term solution that's immediately useful -- allowing some way to answer "local changes take precedence 100% of the time" or "remote changes ..." with a single command. That was my hack solution that I thought would people might find useful when stuck with the duplicate-patch situation.

In the command line merge tool, when merging a file-create, "rla" would cause the current file conflict, and all future file-create conflicts, to be "won" by the remote side -- essentially creating the effect of typing "rl" 300 times. Apply similar logic to the file-rename merge case. I think the merge command I used in 100% of the cases, during that merge, was 'r'.

If you are stuck with the duplicate patch case, as happened here, I just want to see the pain eased a bit :) IMO you can put off the hard problem if you make the UI a bit better.

Christer Weinigel also suggested, "One variant of this would be to automatically use the remote file as long as the file contents are the same. That way, if I apply a patch locally and Marcello/Linus later apply the same patch and put it into the official tree, I can use the official version. This would probably handle most of the conflicts I have seen so far. If there are any "real" conflicts, I can handle them manually."

7. 2.5.7; Vacation

18 Mar 2002 (2 posts) Archive Link: "Linux 2.5.7"

People: Linus TorvaldsDave JonesJeff Garzik

Linus announced 2.5.7 and added, "NOTE! I'll be gone for a vacation for two weeks, and will not be reading email during the time. So please discuss problems on linux-kernel, with Dave Jones, Jeff Garzik etc handling patches while I'm away."

8. KGDB Documentation

20 Mar 2002 (1 post) Archive Link: "Announce: Documentation on thread analysis with kgdb"

People: Amit S. Kale

Amit S. Kale announced, "Documentation on thread analysis using kgdb can be found at" There was no reply.







Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.