2.6.19 -mm merge plans

Gene Heskett · External Since: May 10, 2005 Posts: 109

On Thursday 21 September 2006 20:32, Fengguang Wu wrote:
>On Thu, Sep 21, 2006 at 04:59:18PM -0700, Andrew Morton wrote:
>> > On Wed, Sep 20, 2006 at 01:54:38PM -0700, Andrew Morton wrote:
>> > > The readahead code is complex, I'm unconvinced that it has a lot
>> > > of benefit and Wu has gone quiet. Will drop.
>> >
>> > Sorry, I've been putting efforts to meet the deadline of the google
>> > SoC project "Rapid linux desktop startup through pre-caching", which
>> > still can not be called success for now. And there's my pending paper
>> > work...
>>
>> Oh, OK.
>>
>> That's a neat thing to be working on.
>
>Thank you.
>
>FYI: I attached a little presentation work, one for the boot time
>stuff, another for the readahead patch.
>
>> > I should be able to come back and concentrate on the readahead patch
>> > after one month, whether it be dropped for now. I guess it can be
>> > further improved in complexity and performance. It also needs a good
>> > document for the overall design and benefits. And sure the
>> > performance numbers Smile

>>
>> I'll hang onto the patches then - they're causing little maintenance
>> trouble for me.
>
>Sorry, I can imagine it, which upsets me.
>I'll try to settle it in the next 3-month cycle.
>
>Thanks,
>Fengguang Wu

Both of your attached pdf's were missing the required fonts to display the
content on this locale=en machine, as the latest acroread for linux (7.05)
advised me about both, and the second one, while it did display the cover
page in english at a scale far larger than my 1600x1200 screen, it
actually locked up X and I had to reboot. I thought I had enough fonts
here to cover everything too. Sad

--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo RemoveThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Fengguang Wu · External Since: Jun 05, 2006 Posts: 48

On Sat, Sep 23, 2006 at 10:48:13AM -0400, Gene Heskett wrote:
> Both of your attached pdf's were missing the required fonts to display the
> content on this locale=en machine, as the latest acroread for linux (7.05)
> advised me about both, and the second one, while it did display the cover

Thanks for the feedback. I guess the main cause can be from a default
Chinese font, which is actually not used for the visible characters.
It should not cause serious readability issues.

> page in english at a scale far larger than my 1600x1200 screen, it
> actually locked up X and I had to reboot. I thought I had enough fonts
> here to cover everything too. Sad

Sorry for that. I'll send a copy of .odp for you.

Regards,
Wu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Lennert Buytenhek · External Since: Oct 21, 2005 Posts: 92

On Fri, Sep 22, 2006 at 11:26:49AM -0700, Andrew Morton wrote:

> <I maintain that it is in the interests of obscure-arch maintainers
> to help others build cross-compilers for their arch..>

As I regularly test with different gcc versions and encourage others
to do the same, I've had a set available for a while at:

http://www.wantstofly.org/~buytenh/kernel/arm-cross/

