Grant Grundler <[EMAIL PROTECTED]>:
> One might consider this a bug that hasn't happened yet - thanks Eric!
Thank you very much for your cooperation. This is the third real problem that
the CONFIG_ namespace audit has turned up, and a good example of the sort of
thing I have been hoping to accom
[EMAIL PROTECTED] said:
> If it can't be mechanically verified that the symbol has a correct
> reference pattern within the tree, then it's broken. That's a
> definition.
Here's an alternative definition:
If the symbol has the letters 'F', 'I', 'S' and 'H' in it, in any order,
then it's bro
Tom Leete writes:
> $ diff -6 ...
> will give 6 lines of context. patch will understand the output without any
> extra help.
Indeed, but I can't do that to a patch that Alan or Linus produces.
--
Russell King ([EMAIL PROTECTED])The developer of ARM Linux
http://www.a
"Eric S. Raymond" wrote:
> Here's what I have for you guys:
...
> CONFIG_DMB_TRAP: arch/parisc/kernel/sba_iommu.c
> CONFIG_FUNC_SIZE: arch/parisc/kernel/sba_iommu.c
>
> Would you please take these out of the CONFIG_ namespace? Changing the
> prefix to CONFIGURE would do nicely.
As willy noted
[Cc: trimmed]
Russell King wrote:
>
[...]
>
> Generally it seems like diff needs to produce one more line of context, and
> most of these problems will go away. Yes, there will still be the odd
> problem, so then it becomes the "how much do you crank the setting" problem.
>
$ diff -6 ...
wil
Alan Cox <[EMAIL PROTECTED]>:
> > Even supposing that's so, a 36% rate of broken symbols is way too high.
> > It argues that we need to do a thorough housecleaning at least once in
> > order to get back to an acceptably low stable rate.
>
> Many of your 'broken' symbols arent. We have no idea wh
David Woodhouse <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] said:
> > Even supposing that's so, a 36% rate of broken symbols is way too
> > high. It argues that we need to do a thorough housecleaning at least
> > once in order to get back to an acceptably low stable rate.
>
> Accepted. Can we let
> Even supposing that's so, a 36% rate of broken symbols is way too high.
> It argues that we need to do a thorough housecleaning at least once in
> order to get back to an acceptably low stable rate.
Many of your 'broken' symbols arent. We have no idea what the real amount is
-
To unsubscribe f
[EMAIL PROTECTED] said:
> Even supposing that's so, a 36% rate of broken symbols is way too
> high. It argues that we need to do a thorough housecleaning at least
> once in order to get back to an acceptably low stable rate.
Accepted. Can we let the 2.4 "angry penguin"-enforced stabilising pe
David Woodhouse <[EMAIL PROTECTED]>:
> I'd be very surprised if the number of false positives isn't fairly stable,
> with new ones being introduced at a similar rate to the rate at which old
> ones finally become correct.
Even supposing that's so, a 36% rate of broken symbols is way too high.
[EMAIL PROTECTED] said:
> Not good enough. In a year, the pile of false positives would get
> high enough to make it too hard to spot real bugs like the Aironet
> mismatch. The whole point of the cleanup is to be able to mechanize
> the consistency checks so they require a minimum of human j
David Woodhouse <[EMAIL PROTECTED]>:
> > Otherwise how can you distinguish between dead wood which must be
> > removed and potentially valid symbols referring to code existing only
> > in a remote tree?
>
> By periodically publishing a list of the potentially-obsolete symbols as ESR
> has done, a
[EMAIL PROTECTED] said:
> Therefore it's the maintainer's job to submit coherent patches and
> accept to see inconsistent CONFIG_* references be removed from the
> official tree until further patch submission is due.
Maybe. But you tend to include the latest MTD code in your tree, for
example,
[EMAIL PROTECTED] said:
> Have you tried mailing [EMAIL PROTECTED] and asking to be added?
Yes.
[EMAIL PROTECTED] said:
> I'd be highly surprised if they said no to adding UML to the list if
> you mailed them a request to update the page.
Well, be surprised then. The reply from hpa was that
On Fri, Apr 20, 2001 at 12:50:05PM -0400, Eric S. Raymond wrote:
> Nicolas Pitre <[EMAIL PROTECTED]>:
> > Why not having everybody's tree consistent with themselves and have whatever
> > CONFIGURE_* symbols and help text be merged along with the very code it
> > refers to? It's worthless to have
On Fri, Apr 20, 2001 at 02:48:18PM -0400, Nicolas Pitre wrote:
>
>
> On Fri, 20 Apr 2001, Tom Rini wrote:
>
> > On Fri, Apr 20, 2001 at 12:35:12PM -0400, Nicolas Pitre wrote:
> >
> > > Why not having everybody's tree consistent with themselves and have whatever
> > > CONFIGURE_* symbols and hel
On Fri, Apr 20, 2001 at 10:59:34AM -0400, Eric S. Raymond wrote:
> All right then. I'm going to send you a bunch of dead-symbol cleanup
> patches. I'll try to stay in the mainline code and out of the port
> trees. Would you please do me the kindness of telling me which ones
> can go in and whic
> "Jeff" == Jeff Dike <[EMAIL PROTECTED]> writes:
Jeff> [EMAIL PROTECTED] said:
>> http://www.kernel.org/ has a list of architecture websites. Also
>> the CREDITS / MAINTAINERS files tend to list the people who are
>> involved.
Jeff> Except it's restricted to processor ports, which would le
On Fri, Apr 20, 2001 at 02:00:00PM -0500, Jeff Dike wrote:
> [EMAIL PROTECTED] said:
> > http://www.kernel.org/ has a list of architecture websites. Also the
> > CREDITS / MAINTAINERS files tend to list the people who are involved.
>
> Except it's restricted to processor ports, which would leav
On Fri, Apr 20, 2001 at 12:35:12PM -0400, Nicolas Pitre wrote:
> There is kind of a ridiculous situation here where people want to withhold
> their own changes in their own trees for all good reasons until it is mature
> and stable enough to be fed upstream in the appropriate way, while insisting
[EMAIL PROTECTED] said:
> http://www.kernel.org/ has a list of architecture websites. Also the
> CREDITS / MAINTAINERS files tend to list the people who are involved.
Except it's restricted to processor ports, which would leave you not knowing
about UML.
Jeff
Nicolas Pitre <[EMAIL PROTECTED]>:
> Why not having everybody's tree consistent with themselves and have whatever
> CONFIGURE_* symbols and help text be merged along with the very code it
> refers to? It's worthless to have config symbols be merged into Linus' or
> Alan's tree if the code isn't t
Bob McElrath wrote:
>
> Jeff Garzik [[EMAIL PROTECTED]] wrote:
> > Tom Rini wrote:
> > > Which does boil down to having to work with trees other than Linus or
> > > Alans. Remember, the official tree is not always the up-to-date tree,
> > > or in the case of other arches, the most relevant tree.
On Fri, Apr 20, 2001 at 11:15:12AM -0500, Bob McElrath wrote:
> This may be a dumb question, but is there some place where the arch
> maintainers are listed? Where the arch-specific trees are kept? Where
> would I go to get the latest set of relevant patches for alpha?
http://www.kernel.org/ ha
Jeff Garzik [[EMAIL PROTECTED]] wrote:
> Tom Rini wrote:
> > Which does boil down to having to work with trees other than Linus or
> > Alans. Remember, the official tree is not always the up-to-date tree,
> > or in the case of other arches, the most relevant tree.
>
> Yep. You could even look a
Tom Rini wrote:
> Which does boil down to having to work with trees other than Linus or
> Alans. Remember, the official tree is not always the up-to-date tree,
> or in the case of other arches, the most relevant tree.
Yep. You could even look at Linus as simply the x86 port maintainer :)
Excep
On Fri, Apr 20, 2001 at 10:59:34AM -0400, Eric S. Raymond wrote:
> Alan Cox <[EMAIL PROTECTED]>:
> > > well, though. One is the kind I'm bumping into right now, where
> > > somebody legitimately needs to make small (almost trivial) changes
> > > scattered all through the tree.
> >
> > Yep. But s
Alan Cox <[EMAIL PROTECTED]>:
> > well, though. One is the kind I'm bumping into right now, where
> > somebody legitimately needs to make small (almost trivial) changes
> > scattered all through the tree.
>
> Yep. But such changes are rare. Or should be.
Knowing that doesn't help me much, sinc
> I'll continue asking stupid questions, then. Like, under this system how
> can either you or the port maintainers maintain a good representation of
> how far out of sync they are with the main tree?
diff and read the output.
[bizzare sociopolitical mumble deleted]
> well, though. One is th
Alan Cox <[EMAIL PROTECTED]>:
> People send batches of small fixes to Linus or to me. So for example
> the S/390 folks send me things like 'fix the mm layer to match the
> changes in 2.4.3' and 'Update the DASD storage driver'. Each of
> which fixes one thing or one set of things and is easy to ch
> OK, so maybe I'm being stupid. But the implication of this talk of separate
> port trees and architecture merges is that these guys periodically send big
> resync patches to you and Linus.
>
> If that's not what's going on, what is?
People send batches of small fixes to Linus or to me. So for
> Alan Cox <[EMAIL PROTECTED]>:
> > I have for one. Its definitely the wrong approach to bomb Linus with patches
> > when doing the merge of an architecture. All the architecture folk with in
> > their own trees for good reason.
>
> On the other hand, Linus has objected to the One-Big-Patch appro
Alan Cox <[EMAIL PROTECTED]>:
> > Alan Cox <[EMAIL PROTECTED]>:
> > > I have for one. Its definitely the wrong approach to bomb Linus
> > > with patches when doing the merge of an architecture. All the
> > > architecture folk with in their own trees for good reason.
> >
> > On the other hand, Lin
Alan Cox <[EMAIL PROTECTED]>:
> I have for one. Its definitely the wrong approach to bomb Linus with patches
> when doing the merge of an architecture. All the architecture folk with in
> their own trees for good reason.
On the other hand, Linus has objected to the One-Big-Patch approach in
the p
> > we sent him every single one of those patches individually. and we'd
> > go insane trying to keep up with what he'd taken and what he'd dropped.
> >
> > until you've actually tried doing this, please don't attempt to criticise.
>
> Have _you_ tried? If I recall correctly, Linus spoke out ag
> What is the right procedure for doing changes like this? Is "don't
> touch that tree" a permanent condition, or am I going to get a chance
> to clean up the global CONFIG_ namespace after your next merge-down?
Feeding arch related stuff to the architecture maintainers.
> That's the main thing
Alan Cox <[EMAIL PROTECTED]>:
> > What is the right procedure for doing changes like this? Is "don't
> > touch that tree" a permanent condition, or am I going to get a chance
> > to clean up the global CONFIG_ namespace after your next merge-down?
>
> Feeding arch related stuff to the architectu
37 matches
Mail list logo
