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, and _not_
[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
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.
It
[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
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
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 the 2.4
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 what the
[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 ...
will
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_
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
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
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
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
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. I'm
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 is
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_ namespace
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
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? It
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:
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
Sun Mar 18 11:52:13 2001
@@ -0,0 +1,87 @@
+Linux 2.4.2 Secure Attention Key (SAK) handling
+18 March 2001, Andrew Morton <[EMAIL PROTECTED]>
+
+An operating system's Secure Attention Key is a security tool which is
+provided as protection against trojan password capturing
Mar 18 11:52:13 2001
@@ -0,0 +1,87 @@
+Linux 2.4.2 Secure Attention Key (SAK) handling
+18 March 2001, Andrew Morton [EMAIL PROTECTED]
+
+An operating system's Secure Attention Key is a security tool which is
+provided as protection against trojan password capturing programs. It
+is an undefeatable
Originally sent to [EMAIL PROTECTED] but that host is not resolving.
drivers/char/joystick/analog.c in 2.4.0-test10 has these lines.
MODULE_PARM(js,"1-16s");
#define ANALOG_PORTS16
static char *js[ANALOG_PORTS];
static int analog_options[ANALOG_PORTS];
Instead of hard coding 16
Originally sent to [EMAIL PROTECTED] but that host is not resolving.
drivers/char/joystick/analog.c in 2.4.0-test10 has these lines.
MODULE_PARM(js,"1-16s");
#define ANALOG_PORTS16
static char *js[ANALOG_PORTS];
static int analog_options[ANALOG_PORTS];
Instead of hard coding 16
401 - 428 of 428 matches
Mail list logo
