Kernel Traffic #334 by Zack Brown
[email protected] Sat, 26 Nov 2005 13:15:46 -0800
| Newsgroups | gmane.linux.kernel.kernel-traffic |
|---|---|
| Message-ID | <[email protected]> |
Kernel Traffic #334 For 26 Nov
By Zack Brown
No, I did that on purpose.
--Linus Torvalds
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Mailing List Stats For This Week
* Threads Covered
1. 13 Oct - 22 Oct (10 Status Of Sharp SL-C3000 Support
posts)
2. 16 Oct - 24 Oct (75 Linux 2.6.14-rc4-mm1 Released; NTFS Lurching
posts) Toward Writable
3. 17 Oct - 24 Oct (20 git/Cogito Tutorial; Some Discussion Of The
posts) Merge Problem
4. 17 Oct - 24 Oct (7 Another git/Cogito Tutorial
posts)
5. 19 Oct - 21 Oct (6 Linux 2.6.14-rc5 Released
posts)
6. 21 Oct - 25 Oct (21 git File-History Tracking; Some Consideration
posts) Of Rename Tracking
7. 22 Oct - 24 Oct (15 RCU Infrastructure Torture Test For Hotplug,
posts) Realtime, And More
8. 23 Oct - 25 Oct (2 Support For Parallel Port On SGI 02
posts) Workstation
9. 23 Oct (1 Improved git-mv May Replace git-rename
post)
10. 25 Oct (1 ethtool Development Migrates To git
post)
11. 25 Oct - 27 Oct (5 Making gitk Play Nice With --dense
posts)
12. 25 Oct - 26 Oct (10 Swap-Based Page Migration
posts)
13. 27 Oct - 3 Nov (16 Linux 2.6.14 Released
posts)
14. 28 Oct (3 Status Of Native POSIX Thread Library Support
posts) In 2.4 And 2.6
15. 29 Oct - 31 Oct (32 Some Discussion Of 2.6 Maintenance Patterns
posts)
16. 29 Oct - 30 Oct (17 Splitting The swsusp Code Into Two Subsystems
posts)
17. 29 Oct - 2 Nov (28 git 0.99.9 Released; Documenting More Of
posts) git's Power
18. 30 Oct - 1 Nov (19 Removing Obsolete OSS Sound Drivers
posts)
19. 30 Oct (4 Emails Delayed From Reaching Kernel
posts) Maintainers
20. 31 Oct - 1 Nov (28 NTFS Updates; Instructions On Testing
posts)
21. 1 Nov (1 Fresh Attempt To Remove DevFS
post)
22. 1 Nov (1 '(H)gct' git And Mercurial GUI-Enabled Commit
post) Tool Update
23. 2 Nov (1 git 0.99.9b In Use On kernel.org Machines
post)
Mailing List Stats For This Week
We looked at 2243 posts in 14MB. See the Full Statistics.
There were 662 different contributors. 246 posted more than once. The average
length of each message was 106 lines.
+-----------------------------------------------------------------------------+
| The top posters of the week | The top subjects of the week were: |
| were: | |
|--------------------------------+--------------------------------------------|
| |78 posts in 364KB for "new (now current |
|88 posts in 386KB by |development process)" |
|[email protected] |41 posts in 172KB for "3d video card |
|74 posts in 515KB by russell |recommendations" |
|king |38 posts in 178KB for "best way to handle |
|73 posts in 560KB by adrian bunk|leds" |
|68 posts in 384KB by |34 posts in 160KB for "[patch]: clean up of |
|[email protected] |__alloc_pages" |
|51 posts in 492KB by greg kh |33 posts in 159KB for "ntp broken with |
| |2.6.14" |
+-----------------------------------------------------------------------------+
These stats generated by mboxstats version 2.8
1. Status Of Sharp SL-C3000 Support
13 Oct - 22 Oct (10 posts) Archive Link: "spitz (zaurus sl-c3000) support"
Topics: I2C
People: Pavel Machek, Richard Purdie
Pavel Machek asked about the status of the Sharp SL-C3000 (http://conics.net/
shp/pda/zaurus-sl-c700/sl-c3000/) (Spitz) PDA, saying, "I got spitz machine
today. I thought oz3.5.3 (http://www.openzaurus.org/wordpress/) for spitz would
be 2.6-based, but found out that I'm not _that_ fortunate." He saw from the
changelogs that Spitz support in some form had come into the kernel in
2.6.14-rc2, but he pointed out that the 2.6 port page (http://www.orca.cx/
zaurus/) seemed old. Specifically, he asked, "Is there simple way to tell spitz
and tosa apart (like without opening the machine)?" Tosa being the SL-6000 (
http://conics.net/shp/pda/zaurus-sl-c700/sl-6000.htm) .
Richard Purdie said, "oz 3.5.4 is due for release soon and will hopefully have
a 2.6 option for spitz." He also confirmed that the port page was indeed
outdated. He added:
I got a spitz recently which moved 2.6 for it forwards a lot. Have a look at:
http://www.rpsys.net/openzaurus/
This file should give you an idea of which patches to apply in what order:
http://www.rpsys.net/openzaurus/temp/linux-openzaurus_2.6.14-rc1.bb
With my patch series applied, we're missing usb client (usb host works) and
sound support.
Mainline is missing power management and currently fails to compile without my
patch series but I'm working on that.
Pavel asked if there was a "preview" of oz 3.5.4 anywhere, and Richard replied:
I'm no sure offical preview images exist but here's something I built myself
recently:
http://www.rpsys.net/openzaurus/temp/spitz/
Rename the gpe or opie file "hdimage1.tgz" to flash depending on what flavoured
image you'd like. You need the other files including gnu-tar. You don't need an
initrd.bin file as under 2.6 we can boot directly from the microdrive.
I'm hoping these work - I'm not sure I've tried one of them... :)
Pavel asked what he could do to help the project in general, and Richard
summarized:
I'm open to any help in getting the none ipaq/tosa things merged with mainline.
Have a look through them patch series and see if there's anything you fancy
taking on. Most of them are simple fixes although some are nasty hacks we need
to find some way of doing nicely.
The biggest thing is the battery/power management patch. I've just agreed some
changes to enable it to stand a chance of making mainline. It probably needs
more coding style cleanup.
There's also sound to get working although so code arrived yesterday which
should help with that. The usb client code exists in handheld.org's kernel26
cvs tree. We need to extract it, fix any bugs and talk to the usb developers
about it.
Its a shame you don't have a C1000 as there's a nasty bit of coding someone
with such a device needs to do to complete mainline 2.6 support (I2C driver for
its IO Expander to enable access to its extra GPIOs).
Pavel didn't take any of that up explicitly, but they did continue to talk for
awhile about how to get things working for Pavel, and how to interpret various
ambiguous situations.
2. Linux 2.6.14-rc4-mm1 Released; NTFS Lurching Toward Writable
16 Oct - 24 Oct (75 posts) Archive Link: "2.6.14-rc4-mm1"
Topics: FS: NTFS, I2C, Kernel Release Announcement, PCI, USB
People: Andrew Morton, Anton Altaparmakov
Andrew Morton announced Linux 2.6.14-rc4-mm1, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.14-rc4/
2.6.14-rc4-mm1/
* Lots of i2c, PCI and USB updates
* Large input layer update to convert it all to dynamic input_dev allocation
* Significant x86_64 updates
* MD updates
* Lots of core memory management scalability rework
One of the patches was also an NTFS update. Anton Altaparmakov replied:
This is a request for testers for ntfs. 2.6.14-rc4-mm1 contains a pretty much
complete re-write of file write support so some more testers than just myself
would be good before I submit it for inclusion in 2.6.15...
The rewrite means that the following features are now supported:
Given an existing uncompressed and unencrypted file, you can use:
* write(2) to write to the file, including beyond the end of the existing
file, and the file will be extended appropriately. Both resident and
non-resident files are supported. Support for heavily fragmented files
still has some limitations but you will just get an EOPNOTSUPP error if you
hit one. Everything will still be consistent on the volume. Sparse files
can also be written to and holes will be filled in appropriately.
* truncate(2) and ftruncate(2) to change the size of the file, inlcuding
using open(2) with O_TRUNC flag. As with write(2) there still are some
limitations for heavily fragmented files, and as above, everything will
still be consistent on the volume if you hit an unsupported case.
What this means is that you can now run your favourite editor on an existing
file, e.g. "vim /ntfs/somefile.txt" works fine and you can save your changes.
Also things like running OpenOffice should work to edit existing MS Office
documents but I haven't tried it yet (it should work as long as OpenOffice does
not need to create temporary files in the same directory as the document).
Still not supported features are creation/deletion of files/directories and
mmap(2) based writes to sparse regions of files. (The mmap(2) support has not
been modified since the last release, only the file write(2) support was
rewritten.)
If you do try it, please let me know how it worked for you! - Thanks a lot in
advance for testing!
Alberto Patino tested it out, but the code corrupted his filesystem so badly he
could no longer boot Windows 2000; and an examination of two files he edited
showed parts of each file in the other. Anton replied:
You should be able to hopefully fix windows by booting with the installation CD
and going into recovery console and running chkdsk on the partition. You can
also try running ntfsfix from ntfsprogs and then booting into windows. This may
be sufficient to allow it to do a chkdsk on the partition before it crashes.
I found a bug that caused corruption of the openoffice document as you
described. The fix is below.
3. git/Cogito Tutorial; Some Discussion Of The Merge Problem
17 Oct - 24 Oct (20 posts) Archive Link: "LCA2006 Git/Cogito tutorial"
Topics: PCI, Version Control
People: Martin Langhoff, Junio C. Hamano, Linus Torvalds, Petr Baudis
On the git mailing list, Martin Langhoff said:
Sounds like I will be hosting a Git/Cogito tutorial in the upcoming LCA2006
(Dunedin, NZ, Jan 25~28). Given that I do have some significant holes in my git
knowledge (no, really!?) I'll be happy if other git hackers/users are present
at LCA and willing to take part in the tutorial.
Petr Baudis hinted earlier that he might be coming, as did Linus (but he was
hoping for a sponsor, I'm not sure whether he'll be there or not). Speak up if
you'll be there!
I'll post my slides and presentation plan beforehand to the list, to avoid
spreading misinfirmation/bad practices. They will probably be based on a recent
talk I gave @ Wellington Perl Mongers about swtiching to Git/Cogito:
http://wellington.pm.org/archive/200510/git/
The feedback (from both non-cogito-users and actual cogito-users) was that I
made it sound too complicated, so the current plan is to focus on the tutorial
part, and leave "under the hood" parts for a rainy day or for an after tutorial
in-the-corridor chat.
Petr Baudis offered some suggestions, and remarked on Martin's description of
the merge feature in his tutorial. Martin had said that git and Cogito provided
"Very fast stupid merge" and "very smart, slow merges when stupid won't do".
Petr said he didn't know of any merges that could be termed "very smart", and
asked what Martin was referring to. Martin replied, "I'm very impressed with
git-merge.sh, which first does the simple git-read-tree -m, and it can then try
several merger scripts to resolve the index. The "smartest" merge resolver we
have follows renames, but we could have language-specific and project-specific
resolvers, for instance." The discussion branched off in different directions
at this point. In one of these, Junio C. Hamano replied:
I should not be saying this because I am the primary guilty party, but you
should not be so impressed.
Being able to specify which merge strategy to use is a useful thing, but I do
not think being able to try more than one merge strategies automatically, while
it has some coolness value, is very useful in practice.
The language-specific or project-specific part should be made orthogonal to
merge strategy modules, which currently is not. The primary thing Daniel's
git-merge-resolve and Fredrik's git-merge-recursive do is to figure out which
paths can be resolved without merging the file contents, and which paths need
to be resolved with file contents merge, and they use different strategies to
find which 3 variants of the contents to use for that final merge.
But at the end of the day, merging the contents is done by running 'merge' in
either case. This should be made either customizable, or we ship our standard
one that can be extended to first run 'file' to see the file content type of
what is being merged and run content specific merge program if there is one.
Even if we did that, we are still doing 3-way merge; git-merge framework may
not mesh very well when we want to use something like codeville merge which is
not based on 3-way.
Linus Torvalds said:
Oh, the git merge is about a million times better than any silly weave merge
with extra BonusPoints and MagicCapitalizedNames.
Why? Because if you want to be slow and careful, you can always just create the
weave after-the-fact and do a weave merge.
And because well-behaved git merges are so fast, you can actually afford to so
so.
There's nothing magic in a weave merge. It's just a trick. It doesn't need the
files to be in weave format beforehand, even though people seem to believe that
file formats go together with it.
If somebody thinks a weave merge is wonderful and fixes everything, I have to
rain on their parade. You still need to manually fix real conflicts up, and
regardless, what kind of merge you do has _nothing_ to do with how you maintain
your files.
If you want to do a weave merge inside git, then the way to do that is to just
create the weave on demand in the (rare) case where it's needed. We have all
the history. You might even just do a "lazy weave", which just starts from the
common parent, and ignores the history before that.
Much cheaper that way, and arguably nicer (others will argue that you want to
take history into account, to decide about undo's etc. It's a matter of taste).
The thing is, automatic merging isn't all _that_ important. The thing that made
BK wonderful at merging was that it had a wonderful tool for merging for when
there were real clashes, which is where the _really_ nasty cases are. The
actual automatic merge wasn't necessarily anything magical.
(Same went for applying diffs, btw. What made BK nice was "renametool". Of
course, it was also what made me decide that tracking renames was the wrong
thing to do in the first place, but if you make a CMS that does renames, you'd
better have a "renametool").
And if you have a tool that helps you visually merge the _real_ clashes, it
doesn't much matter if you are only half-way decent on the automatic ones.
They'll be so trivial that nobody cares.
And it doesn't matter _how_ good your automatic merges are, there always _will_
be real clashes.
[ Side note. Think about this for a while. Git did three-way merges pretty much
since day one, but they only became _useful_ when we made it easy to see the
merge conflicts and fix them up. That's a fundamental lesson right there: you
don't have to be perfect, you have to make it easy for the user to fix up your
imperfections. ]
So we should spend time on making it easy to see what the clash was, and on
tools to help resolve them. Some random merge-strategy-of-the-day is just
bling-bling.
The reason people like merge strategies is that it's a nice area for some
mental masturbation. You can create all these fancy examples. And then can
ignore the fact that most real merge problems end up being two people changing
the same code in different ways, that just need manual merging.
Don't get me wrong - if somebody does a nice automated merge for git, it's a
good thing, but it's probably much more important to try to integrate something
like xxdiff to a git workflow. And _that_ level is probably where you want to
have special language-based coloring etc to further help things out.
So keep your eyes on the ball. And "automatic merge" isn't it.
Petr replied, "The *primary* reason for new merge strategies is not reducing
number of conflicts, but actually being able to force a conflict at places
where it isn't crystal-clear what the resolution should be (but not conflicting
where it should be clear), and especially at places where the three-way merge
*silently* gets it *wrong* without throwing any conflicts. And weren't it you
who wanted a conservative merge strategy which wouldn't ever do that?" Linus
replied:
A three-way merge is plenty conservative for me.
Any merge will always get some case wrong, exactly the same way any merge will
always get some that require fixing up, even if a human might say "that's a
stupid merge". Two patches add the same thing to different places (an unsorted
array of PCI ID's or whatever), and pretty much any merge ever will silently
"mismerge" it as far as a human is concerned. From a _technical_ point it was
correct. In practice, it wasn't.
So when I say "conservative", I don't mean "can never mis-merge", because such
a thing doesn't exist. No, "conservative" means that it seldom does it in
practice, and that when it happens, you can at least understand why it
happened.
A simple strategy that makes people understand what happened is often much
better than a more complex one. And you should never underestimate the
importance of peoples _expectations_. A three-way merge has a _huge_ advantage
in that absolutely tons of people are used to what it does: even when they
don't necessarily "understand" the merge (they never cared), if they've worked
with CVS they've seen them before.
Don't get me wrong - a weave merge is pretty damn conservative too. I'm not
down on weave merges, I just don't think that the difference is that huge in
practice - the difference between a three-way merge and a weave merge is much
smaller than the advantage of a good graphical tool and a good workflow.
That's really my argument here: automated merges aren't the end-all. I realize
that a lot of SCM people think that three-way merges are old and boring and
stupid, but the fact is, sometimes the old ways aren't the best ways, but
sometimes they are old just because they are good enough.
4. Another git/Cogito Tutorial
17 Oct - 24 Oct (7 posts) Archive Link: "Scribblings for a cogito/git
tutorial"
People: Horst von Brand, Petr Baudis
On the git mailing list, Horst von Brand said, "I've also been asked around
here for a cogito+git tutorial, to that end I've made up a script that
simulates several developers interacting. Hacking around is simulated by
patching, ed(1) scripts (merges don't turn out the same diff every time), and
plain copying new files in. I've set up a GPG key with an empty passphrase
(comment is "Experimental") to have signed tags, etc. in a convenient manner.
The idea is to create interesting histories (for browsing) and show off the
commands in a compact way. If only there was a convenient way to run a strech
of the (bash) script, look at the results, and then resume..." He gave a link
to a git repository (http://pincoya.inf.utfsm.cl/Script.git) of his script and
supporting files. Petr Baudis said he loved it, and asked if it could be
released under the GPL and added to the Cogito official documentation. Horst
said he'd be honored, and added, "I realized later that I didn't clarify the
license. It's on my TODO list ;-)" He also noticed that Petr had not only
included the latest version of the tutorial into the Cogito repository, but the
entire history of its development as well.
5. Linux 2.6.14-rc5 Released
19 Oct - 21 Oct (6 posts) Archive Link: "Linux v2.6.14-rc5"
Topics: Kernel Release Announcement
People: Linus Torvalds
Linus Torvalds announced Linux 2.6.14-rc5, saying:
Yeah, I know I said -rc4 was going to be the last one, but as some of you may
have noticed from the discussions, a day before I was planning on releasing
2.6.14 we found a couple of bugs (nasty RCU callback delays, swiotlb, etc). The
fixes for those weren't all that complicated, but the problems were subtle
enough that I wanted to get them fixed and have another -rc before final
release.
So here it is. There's a number of other small random fixes in there too.
6. git File-History Tracking; Some Consideration Of Rename Tracking
21 Oct - 25 Oct (21 posts) Subject: "git-rev-list: add "--dense" flag"
Topics: Version Control
People: Linus Torvalds, Petr Baudis, Junio C. Hamano
On the git mailing list, Linus Torvalds said:
This is what the recent git-rev-list changes have all been gearing up for.
When we use a path filter to git-rev-list, the new "--dense" flag asks
git-rev-list to compress the history so that it _only_ contains commits that
change files in the path filter. It also rewrites the parent information so
that tools like "gitk" will see the result as a dense history tree.
For example, on the current kernel archive:
[torvalds@g5 linux]$ git-rev-list HEAD | wc -l
9904
[torvalds@g5 linux]$ git-rev-list HEAD -- kernel | wc -l
5442
[torvalds@g5 linux]$ git-rev-list --dense HEAD -- kernel | wc -l
356
which shows that while we have almost ten thousand commits, we can prune down
the work to slightly more than half by only following the merges that are
interesting. But further, we can then compress the history to just 356 entries
that actually make changes to the kernel subdirectory.
To see this in action, try something like
gitk --dense -- gitk
to see just the history that affects gitk. Or, to show that true parallel
development still remains parallel, do
gitk --dense -- daemon.c
which shows some parallel commits in the current git tree.
Signed-off-by: Linus Torvalds <[email protected]>
---
I'm really happy with how this turned out. It's a bit expensive to run on big
archives, but I _really_ think it's quite spectacular. And likely very useful
indeed.
For example, say you love gitk, but only care about networking changes. Easy
enough, just do
gitk --dense -- net/ include/net/
and off you go. It's not free (we do a _lot_ of tree comparisons), but dammit,
it's fast enough that it's very very useful. The tree comparisons are done very
efficiently.
This is _way_ more powerful than annotate. Interested in just a single file?
Just do
gitk --dense -- kernel/exit.c
and it will show the 17 or so commits that change kernel/exit.c with the right
history (it turns out that there is no parallel development at all in that
file, so in this case it will linearize history entirely).
Damn, I'm good.
He added in reply:
one additional point.
This took 0.91 seconds to complete on the current kernel history on my machine
with a pretty much fully packed archive, and the memory footprint was a total
of about 12MB.
And it scales pretty well too. On the historical linux archive, which is three
years of history, the same thing takes me just over 12 seconds and 52MB, and
that's for the _whole_ history. And it's not just following one file: it's
following that subdirectory.
So it really is pretty damn cool.
Of course, I might have a bug somewhere, but it all _seems_ to work very well
indeed.
Marco Costalba was very impressed with this, and updated the qgit graphical
archive browser to also support the --dense option.
Elsewhere, Petr Baudis raised an old question, "How to track renames? I believe
the situation has changed in the last half a year. GIT really is a full-fledged
SCM by now (at least its major part code-wise), and I think it's hopefully
becoming obvious that we need to track renames." [...] "If I convince you that
it is worth tracking the renames explicitly, "how" is already a minor
question." Linus replied:
Never. I'm 100% convinced that tracking renames is WRONG WRONG WRONG.
You can follow renames _afterwards_.
Git tracks contents. And I think we've proven that figuring out renames
after-the-fact from those contents is not only doable, but very well supported
already.
I'm convinced that git handles renames better than any other SCM ever. Exactly
because we figure it out when it matters.
Petr tried to discuss it, but Linus closed down the argument with, "The fact
is, users have not a frigging clue when a rename happens. I told you before,
I'll tell you again: if you depend on users telling you about renames, you'll
get it wrong. You'll get it wrong quite often, in fact. This is not something
I'm going to discuss again. Go back to all the same arguments from 6 months
ago. I was right then, I'm right now."
Elsewhere, he posted some pseudo-code:
let's say that you want to follow a certain filename, what you can do is
basically (fake shell syntax with "goto restart")
rev=HEAD
restart:
git-rev-list $rev --dense --parents -- "$filename" |
while read commit parent1 restofparents
do
if [ "$restofparents" ]; then
.. it's a merge, do whatever it is you do
with merges ..
else
shaold=$(git-ls-tree $parent -- "$filename")
shanew=$(git-ls-tree $commit -- "$filename")
# Did it disappear?
# Maybe it got renamed from something
if [ -z "$shaold" ]; then
old=$(git-diff-tree -M -r $commit |
grep " R .* $filename")
echo "rename? $old"
filename=figure-it-out-from-$old
rev=$parent
goto restart
fi
git-diff-tree -p $commit -- "$filename"
fi
while
or something similar.
In other words: you'll basically have to figure out the renames on your own,
and follow the renaming, but something like the above should do it.
Junio C. Hamano replied, "Isn't that only true because you are not doing more
than "have these paths change" in the new rev-list that already has part of
diff-tree? If rev-list can optionally be told to detect renames internally (it
has necessary bits after all), it could adjust the set of paths to follow when
it sees something got renamed, either by replacing the original path given from
the command line with its previous name, or adding its previous name to the set
of path limitters (to cover the copy case as well)." Linus said:
The problem with renames isn't the straight-line case.
The problem with renames is the merge case. And quite frankly, I don't know how
to handle that sanely.
If everything was straight-line (CVS), renames would be trivial. But
git-rev-list very fundamentally works on something that isn't. So let's look at
the _fundamental_ problem:
* git-rev-list traverses one commit at a time, and it doesn't even _know_
whether it has seem all the parents of that commit during the first phase.
The first phase is the "limit_list()" thing, which is when we decide which
commits are reachable, uninteresting, and which merges to follow.
Now, think about this: since we don't even know that we've seen all
parents, that pretty much by definition means that we can't know what has
been renamed if we were to track it.
* in the second phase (which is where I do the densification), we do actually
have the full tree and that makes a lot of things a lot easier to do. When
it comes to dense, for example, it means that I know all the UNINTERESTING
logic has already been done, and that all merges have been simplified.
But in the second phase, we couldn't do rename detection either, since by
then, we've already fixed the list of names as far as merges are concerned.
And note that this fundamental issue is true _whether_ we have some explicit
rename information in a commit or not.
Git-rev-list has a few additional issues that make it even more interesting:
* git-rev-list fundamentally is designed for multiple heads. There is no one
special "origin" head. We might not have _one_ end-point, we might have
twenty-five different heads we're looking at at the same time. Try
gitk --all --dense -d -- git-fetch.c
on the current git archive, and be impressed by how well it works (and yes,
you'll see a funny artifact: "--dense" never removes a line of development
entirely, so you'll see a single dot for the two "unrelated" lines: "gitk"
and "to-do" do not share a root with the rest of them. You'll get a single
dot for that root, even if it obviously doesn't actually change
"git-fetch.c").
You'll also very clearly see the "Big tool rename" which created that name:
it will be the first commit after the root that is visible that way.
* path limiters are fundamentally designed to take a list of paths and
directories. Personally, I find that to be a lot more important than a
single file. That's very efficient the way we do it, but if you were to
_change_ the list of paths, you'd basically have to track those changes
over history.
(This actually happens even with a single path - imagine a merge, and a
rename down one line of the merge. You'll have to keep track of different
files for the different lines of development, and then when they join
together, and the rename only happened in one of them, you'll have to make
an executive decision, or just continue to track _both_)
So what do I propose? I propose that you realize that "git-rev-list" is just
the _building_ block. It does one thing, and one thing only: it creates
revision list.
A user basically _never_ uses git-rev-list directly: it just doesn't make
sense. It's not what git-rev-list is there for. git-rev-list is meant to be
used as a base for doing the real work. And that's how you can use it for
renaming too.
If you think of "git-rev-list --dense -- name" as a fast way to get a set of
commits that affect "name", suddenly it all makes sense. You suddenly realize
that that's a nice building block for figuring out renames. It's not _all_ of
it, but it's a big portion.
To go back to "gitk", let's see what the path limitation shows us. Right now,
doing a
gitk --all --dense -d -- git-fetch.sh
only shows that particular name, and that's by design. Maybe that's what the
user wants? You have to realize that especially if you remember an _old_ name
that may not even exist any more, that's REALLY what you want. Something that
works more like "annotate" is useless, because something that works like
annotate would just say "I don't have that file, I can't follow renames" and
exit.
So the first lesson to learn is that following just pure path-names is actually
meaningful ON ITS OWN! Sometimes you do NOT want to follow renames.
For example, let's say that you used to work on git 4 months ago, but gave up,
since it was too rough for you. But you played around with it, and now you're
back, and you have an old patch that you want to re-apply, but it doesn't talk
about "git-fetch.sh", it talks about "git-fetch-script". So you do
gitk --dense -- git-fetch-script
and voila, it does the right thing, and top of the thing is "Big tool rename",
which tells you _exactly_ what happened to that PATHNAME.
See? Static pathnames are important!
Now, this does show that when you _do_ care about renames, "gitk" right now
doesn't help you very much (no offense to gitk - how could it know that
git-rev-list would give it pathname detection one day?). Let's go back to the
original example, and see what we could do to make gitk more useful..
gitk --all --dense -d -- git-fetch.sh
Go and select that "Big tool rename" thing, and start looking for the rename..
You won't find it. Why? You'll see all-new files, no renames. It turns out that
"gitk" follows the "parent" thing a bit _too_ slavishly, which is correct on
one level, but in this case with "--dense" it turns out that what you want to
do is see only what _that_ commit does, not what that commit did relative to
its parent (which was the initial revision).
So while "--dense" made gitk work even without any changes, it's clear that the
new capability means that gitk might want to have a new button: "show diff
against 'fake parent'" and "show diff against 'real parent'".
If you want the global view, the default gitk behaviour is correct (it will
show a "valid" diff - you'll see everything that changed between the points it
shows). But in a rename-centric world, you want the _local_ change to that
commit, and right now gitk can't show you that.
So for trackign renames, we probably want that as a helper to gitk.
Also, gitk has a "re-read references" button, but if you track renames, you
probably want to do more than re-read them: you want to re-DO them with the
"Big rename" as the new head (forget the old references entirely), and with the
name list changed. New functionality (possibly you'd like to havea "New wiew"
button, which actually starts a new gitk so that you can see both of them).
Right now you'd have to do it by hand:
gitk --dense 215a7ad1ef790467a4cd3f0dcffbd6e5f04c38f7 -- git-fetch-script
(where 215a.. is the thing you get when you select the "Big tool rename")
You'd also probably like to have some way to limit the names shown for the
git-diff-tree in gitk.
In short, the new "gitk --dense -- filename" doesn't help you nearly as much as
it _could_. But when you squint a bit, I think you'll see how it's quite
possible to do...
7. RCU Infrastructure Torture Test For Hotplug, Realtime, And More
22 Oct - 24 Oct (15 posts) Archive Link: "[PATCH] RCU torture-testing kernel
module"
Topics: Hot-Plugging, Real-Time
People: Paul E. McKenney, Kyle Moffett, Badari Pulavarty, Andrew Morton, Ingo
Oeser
Paul E. McKenney said:
This patch is a rewrite of the one submitted on October 1st, using modules (
http://marc.theaimsgroup.com/?l=linux-kernel&m=112819093522998&w=2).
This rewrite adds a tristate CONFIG_RCU_TORTURE_TEST, which enables an intense
torture test of the RCU infratructure. This is needed due to the continued
changes to the RCU infrastructure to accommodate dynamic ticks, CPU hotplug,
realtime, and so on. Most of the code is in a separate file that is compiled
only if the CONFIG variable is set. Documentation on how to run the test and
interpret the output is also included.
This code has been tested on i386 and ppc64, and an earlier version of the code
has received extensive testing on a number of architectures as part of the
PREEMPT_RT patchset.
Ingo Oeser pointed out that this feature should really depend on the
DEBUG_KERNEL configuration option; but this led to the discovery that depending
on DEBUG_KERNEL would erroneously cause additional debugging code to be
included in the compiled binary. After some back-and-forth that included Andrew
Morton, the bug was fixed and the dependency updated.
Meanwhile, Badari Pulavarty tested the feature, reporting long boot delays and
a lot of CPU hogging. Kyle Moffett explained, "Uhh... It's a torture test. What
exactly do _you_ expect it will do? I think the idea is to enable it as a
module and load it when you want to start torture testing, and unload it when
done. "TORTURE_TEST"s are not for production systems :-D." Barari said he
expected some sort of /proc interface to turn the feature on and off. But as
Kyle went on to say, the feature should be turned on or off by loading or
unloading the module. And Paul, close by, said, "I wonder if I should somehow
exclude "=y" on this one -- I haven't come up with any case where it is
useful." But there was no real discussion on that.
8. Support For Parallel Port On SGI 02 Workstation
23 Oct - 25 Oct (2 posts) Archive Link: "[PATCH] Parallel port support for
SGI O2"
People: Arnaud Giersch
Arnaud Giersch said:
I wrote a low-level parallel port driver for the built-in port on SGI O2
(a.k.a. IP32).
The parallel port is driven by a standard ECP chipset, with memory-mapped I/O
registers. That's why it was not possible to use the parport_pc module which
assumes port-mapped I/O registers.
What works:
* Basic modes are supported: PCSPP, PS2.
* Compatibility mode with FIFO support is present.
* FIFO can be driven with or without interrupts.
What does not work:
* DMA support is not implemented (lack of documentation). If you have any
information, please tell me.
* EPP and ECP modes are not implemented (lack of interest). I currently do
not own any peripheral supporting this extended modes. It should not be too
difficult to do.
All tests were done with an HP LaserJet 5MP connected to a R5000 SGI O2.
The module is named parport_ip32. The patch is not included in this mail
because it is not very small (2383 lines, 73 Kb). It is however avalaible from:
http://arnaud.giersch.free.fr/parport_ip32/parport_ip32-latest.patch.gz
The patch is against the latest Linux/MIPS kernel (2.6.14-rc2 as of today). If
you prefer that I post it on a mailing list, please just tell me where, and how
(inlined, or gzip'ed attached file).
Further informations are available on:
http://arnaud.giersch.free.fr/parport_ip32.html
9. Improved git-mv May Replace git-rename
23 Oct (1 post) Archive Link: "[PATCH] This commit implements git-mv"
Topics: Version Control
People: Josef Weidendorfer
On the git mailing list, Josef Weidendorfer implemented the git-mv command, to
allow file renaming. He said:
It superceeds git-rename by adding functionality to move multiple files,
directories or symlinks into another directory. It also provides according
documentation.
The implementation renames multiple files, using the arguments from the command
line to produce an array of sources and destinations. In a first pass, all
requested renames are checked for errors, and overwriting of existing files is
only allowed with '-f'. The actual renaming is done in a second pass. This
ensures that any error condition is checked before anything is changed.
With his patch, Josef included a changelog entry:
The recent request on the list for "mv" in GIT reminded me about an addition to
git-rename I made a week ago. I renamed it to "git-mv" and added some
documentation.
If this works, we can remove git-rename sometimes in the future.
I should complement this command with tests. Also, a nice addition would be to
support an interactive mode like 'mv', by asking if files should be
overwritten.
By the way, it also checks for a request to move a directory into itself, which
of course is an error.
Option "-k" is good for this: E.g. a "git-mv -k * dir" moves all revision
controlled files and directories (but not "dir"!) into "dir". "-k" makes sure
that the errors (trying to move "dir" into itself, or move files without
revision control around) will not terminate the command but silently ignored
and skipped. "-k" was taken from "make": Continue even on an error.
10. ethtool Development Migrates To git
25 Oct (1 post) Archive Link: "ethtool git repo created"
People: Jeff Garzik
Jeff Garzik said, "After sitting around in a non-public subversion repo for far
too long, I've stuffed the latest ethtool source code into a git repository. As
soon as it finished mirroring, it will be available at rsync://rsync.kernel.org
/pub/scm/linux/kernel/git/jgarzik/ethtool.git"
11. Making gitk Play Nice With --dense
25 Oct - 27 Oct (5 posts) Archive Link: "Make "gitk" work better with dense
revlists"
People: Linus Torvalds, Paul Mackerras, Junio C. Hamano
On the git mailing list, Linus Torvalds said:
To generate the diff for a commit, gitk used to do
git-diff-tree -p -C $p $id
(and same thing to generate filenames, except using just "-r" there) which does
actually generate the diff from the parent to the $id, exactly like it meant to
do.
However, that really sucks with --dense, where the "parent" information has all
been rewritten to point to the previous commit. The diff actually works exactly
right, but now it's the diff of the _whole_ sequence of commits all the way to
the previous commit that last changed the file(s) that we are looking at.
And that's really not what we want 99.9% of the time, even if it may be
perfectly sensible. Not only will the diff not actually match the commit
message, but it will usually be _huge_, and all of it will be totally
uninteresting to us, since we were only interested in a particular set of
files.
It also doesn't match what we do when we write the patch to a file.
So this makes gitk just show the diff of _that_ commit.
We might even want to have some way to limit the diff to only the filenames
we're interested in, but it's often nice to see what else changed at the same
time, so that's secondary.
The merge diff handling is left alone, although I think that should also be
changed to only look at what that _particular_ merge did, not what it did when
compared to the faked-out parents.
Paul Mackerras, the gitk maintainer, accepted the patch and pushed out an
updated release, which Junio C. Hamano accepted into the official git
repository. Paul also remarked, "I'm hoping to get back to gitk hacking RSN -
I've been going flat out on the ppc32/ppc64 merge. Thanks for doing the --dense
thing; I was thinking about doing something like that inside gitk but doing it
in git-rev-list is better. It does mean that I now want to be able to get gitk
to contract the view to just a given set of files or directories and then
expand back to the whole tree view, which means running git-rev-list multiple
times, which gitk can't do at the moment..." Linus replied, "Yes. And please
also give the option to contract the diffs to a set of files (I think that
should be independently controlled, although perhaps with some way to set them
both at the same time)."
12. Swap-Based Page Migration
25 Oct - 26 Oct (10 posts) Archive Link: "[PATCH 0/5] Swap Migration V4:
Overview"
Topics: Hot-Plugging
People: Christoph Lameter
Christoph Lameter said, "This is a patchset intended to introduce page
migration into the kernel through a simple implementation of swap based page
migration. The aim is to be minimally intrusive in order to have some hopes for
inclusion into 2.6.15. A separate direct page migration patch is being
developed that applies on top of this patch. The direct migration patch is
being discussed on <[email protected]>. Much of the code is
based on code that the memory hotplug project and Ray Bryant have been working
on for a long time. See http://sourceforge.net/projects/lhms/" He posted his
patches, but there was no real discussion.
13. Linux 2.6.14 Released
27 Oct - 3 Nov (16 posts) Archive Link: "Linux 2.6.14"
Topics: Kernel Release Announcement, PCI, POSIX
People: Linus Torvalds, Oleg Nesterov, Roland McGrath
Linus Torvalds announced Linux version 2.6.14, saying:
Ok, it's finally there.
2.6.14 was delayed twice due to some last-minute bug-reports, some of which
ended up being false alarms (hey, I should be happy, but it was a bit
frustrating)
But hey, the delays - even when perhaps unnecessary - got us to look at the
code and fix some other bugs instead. So it's all good.
So special thanks go to Oleg Nesterov and Roland McGrath for doing some code
inspection and fixing and just making the otherwise frustrating wait for bug
resolution more productive ;^p.
Let's try the 2-week merge window thing again, I think it worked pretty well
despite the delays, and hopefully it will work even better this time around.
The actual changes from 2.6.14-rc5 are a number of mostly one-liners, with the
ShortLog appended (full log from 2.6.13 on the normal sites together with the
release itself). The only slightly bigger ones (ie more than a handful of
lines) is a kernel parameter doc update, and the PIIX4 PCI quirk printouts, and
the cleanups/fixes for the posix cpu timers.
(In fact, according to diffstat, about half the diff is that one documentation
update, and most of that is whitespace cleanups)
14. Status Of Native POSIX Thread Library Support In 2.4 And 2.6
28 Oct (3 posts) Archive Link: "NPTL support for 2.4.31?"
Topics: POSIX
People: Harald Dunkel, Bert Hubert
Harald Dunkel asked about the status of Native POSIX Thread Library (http://
en.wikipedia.org/wiki/NPTL) (NPTL) support in the 2.4 tree, adding, "I know
that there is a backport in RH's 2.4.21, but obviously it didn't make it into
the native 2.4 kernel." Bert Hubert replied, "I doubt anybody else would do the
work, you'll find that any NPTL patch is bound to be huge and intrusive. Try
running 2.6 if possible. A 2.4 kernel with NPTL patched in is not going to
confer any stability benefits over 2.6."
15. Some Discussion Of 2.6 Maintenance Patterns
29 Oct - 31 Oct (32 posts) Archive Link: "[git patches] 2.6.x libata updates"
Topics: Version Control
People: Linus Torvalds, Jeff Garzik
In the course of discussion, Linus Torvalds remarked:
one of the downsides of the new "merge lots of stuff early in the development
series" approach is that the first few daily snapshots end up being _huge_.
So the -git1 and -git2 patches are/will be very big indeed.
For example, patch-2.6.14-git1 literally ended up being a megabyte compressed.
Right now my diff to 2.6.14 (after just two days) is 1.6MB compressed.
Admittedly, some of it is due to things like the MIPS merge, but the point I'm
trying to make is that it makes the daily snapshot diffs a lot less useful to
people who try to figure out where something broke.
Now, I've gotten several positive comments on how easy "git bisect" is to use,
and I've used it myself, but this is the first time that patch users _really_
become very much second-class citizens, and you can't necessarily always do
useful things with just the tar-trees and patches. That's sad, and possibly a
really big downside.
Don't get me wrong - I personally think that the new merge policy is a clear
improvement, but it does have this downside.
Jeff Garzik replied:
Back when I did the BK snapshots, I would occasionally do a middle-of-the-day
snapshot if there were a ton of incoming merges in a 24-hour span.
If this "huge -git1" becomes a real problem, we could always
* give you a manual "do snapshot" button
* ask the maintainers to spread out their submits across multiple days, as I
am doing now
* sell you on capping the daily push-to-kernel.org limit. merge stuff into
"day1", "day2", etc. branches when the main branch "fills up" for the day.
None of these are terribly painful, but none are terribly appealing either.
16. Splitting The swsusp Code Into Two Subsystems
29 Oct - 30 Oct (17 posts) Archive Link: "[RFC][PATCH 0/6] swsusp: rework
swap handling"
Topics: Software Suspend
People: Rafael J. Wysocki, Pavel Machek
Rafael J. Wysocki said:
The following series of patches divides swsusp into two functionally
independent subsystems:
* the snapshot-handling part responsible for creating and populating the
snapshot-related data structure which is the list of page backup entries
aka pagedir,
* the swap-handling part responsible for writing the snapshot data to and
reading it from swap.
On suspend the snapshot-handling part creates the system snapshot and makes the
data stored in the snapshot available to the swap-handling part via an
interface function allowing it to transfer the data as a series of consecutive
data pages, in a specific order. The swap-handling part writes the data pages
to a swap partition is such a way that they can be read in exactly the same
order in which they have been saved.
On resume the snapshot-handling part is invoked by the swap-handling part to
create the pagedir. Then, the swap-handling part is allowed to send it, with
the help of an interface function, data pages that are used to populate the
snapshot data structure. It is assumed that the data pages will be sent in the
same order in which they have been received by the swap-handling part on
suspend. Finally, the system state (from before suspend) is restored by the
snaphot-handling part from the data structure handled by it.
>From the point of view of the swap-handling part, the contents of the data
pages provided by the snapshot-handling do not matter at all. It handles each
data page in the same way without analyzing its contents and the
snapshot-handling part is responsible for recognizing the metadata and using
them as appropriate. Consequently, in principle the swap-handling part can be
replaced with a user-space process and the interface functions used in
transferring data between the two parts of swsusp can be replaced with a
relatively simple kernel-user interface in the future.
The approach used in this series of patches has some additional benefits:
1. the size of the pagedir is reduced by 1/4 which causes some more memory to
be available on resume,
2. the amount of metadata written to swap is reduced by 3/4,
3. the artificial limitation on the pagedir size, imposed by the size of the
swsusp_info structure, is lifted,
4. the size of swsusp_info structure is reduced so it can be merged with the
swsusp_header structure in the future,
5. the swap-handling part does not use any global variables related to the
snapshot data structure,
6. the __nosavedata variables are almost eliminated (on x86-64 the last of
them is the in_suspend variable).
I have divided the changes into some more or less logical steps for clarity.
Although the code has been designed as proof-of-concept, it is functional and
has been tested on x86-64, except for the cryptographic functionality and error
paths.
For your convenience the patches are available from: http://www.sisk.pl/kernel/
patches/2.6.14-rc5-mm1/
He posted each patch, and Pavel Machek went over them all, and was generally
very pleased. He had a few minor objections, to which Rafael was very
responsive, and the thread ended.
17. git 0.99.9 Released; Documenting More Of git's Power
29 Oct - 2 Nov (28 posts) Archive Link: "GIT 0.99.9"
People: Junio C. Hamano, Linus Torvalds
On the git mailing list, Junio C. Hamano announced git 0.99.9, saying:
As I said in the 0.99.8 announcement, git already does everything I want it to
do, and from here on I'd like to see us concentrate on fixes (both correctness
and performance) until we hit 1.0 which should happen shortly.
Many thanks to everybody who contributed the comments, extra set of eyeballs,
and code.
Linus Torvalds replied, "Congrats. I personally think this is very much worthy
of a 1.0 after just giving it some time to shake out any possible last-minute
bugs." In a later post, he added:
one thing I'd like to see (maybe it already exists and I just have overlooked
it) is some kind of simple readme or something about the different ways to
limit the output of the various git commands.
I've several times been surprised to see people not realize that
"git-whatchanged" takes a file list to limit the files it is interested in. I
also suspect people don't realize that you can limit it by time and version and
file list, all at the same time.
IOW,
git-whatchanged -p --pretty=short --since="2 weeks ago" v0.99.8..v0.99.9
Makefile
is a valid query: it basically asks for any change to the Makefile in between
versions v0.99.8..v0.99.9, _and_ within the last two weeks, and asks to show it
as a patch, with the shortened commit message.
Is it useful? The above exact line almost certainly isn't, but variations on
the above definitely are. And I suspect a lot of people never even realized you
could do something like that.
(The danger with date-based things is that something may be 4 months old, but
it only got _merged_ yesterday, so it may be new to _you_. And the --since="2
weeks ago" will not show it, which can be surprising to people who expect
things that are new to _them_ to be shown).
The above limiters now work with "git log" and "gitk" too (they've worked for a
long time with "git-whatchanged", but only with the new git-rev-list
functionality does the name-limiting work for the other commands).
It would be good to make this more well-known, because a lot of people probably
end up using git not as developers, but just to follow what is going on. And
then the different limiters are some of the most important parts (the date-one
is likely the least important one, but limiting by version and name is _very_
important).
Junio replied:
I've somewhat updated git-rev-list documentation and tried to categorize the
options into commit selectors and presentation modifiers. The documentation for
commands you mentioned in your message all talk about them describing only
frequently used options, and refer the user to rev-list documentation. I am not
sure this would be enough.
One good thing to have would be to add a section to Tutorial. Currently we
cover building a small project from scratch and have the readers graduate when
they learn basic commit swapping, but we do not talk much about archaeology
tools.
Linus said:
I don't think people really follow the links or think very abstractly at all in
the first place.
So I was thinking more of some explicit examples. I actually think every
command should have an example in the man-page, and hey, here's a patch to
start things off.
Of course, I'm not exactly "Mr Documentation", and I don't know that this is
the prettiest way to do this, but I checked that the resulting html and
man-page seems at least reasonable.
And hey, if the examples look like each other, that's just because I'm also not
"Mr Imagination".
18. Removing Obsolete OSS Sound Drivers
30 Oct - 1 Nov (19 posts) Archive Link: "[2.6 patch] schedule obsolete OSS
drivers for removal"
Topics: PCI, Sound: ALSA, Sound: OSS
People: Adrian Bunk, Alistair John Strachan, Kyle McMartin, Lee Revell, Andi
Kleen, Jeff Garzik, Andrew Morton
Adrian Bunk said, "This patch schedules obsolete OSS drivers (with ALSA drivers
that support the same hardware) for removal." He added, "Scheduling the
via82cxxx driver for removal was ACK'ed by Jeff Garzik." Andrew Morton also
signed off on the patch. And as Alistair John Strachan added a couple of posts
later, "Adrian plans simply to remove drivers which have solid, known working
replacements for all PCI ids in an equivalent ALSA driver."
Elsewhere, Kyle McMartin remarked, "I didn't see it here, but SOUND_AD1889 can
definitely be removed as well. The driver never worked properly to begin with.
This was ACK'd by the author last time this thread reared it's head." After a
small mixup, Adrian said, "The ad1889 ALSA driver was not present before 2.6.14
and therefore not on my original list. Below is an updated patch that also
schedules SOUND_AD1889 for removal."
The above-mentioned mixup involved Adrian thinking Kyle was talking about the
ad1816 driver, to which his objection was that "ALSA bugs (https://
bugtrack.alsa-project.org/) #1301 and #1302 are still open." As it turned out,
the inadvertant consideration of ad1816 was useful. Lee Revell pointed out,
"these bug reports can be disregarded. The submitter never responded to
requests to retest with the latest ALSA version. #1302 is almost certainly a
bug in kphone anyway." And Adrian said, "If these bugs will be marked as
resolved/closed when I'll send the next batch of OSS driver removals a few
months from now, SOUND_AD1816 will be part of this batch."
Elsewhere, Andi Kleen also replied to Adrian's initial post, requesting that
"the ICH driver be kept. It works just fine on near all my systems and has a
much smaller binary size than the ALSA variant. Moving to ALSA would bloat the
kernels considerably." Lee pointed out, "The emu10k1 ALSA driver is
considerably smaller than the OSS driver and has more features, like most ALSA
drivers. If the ICH driver is really smaller I suspect it's missing some
functionality." Adrian also said that Andi should submit a proper bug and
provide the bug number, if he wanted the issue to be considered. He added, "If
you consider ALSA too bloated you should help on solving this issue instead of
insisting on keeping OSS." At this point several other folks did indeed begin a
technical consideration of ways to reduce ALSA bloat.
19. Emails Delayed From Reaching Kernel Maintainers
30 Oct (4 posts) Archive Link: "[git patches] 2.6.x libata update"
Topics: Bug Tracking
People: Jeff Garzik, Linus Torvalds, Andrew Morton
Jeff Garzik posted a patch, and Andrew Morton said, "Linus may not receive
this. For me at least, large amounts of incoming and outgoing OSDL email have
been disappearing into the ether for the past 12 hours or so." And Linus
Torvalds added:
Apparently the osdl mail server (and bugzilla etc) had a disk failure
overnight.
My (and yours, Andrew) mail should be starting to trickle in now. Just a little
bit delayed ;)
20. NTFS Updates; Instructions On Testing
31 Oct - 1 Nov (28 posts) Archive Link: "[2.6-GIT] NTFS: Release 2.1.25."
Topics: FS: NTFS
People: Anton Altaparmakov
Anton Altaparmakov posted a bunch of NTFS patches, saying, "This is the next
NTFS update containing more extended write support (and in fact pretty much
completely rewritten file write support)! This has been in -mm for a while and
at least one person (other than me that is) tested it, found a bug which I
fixed, and since then noone has reported any bugs with the code. So I think it
is definitely ready for a larger audience, i.e. the mainline kernel." Yura
Pakhuchiy reported a bug, and it turned out he hadn't known where to get
additional patches needed to test NTFS. In a subsequent release, Anton said:
If you go to a kernel.org mirror and look at:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/
And then at the kernel you are interested in, e.g. lets take the latest -mm,
then you will find the full -mm patch and the broken out bits in the following
URLs respectively:
full mm:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.14-rc5/
2.6.14-rc5-mm1/
broken out:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.14-rc5/
2.6.14-rc5-mm1/broken-out/
And thusly, the ntfs patch from the developmental ntfs git repository would be:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.14-rc5/
2.6.14-rc5-mm1/broken-out/git-ntfs.patch
It is also worth looking in the broken out directory for other patches with
ntfs in the name, as Andrew may have other ntfs patches. In the above -mm,
there is for example:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.14-rc5/
2.6.14-rc5-mm1/broken-out/ntfs-printk-warning-fixes.patch (http://
www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.14-rc5/
2.6.14-rc5-mm1/broken-out/ntfs-printk-warning-fixes.patch)
21. Fresh Attempt To Remove DevFS
1 Nov (1 post) Archive Link: "[GIT PATCH] Remove devfs from 2.6.14"
Topics: FS: devfs
People: Greg KH
Greg KH said:
Here are the same "delete devfs" patches that I submitted for 2.6.12 and
2.6.13. It rips out all of devfs from the kernel and ends up saving a lot of
space. Since 2.6.13 came out, I have seen no complaints about the fact that
devfs was not able to be enabled anymore, and in fact, a lot of different
subsystems have already been deleting devfs support for a while now, with
apparently no complaints (due to the lack of users.)
Please pull from:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/devfs-2.6.git/
or if master.kernel.org hasn't synced up yet:
master.kernel.org:/pub/scm/linux/kernel/git/gregkh/devfs-2.6.git/ (http://
www.master.kernel.org:/pub/scm/linux/kernel/git/gregkh/devfs-2.6.git/)
I've posted all of these patches before, but if people really want to look at
them, they can be found at:
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-05-devfs
/
Also, if people _really_ are in love with the idea of an in-kernel devfs, I
have posted a patch that does this in about 300 lines of code, called ndevfs.
It is available in the archives if anyone wants to use that instead (it is
quite easy to maintain that patch outside of the kernel tree, due to it only
needing 3 hooks into the main kernel tree.)
There was no reply.
22. '(H)gct' git And Mercurial GUI-Enabled Commit Tool Update
1 Nov (1 post) Archive Link: "[ANNOUNCE] (H)gct 0.3"
People: Fredrik Kuivinen
On the git mailing list, Fredrik Kuivinen said:
Version 0.3 of (H)gct, a GUI enabled commit tool for Git and Mercurial, has
been released and can be downloaded from http://www.cyd.liu.se/~freku045/gct/
ct-0.3.tar.gz
Thanks to Vincent Danjean there are Debian packages available at http://
dept-info.labri.fr/~danjean/deb.html#commit-tool
Screen shots and a Git repository with a gitweb interface are available at the
project homepage, http://www.cyd.liu.se/~freku045/gct
The major changes compared to v0.2 are:
* File filter, show only file names which contain a specified string.
* Make ignoring files actually work.
* A new option, --one-shot, which makes (h)gct exit after the first commit.
* Support for new versions of git.
* An Hg extension which makes hgct better integrated with Hg. See README.HG
for details.
23. git 0.99.9b In Use On kernel.org Machines
2 Nov (1 post) Archive Link: "git 0.99.9b installed on kernel.org"
People: H. Peter Anvin
On the git mailing list, H. Peter Anvin said, "git 0.99.9b is now installed on
all kernel.org machines."
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
kernel.org. All pages on this site are copyright their original authors, and
distributed under the terms of the GNU General Public License version 2.0.