(Generated with crosstool 0.42, see http://kegel.com/crosstool) Any
suggestions for making them easier to find for folks?

cheers,
Lennert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Lennert Buytenhek · External Since: Oct 21, 2005 Posts: 92

On Fri, Sep 22, 2006 at 09:21:32AM -0700, Linus Torvalds wrote:

> > Hmm. Some trees do seem to get pulled more often than others.
> > Linus, is there a upper limit on the number of times you want
> > to see pull requests? It strikes me as odd, so I'm wondering
> > if there are some crossed wires here.
>
> I personally prefer to not see _too_ many pull requests, since that
> to me indicates that people don't take advantage of the distributed
> nature of git, and don't let things "simmer" in their own tree for
> a while.

ARM has many sub-architectures, and patches for each of the sub-archs
typically (not always) come from the same person in ARM land, which
typically means that the total set of ARM changes doesn't really need
much integration testing as a whole.

Changes that span sub-architectures (such as genirq) are usually
discussed on the mailing list first, and tested before they get
committed to any tree. I.e. on the few occasions that we do need
to test ARM-wide changes, we just email patches around rather than
asking folks "whether 2.6.30-rmk42 works."

Due to this, by the time a patch gets sent to rmk it's Obviously
Perfect, and the remaining testing work is 99% integration testing
with concurrent changes to other subsystems -- mtd, netdev, usb, etc.

In fact, I'd argue that there are more patches that span arch/arm plus
some other part of the tree (inter-related mtd bits, netdev bits, usb
bits, framebuffer bits), than there are patches that span different ARM
sub-architectures.

For example, a driver for the ethernet MAC in the ARM cpu that I have
here was recently applied by jgarzik, but I cannot submit the arch/arm
hooks to make use of this driver until jgarzik's tree is merged upstream
_and_ rmk rebases the half a megabyte of pending ARM changes on this
tree. If I submit the hooks to rmk when the driver goes upstream, rmk's
private tree (probably still based on 2.6.18 when that happens, so won't
have the relevant netdev changes) will break.

To make making these kinds of changes easier without sending stuff
upstream so regularly, rmk would have to either pull from upstream
regularly or rebase his tree on upstream regularly, both of which
don't seem like desirable options.

Also, I do want to track upstream git, as every now and then changes
are made upstream that break ARM, and we want to be able to detect that
quickly.

Due to the nature of ARM work, rmk maintaining a long-lived tree for
stuff to 'simmer in' would probably reduce the burden on Linus but
would not have much of an advantage otherwise, IMHO.

cheers,
Lennert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo RemoveThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Russell King · External Since: May 18, 2006 Posts: 479

On Sun, Sep 24, 2006 at 09:48:37AM +0200, Lennert Buytenhek wrote:
> On Fri, Sep 22, 2006 at 09:21:32AM -0700, Linus Torvalds wrote:
> > I personally prefer to not see _too_ many pull requests, since that
> > to me indicates that people don't take advantage of the distributed
> > nature of git, and don't let things "simmer" in their own tree for
> > a while.
>
> Changes that span sub-architectures (such as genirq) are usually
> discussed on the mailing list first, and tested before they get
> committed to any tree. I.e. on the few occasions that we do need
> to test ARM-wide changes, we just email patches around rather than
> asking folks "whether 2.6.30-rmk42 works."

Let's look at how two scenarios work for the case of the genirq patches.

1. genirq remains as patches until it's ready (iow, what actually happened)
- patches as a series were posted to the mailing list with a request
to test.
- feedback came, the patches were improved, and this repeated several
times
- eventually, people are happy
- in parallel, because these patches affect other architectures, they
were also submitted to -mm.
- the generic parts of genirq were submitted to Linus.
- once the generic parts of genirq are in mainline, the ARM specific
parts can then be applied to my git tree, and be sent to Linus.

2. genirq patches in ARM git tree.
- the initial entire patches get applied to the ARM tree on a
separate branch.
- the patches get mailed to the ARM mailing list as one large patch.
- feedback comes to me/mailing list rather than CC:'d to the genirq
people.
- maybe the genirq people send updates to me, which then need to be
applied to the ARM tree, and the result needs to be re-published.
- we go around the loop several times, maybe merging in later mainline
versions.
- in parallel with this, the non-ARM parts of genirq are submitted to
-mm.
- when the patches are ready, the generic parts are submitted to
Linus.
- rmk then faces a _big_ problem in resolving lots of conflicts in
his tree, because the generic parts submitted to Linus are different
from the initial generic parts committed to the ARM git tree.
- the ARM git tree for genirq probably has to be rebuilt from scratch.

Sure, someone else _could_ maintain genirq in their own git tree, so
replace "rmk" above with "tglx". The overall problem remains though -
at the end of it you can't push that git tree with all that history,
and the whole thing can't go via just one person. This in turn means
that there's a chunk of additional work to rework the changes (which
may introduce bugs) and then an additional round of re-testing to make
sure nothing broke.

