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...

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.

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 ;)

We, the undersigned members and officers of the Open Source Club at the Ohio State University, are unhappy with the advocacy of the proprietary (http://www.mit.edu/afs/athena/user/x/i/xiphmont/Public/critique.html) 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 kernel.org.

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 (http://www.regexps.com/#arch) or Subversion (http://subversion.tigris.org) are completed. Moreover, full-featured, completely functional free versioning sytems are currently available, such as PRCS (http://prcs.sourceforge.net) and CVS (http://www.cvshome.org). 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.

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.

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.

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.

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.

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.

Guys, calm down.

A few points:

• I certainly don't require BK use of anybody. It makes my life simpler with some people (mainly the ones that tend to be maintainers of subsystems and send me lots of patches), but there are many developers who do NOT use BK, and it doesn't slow them down at all.

  For example, see the FS patches from Al Viro: the only thing that BK has resulted in as far as Al is concerned is that the changelogs are a lot better and include his email comments.

  And I also export my tree as regular patches, the way I always have (well, the actual format changed subtly, but that's purely syntactic)

• If Larry turns to the dark side (or, as some would say, the "even darker side" ;) we're _still_ ok. The data isn't going anywhere, he can't close that down. We'd just have to export it into a new format.

  If worst comes to worst, and nobody has fixed CVS/subversion/whatever by then, I can even just go back to how I used to work. Nothing lost.

• If people in the open-source SCM community wake up and notice that the current open-source SCM systems aren't cutting it, that's _good_. But it's absolutely NOT an excuse to use them today. Sorry. I use CVS at work, and I could never use it for Linux. I took a look at subversion, and it doesn't even come close to what I wanted.

  And I personally refuse to use inferior tools because of ideology. In fact, I will go as far as saying that making excuses for bad tools due to ideology is _stupid_, and people who do that think with their gonads, not their brains.

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.

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 http://evlog.sourceforge.net/ 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).

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.

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 Config.in files by parsing arch/$(ARCH)/config.in 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.

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.

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).

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'.

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?

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.

How do those of us who've been using the

http://gkernel.bitkeeper.net/marcelo-2.4

for development resync against the kernel24.bkbits.net 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
jgarzik@mandrakesoft.com|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).

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.

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.

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 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.

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.

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.