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
"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,
> CONFIG_BINFMT_SOM: arch/parisc/config.in arch/parisc/defconfig
> Not used in code anywhere. Can you get rid of this one?
Its used in the parisc tree as are most of the others you see. You probably want
to simply skip processing arch/parisc
-
To unsubscribe from this list: send the line "unsub
[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
Matthew Wilcox <[EMAIL PROTECTED]>:
> Code not merged yet.
:
> it's old and needs to die properly. i haven't had time to fix that yet.
Thanks for the information. Actually the parisc tree is one of the ones
that leaks the fewest of these symbols...
--
http://www.tuxedo.org
On Fri, Apr 20, 2001 at 03:47:43PM -0400, Eric S. Raymond wrote:
> CONFIG_BINFMT_SOM: arch/parisc/config.in arch/parisc/defconfig
>
> Not used in code anywhere. Can you get rid of this one?
Code not merged yet.
> CONFIG_DMB_TRAP: arch/parisc/kernel/sba_iommu.c
> CONFIG_FUNC_SIZE: arch/parisc/k
Matthew Wilcox <[EMAIL PROTECTED]>:
> > Could I ask you to audit your tree and change the prefix on any
> > CONFIG_ symbols that are private over there? This would make life
> > easier for my auditing tools (kxref and Stephen Cole's ach script).
>
> I don't think we have any of those. We cert
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
[EMAIL PROTECTED] said:
> Doesn't this seem a little like the problems occurring with lvm right
> now? A separate tree maintained with the maintainers not wanting
> others submitting patches that conflict with their particular tree?
> It seems that any project should be able to submit any patch
On Fri, 20 Apr 2001, Albert D. Cahalan wrote:
> This sucks for users of that architecture. Also, though not
> applicable to PA-RISC, it sucks for sub-architecture porters.
> (by sub-architecture I mean: Mac, PReP, PowerCore, BeBox, etc.)
As you said it so eloquently a few paragraphs down:
Matthew Wilcox writes:
> On Thu, Apr 19, 2001 at 10:07:22PM -0600, james rich wrote:
>> Doesn't this seem a little like the problems occurring with lvm right now?
>> A separate tree maintained with the maintainers not wanting others
>> submitting patches that conflict with their particular tree?
On Thu, Apr 19, 2001 at 10:07:22PM -0600, james rich wrote:
> Doesn't this seem a little like the problems occurring with lvm right now?
> A separate tree maintained with the maintainers not wanting others
> submitting patches that conflict with their particular tree? It seems
> that any project
On Thu, 19 Apr 2001, Matthew Wilcox wrote:
> On Thu, Apr 19, 2001 at 11:00:09PM -0400, Eric S. Raymond wrote:
> > 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_ namesp
On Thu, Apr 19, 2001 at 11:00:09PM -0400, Eric S. Raymond wrote:
> 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?
Our current status
Matthew Wilcox <[EMAIL PROTECTED]>:
> On Thu, Apr 19, 2001 at 18:50:34 EDT, Eric S. Raymond wrote:
> > Remove dead CONFIG_BINFMT_JAVA symbol.
>
> Please don't do this, it just makes merging our patches with Linus harder.
Bother. I've now heard "don't touch that tree!" from you and the ARM
folks
On Thu, Apr 19, 2001 at 18:50:34 EDT, Eric S. Raymond wrote:
> Remove dead CONFIG_BINFMT_JAVA symbol.
Please don't do this, it just makes merging our patches with Linus harder.
This has already been done in our tree since Feb 1. In fact, please
don't touch anything in the tree which is PA specif
Remove dead CONFIG_BINFMT_JAVA symbol.
--- arch/cris/config.in 2001/04/18 14:18:58 1.1
+++ arch/cris/config.in 2001/04/18 14:19:11
@@ -18,9 +18,6 @@
bool 'System V IPC' CONFIG_SYSVIPC
tristate 'Kernel support for ELF binaries' CONFIG_BINFMT_ELF
-if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
-
49 matches
Mail list logo