The point I'm making is that for some things, keeping the changes as
patches until they're ready is far easier, more worthwhile and flexible
than having them simmering in some git tree somewhere.

> For example, a driver for the ethernet MAC in the ARM cpu that I have
> here was recently applied by jgarzik, but I cannot submit the arch/arm
> hooks to make use of this driver until jgarzik's tree is merged upstream
> _and_ rmk rebases the half a megabyte of pending ARM changes on this
> tree. If I submit the hooks to rmk when the driver goes upstream, rmk's
> private tree (probably still based on 2.6.18 when that happens, so won't
> have the relevant netdev changes) will break.
>
> To make making these kinds of changes easier without sending stuff
> upstream so regularly, rmk would have to either pull from upstream
> regularly or rebase his tree on upstream regularly, both of which
> don't seem like desirable options.

I believe that Linus has complained to tree maintainers when they've
done this because it complicates the history far too much.

Consider the effect on the history if I were to pull Linus' tree daily
into my trees, and I was committing about one change per day. You'd
have:

linus---othercommits--------othercommits---------othercommits-------merge
\ \ \ \ /
commit --- merge --- commit --- merge --- commit --- merge --- commit

The other solution is that I somehow start reviewing drivers for any
part of the kernel and accepting them. However, as we've seen already
on lkml, if anyone who isn't jgarzik accepts a change to a network
device driver and passes it to Linus, they get a roasting from Jeff
(see Dominic's incident when adding some additional PCMCIA IDs to PCMCIA
network device drivers.)

From the point of view of keeping an ARM tree, I've been in that situation
before - from the beginnings of ARM support on Linux until the advent of
bitkeeper. This was when I had my own tree which was published regularly.
The problem that posed is that the tree was seen as "the ARM tree" where
_everything_ to do with ARM (be it device drivers) was _dumped_. Once it
was in there, the original authors decided that their job was done and
walked away.

The result was that I accumulated almost 1MB of compressed patch, and
we _never_ got to the situation where the merged ARM mainline was in
a buildable state despite _years_ of work to try to get it there. The
closest we got was one of the 2.4-ac trees, just before Alan quit doing
them (which might have been a contributary reason.)

To date, none of the 2.4 trees is buildable for ARM.

The biggest problem with it is synchronising changes with other trees,
and persuading other people to submit things to the relevant people.
Either such a tree accepts the ARM specific bits along side the device
drivers (and then ends up with a review and bypassing other maintainers
problem, resulting in the tree owner getting regularly roasted) or
they get moaned at for not accepting device driver patches which are
dependent on other changes in that tree.

Since then, I've vowed to _never_ maintain such a "community" tree ever
again. I credit 2.6 being buildable for ARM entirely on the choice to
get rid of this tree.

--
Russell King
2.6 ARM Linux - http://www.arm.linux.org.uk/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.DeleteThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Diego Calleja · External Since: May 22, 2006 Posts: 49

El Fri, 22 Sep 2006 08:32:23 +0800,
Fengguang Wu <fengguang.wu.RemoveThis@gmail.com> escribió:

> FYI: I attached a little presentation work, one for the boot time
> stuff, another for the readahead patch.

A nice and clean way to collect I/O traces that it's not mentioned in
the boot_linux_faster.pdf paper would be to use kprobes + systemtap.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Mike Galbraith · External Since: May 26, 2006 Posts: 368

On Sun, 2006-09-24 at 10:20 +0100, Russell King wrote:

> The point I'm making is that for some things, keeping the changes as
> patches until they're ready is far easier, more worthwhile and flexible
> than having them simmering in some git tree somewhere.

I <heart> patch and </heart> scm (works for me:), but in theory, isn't
that the same?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.TakeThisOut@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Sean · External Since: Aug 18, 2006 Posts: 35

On Sun, 24 Sep 2006 10:20:10 +0100
Russell King <rmk+lkml@arm.linux.org.uk> wrote:

> The point I'm making is that for some things, keeping the changes as
> patches until they're ready is far easier, more worthwhile and flexible
> than having them simmering in some git tree somewhere.

It's not really easier, just different. Git allows you to make a
"topic branch" to keep separate items that need to bake before going
upstream without being mixed in with all your other worked. This
allows you to continue to pull in upstream changes to make sure that
the patch series still applies cleanly and doesn't need updates etc.

Of course you may be more comfortable with other tools, but Git _does_
make it easy and practical to do the same thing.

Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.DeleteThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Ingo Molnar · External Since: May 15, 2006 Posts: 3112

* Linus Torvalds <torvalds.RemoveThis@osdl.org> wrote:

> I think the "big merges in the first two weeks, and a -rc1 after, and
> no new code after that" rule has been working because it brought
> everybody in on the same page.

yeah. I dont really support the even/odd release thing because even the
old 1.2/1.3/2.0/2.1/2.2/2.3/2.4 scheme _always_ confused non-insiders.
Sometimes i saw it confuse people who already understood the GPL Wink

Furthermore it would just dillute our version numbers to encode some
information that "-rc1" indicates just as well. Insiders know perfectly
well that when -rc1 is released the merge window is closed. And what
causes -rc elongation is usually not the lack of communication towards
users or lack of testing but the lack of fixing power ...

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Stefan Richter · External Since: May 15, 2006 Posts: 681

Sean wrote:
> On Sun, 24 Sep 2006 10:20:10 +0100
> Russell King <rmk+lkml@arm.linux.org.uk> wrote:
>
>> The point I'm making is that for some things, keeping the changes as
>> patches until they're ready is far easier, more worthwhile and flexible
>> than having them simmering in some git tree somewhere.
>
> It's not really easier, just different. Git allows you to make a
> "topic branch" to keep separate items that need to bake before going
> upstream without being mixed in with all your other worked.
....
> Git _does_ make it easy and practical to do the same thing.

I'm not convinced. Certain workflows are more focused on how changes
change (sic) rather than on how the end product i.e. the sources change.
I am referring to reworking of patches during tests and reviews as well
as rewriting descriptions, collecting Acks and Sign-offs etc. while
maintaining a certain identity of the patch or series of patches.

But maybe I'm just not aware of how git may support this effectively.
Perhaps thusly: Let the young and wild times of life of a patch actually
result into many commits to a topic branch; collapse a lot of these
commits into one or few diffs for each review round; move to a new topic
branch for bigger reworks of the changeset; and finally collapse it into
one or few commits to a staging branch for submission? Sounds still more
like a job for patch-centered tools like quilt.
--
Stefan Richter
-=====-=-==- =--= ==---
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo RemoveThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Sean · External Since: Aug 18, 2006 Posts: 35

On Mon, 25 Sep 2006 00:34:45 +0200
Stefan Richter <stefanr DeleteThis @s5r6.in-berlin.de> wrote:

> I'm not convinced. Certain workflows are more focused on how changes
> change (sic) rather than on how the end product i.e. the sources change.
> I am referring to reworking of patches during tests and reviews as well
> as rewriting descriptions, collecting Acks and Sign-offs etc. while
> maintaining a certain identity of the patch or series of patches.
>
> But maybe I'm just not aware of how git may support this effectively.
> Perhaps thusly: Let the young and wild times of life of a patch actually
> result into many commits to a topic branch; collapse a lot of these
> commits into one or few diffs for each review round; move to a new topic
> branch for bigger reworks of the changeset; and finally collapse it into
> one or few commits to a staging branch for submission? Sounds still more
> like a job for patch-centered tools like quilt.

Well, you're absolutely right about native Git being more focused on
tracking the final product. However, there are tools growing up around
Git that attempt to give similar (although completely integrated with
Git) functionality of Quilt. One such tool is Stacked Git (StGit)
http://www.procode.org/stgit/. Since i'm not actually a user myself,
I can't vouch for it, but it does have a responsive community around it
and seems to be providing what it set out to accomplish.

Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo DeleteThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Russell King · External Since: May 18, 2006 Posts: 479

On Sun, Sep 24, 2006 at 02:23:53PM -0400, Sean wrote:
> On Sun, 24 Sep 2006 10:20:10 +0100
> Russell King <rmk+lkml@arm.linux.org.uk> wrote:
>
> > The point I'm making is that for some things, keeping the changes as
> > patches until they're ready is far easier, more worthwhile and flexible
> > than having them simmering in some git tree somewhere.
>
> It's not really easier, just different. Git allows you to make a
> "topic branch" to keep separate items that need to bake before going
> upstream without being mixed in with all your other worked. This
> allows you to continue to pull in upstream changes to make sure that
> the patch series still applies cleanly and doesn't need updates etc.
>
> Of course you may be more comfortable with other tools, but Git _does_
> make it easy and practical to do the same thing.

Before people disagree with my statement (and I'm referring to all the
replies so far), maybe they should talk to Thomas who pioneered the
genirq changes to find out why he decided to work with patches rather
than a git repository?

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.TakeThisOut@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Sean · External Since: Aug 18, 2006 Posts: 35

On Mon, 25 Sep 2006 00:09:48 +0100
Russell King <rmk+lkml@arm.linux.org.uk> wrote:

> Before people disagree with my statement (and I'm referring to all the
> replies so far), maybe they should talk to Thomas who pioneered the
> genirq changes to find out why he decided to work with patches rather
> than a git repository?

When Thomas makes a sweeping statement about the applicability of one
tool over another people will respond to him. But if _you_ make such
a statement yourself (even if it's based on his conclusions) then
you better accept that people who disagree will respond to your statement.

Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo DeleteThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Linus Torvalds · External Since: Jan 12, 2005 Posts: 517

On Sun, 24 Sep 2006, Sean wrote:
>
> When Thomas makes a sweeping statement about the applicability of one
> tool over another people will respond to him. But if _you_ make such
> a statement yourself (even if it's based on his conclusions) then
> you better accept that people who disagree will respond to your statement.

I think it's unquestionable that sometimes it's better to work with
patches. The thing is, git by its very design is about tracking things
where history is firmly "set in stone", and that's not always what you
want.

We've done a number of things to help people relax that a bit (notably
"git rebase" and "git cherry-pick"), and there are projects like stgit
that are more of a patch-management system on top of git, but even during
the early design phases I said that it's likely that git will be used in
_conjunction_ with tools like quilt etc, that are less strict than git is.

So I don't think we need to attack the notion of using non-git tools at
all. Especially if you don't know where you're going, git's very strict
immobile history can be a bit daunting.

(Of course, once you get really used to git, you use git _anyway_, and
then you use cherry-pick and other tools to re-write a cleaned-up version
of the thing that you originally screwed up because you didn't know what
you were doing. So you _can_ do this too with git, but that doesn't mean
that git would necessarily be the best way to do it).

That said, maybe we could help the "fixup" phases evenmore using git. For
example, right now you can do "git cherry-pick" to transfer individual
patches, but if you want to combine two commits while cherry-picking, it
immediately gets more involved (still quite doable: use cherry-pick
multiple times with the "-n" flag, but it's not as obvious any more).

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.DeleteThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Nick Piggin · External Since: May 15, 2006 Posts: 532

Ingo Molnar wrote:

>* Linus Torvalds <torvalds DeleteThis @osdl.org> wrote:
>
>
>>I think the "big merges in the first two weeks, and a -rc1 after, and
>>no new code after that" rule has been working because it brought
>>everybody in on the same page.
>>
>
>yeah. I dont really support the even/odd release thing because even the
>old 1.2/1.3/2.0/2.1/2.2/2.3/2.4 scheme _always_ confused non-insiders.
>Sometimes i saw it confuse people who already understood the GPL Wink

>Furthermore it would just dillute our version numbers to encode some
>information that "-rc1" indicates just as well. Insiders know perfectly
>well that when -rc1 is released the merge window is closed. And what
>causes -rc elongation is usually not the lack of communication towards
>users or lack of testing but the lack of fixing power ...
>

OTOH, if we were worried about confusing people, we wouldn't be
using the acronym 'rc' for our 'Ridiculous Count', and have our rc1
denote the result of 2 weeks of stuffing the tree with new features
and intrusive changes, where people might mistake that for the much
more common RC-as-in-'Release Candidate'. Smile

Our -rc is what everyone else knows as -pre, and our dot zeros
basically correspond to what people think of as a release candidate.
As a developer it doesn't hurt me and I do like the current system,
but in principle I just dislike things that are more confusing than
they could be.

--

Send instant messages to your online friends http://au.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo DeleteThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Ingo Molnar · External Since: May 15, 2006 Posts: 3112

* Nick Piggin <nickpiggin RemoveThis @yahoo.com.au> wrote:

> OTOH, if we were worried about confusing people, we wouldn't be using
> the acronym 'rc' for our 'Ridiculous Count', and have our rc1 denote
> the result of 2 weeks of stuffing the tree with new features and
> intrusive changes, where people might mistake that for the much more
> common RC-as-in-'Release Candidate'. Smile

oh, we could call the first one -rc0 then Smile

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo RemoveThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Marcin Juszkiewicz · External Since: Dec 05, 2005 Posts: 13

Dnia ¶roda, 20 wrze¶nia 2006 22:54, Andrew Morton napisa³:

> When replying to this email, please rewrite the Subject: to something
> appropriate. Please also attempt to cc the appropriate developer(s).

> pcmcia-add-few-ids-into-ide-cs.patch

I got another submission from user so had to update patch.

From: Marcin Juszkiewicz <openembedded DeleteThis @hrw.one.pl>

Few cards informations submitted by OpenZaurus users.

Seagate 8GB microdrive:
product info: "SEAGATE", "ST1"
manfid 0x0111, 0x0000

One CF card:
product info: "SAMSUNG", "04/05/06", "", ""
manfid : 0x0000, 0x0000

Ridata 8GB Pro 150X Compact Flash Card:
product info: "SMI VENDOR", "SMI PRODUCT", ""
manfid: 0x000a, 0x0000

product info: "M-Systems", "CF500", ""
manfid: 0x000a, 0x0000

product info: "TRANSCEND", "TS4GCF120", ""
manfid: 0x000a, 0x0000

Signed-off-by: Marcin Juszkiewicz <openembedded DeleteThis @hrw.one.pl>

---
Patch follow kernel version 2.6.18

Please Cc: me - I'm not subscribed to linux-pcmcia or linux-kernel

ide-cs.c | 5 +++++
1 file changed, 5 insertions(+)

Index: linux-2.6/drivers/ide/legacy/ide-cs.c
===================================================================
--- linux-2.6.orig/drivers/ide/legacy/ide-cs.c 2006-08-23 11:02:37.958306000 +0200
+++ linux-2.6/drivers/ide/legacy/ide-cs.c 2006-09-25 16:45:35.765780000 +0200
@@ -398,12 +398,17 @@
PCMCIA_DEVICE_PROD_ID12("IO DATA", "PCIDE", 0x547e66dc, 0x5c5ab149),
PCMCIA_DEVICE_PROD_ID12("IO DATA", "PCIDEII", 0x547e66dc, 0xb3662674),
PCMCIA_DEVICE_PROD_ID12("LOOKMEET", "CBIDE2 ", 0xe37be2b5, 0x8671043b),
+ PCMCIA_DEVICE_PROD_ID12("M-Systems", "CF500", 0x7ed2ad87, 0x7a13045c),
PCMCIA_DEVICE_PROD_ID2("NinjaATA-", 0xebe0bd79),
PCMCIA_DEVICE_PROD_ID12("PCMCIA", "CD-ROM", 0x281f1c5d, 0x66536591),
PCMCIA_DEVICE_PROD_ID12("PCMCIA", "PnPIDE", 0x281f1c5d, 0x0c694728),
PCMCIA_DEVICE_PROD_ID12("SHUTTLE TECHNOLOGY LTD.", "PCCARD-IDE/ATAPI Adapter", 0x4a3f0ba0, 0x322560e1),
+ PCMCIA_DEVICE_PROD_ID12("SEAGATE", "ST1", 0x87c1b330, 0xe1f30883),
+ PCMCIA_DEVICE_PROD_ID12("SAMSUNG", "04/05/06", 0x43d74cb4, 0x6a22777d),
+ PCMCIA_DEVICE_PROD_ID12("SMI VENDOR", "SMI PRODUCT", 0x30896c92, 0x703cc5f6),
PCMCIA_DEVICE_PROD_ID12("TOSHIBA", "MK2001MPL", 0xb4585a1a, 0x3489e003),
PCMCIA_DEVICE_PROD_ID1("TRANSCEND 512M ", 0xd0909443),
+ PCMCIA_DEVICE_PROD_ID12("TRANSCEND", "TS4GCF120", 0x709b1bf1, 0xf54a91c8),
PCMCIA_DEVICE_PROD_ID12("WIT", "IDE16", 0x244e5994, 0x3e232852),
PCMCIA_DEVICE_PROD_ID1("STI Flash", 0xe4a13209),
PCMCIA_DEVICE_PROD_ID12("STI", "Flash 5.0", 0xbf2df18d, 0x8cb57a0e),

--
JID: hrw-jabber.org
Sharp Zaurus C-760 (OZ 3.5.x)
OpenEmbedded/OpenZaurus/OPIE developer
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo DeleteThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Alan Cox · External Since: Sep 11, 2004 Posts: 1608

Ar Llu, 2006-09-25 am 16:59 +0200, ysgrifennodd Marcin Juszkiewicz:
> Dnia Å›roda, 20 wrzeÅ›nia 2006 22:54, Andrew Morton napisaÅ‚:
>
> > When replying to this email, please rewrite the Subject: to something
> > appropriate. Please also attempt to cc the appropriate developer(s).
>
> > pcmcia-add-few-ids-into-ide-cs.patch
>
> I got another submission from user so had to update patch.
>
> From: Marcin Juszkiewicz <openembedded RemoveThis @hrw.one.pl>

Acked-by: Alan Cox <alan RemoveThis @redhat.com>

Same update needs to go into drivers/ata/pata_pcmcia

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo RemoveThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

john stultz · External Since: May 16, 2006 Posts: 260

On Thu, 2006-09-21 at 12:24 +0200, Roman Zippel wrote:
> Hi,
>
> On Wed, 20 Sep 2006, john stultz wrote:
>
> > No objections here, but I wanted to put forth some caution as I've seen
> > some odd NTP behavior with the full NTP patchset on my laptop (either it
> > does not converge or it just converges *much* more slowly then without).
> > Unfortunately I've not been able to collect solid enough data to analyze
> > the issue (really, each run should go for atleast a full day and always
> > run on the same network).
>
> grumble...
> As I said before it's expected that the initial covergence is slower and I
> need the data over multiple days to really say something about it.
> There has been really a lot of time for doing this...

Andrew,
With apologies to Roman, I'm withdrawing my hesitation on these patches.
I was able to run tests for two days each w/ and w/o the patch I had
concerns about. And indeed, it seems if the drift file is reset, the
initial convergence is much slower (and this is really what worried me).
However once it converges it seems to keep sync as well as the current
code.

thanks
-john

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo RemoveThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Ray Lee · External Since: Jun 25, 2006 Posts: 23

On 9/25/06, john stultz <johnstul DeleteThis @us.ibm.com> wrote:
> I was able to run tests for two days each w/ and w/o the patch I had
> concerns about. And indeed, it seems if the drift file is reset, the
> initial convergence is much slower (and this is really what worried me).
> However once it converges it seems to keep sync as well as the current
> code.

So slower convergence isn't a regression?

Ray
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo DeleteThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/