Hi,
On Fri, 8 Apr 2005, Linus Torvalds wrote:
Also, I suspect that BKCVS actually bothers to get more details out of a
BK tree than I cared about. People have pestered Larry about it, so BKCVS
exports a lot of the nitty-gritty (per-file comments etc) that just
doesn't actually _matter_, but
Hi,
On Fri, 8 Apr 2005, Linus Torvalds wrote:
Yes. Per-file history is expensive in git, because if the way it is
indexed. Things are indexed by tree and by changeset, and there are no
per-file indexes.
You could create per-file _caches_ (*) on top of git if you wanted to make
it
Hi,
On Sat, 9 Apr 2005, Eric D. Mudama wrote:
For example bk does something like this:
A1 - A2 - A3 - BM
\- B1 - B2 --^
and instead of creating the merge changeset, one could merge them like
this:
A1 - A2 - A3 - B1 - B2
This results in a
Hi,
On Fri, 8 Apr 2005, Tupshin Harper wrote:
> > A1 -> A2 -> A3 -> B1 -> B2
> >
> > This results in a simpler repository, which is more scalable and which is
> > easier for users to work with (e.g. binary bug search).
> > The disadvantage would be it will cause more minor conflicts, when
Hi,
On Thu, 7 Apr 2005, Linus Torvalds wrote:
> I really disliked that in BitKeeper too originally. I argued with Larry
> about it, but Larry (correctly, I believe) argued that efficient and
> reliable distribution really requires the concept of "history is
> immutable". It makes replication
Hi,
On Thu, 7 Apr 2005, Linus Torvalds wrote:
I really disliked that in BitKeeper too originally. I argued with Larry
about it, but Larry (correctly, I believe) argued that efficient and
reliable distribution really requires the concept of history is
immutable. It makes replication much
Hi,
On Fri, 8 Apr 2005, Tupshin Harper wrote:
A1 - A2 - A3 - B1 - B2
This results in a simpler repository, which is more scalable and which is
easier for users to work with (e.g. binary bug search).
The disadvantage would be it will cause more minor conflicts, when changes
are
Hi,
On Wed, 6 Apr 2005, Dave Hansen wrote:
> > Why is this choice needed at all? Why would one choose SPARSEMEM over
> > DISCONTIGMEM?
>
> For now, it's only so people can test either one, and we don't have to
> try to toss DICONTIGMEM out of the kernel in fell swoop. When the
> memory
Hi,
On Wed, 6 Apr 2005, Dave Hansen wrote:
> On Wed, 2005-04-06 at 22:58 +0200, Roman Zippel wrote:
> > Dave Hansen wrote:
> > > --- memhotplug/mm/Kconfig~A6-mm-Kconfig 2005-04-04 09:04:48.0
> > > -0700
> > > +++ memhotplug-dave/mm/Kconfig
Hi,
Dave Hansen wrote:
> diff -puN mm/Kconfig~A6-mm-Kconfig mm/Kconfig
> --- memhotplug/mm/Kconfig~A6-mm-Kconfig 2005-04-04 09:04:48.0
> -0700
> +++ memhotplug-dave/mm/Kconfig2005-04-04 10:15:23.0 -0700
> @@ -0,0 +1,25 @@
> +choice
> + prompt "Memory model"
> +
Hi,
Dave Hansen wrote:
diff -puN mm/Kconfig~A6-mm-Kconfig mm/Kconfig
--- memhotplug/mm/Kconfig~A6-mm-Kconfig 2005-04-04 09:04:48.0
-0700
+++ memhotplug-dave/mm/Kconfig2005-04-04 10:15:23.0 -0700
@@ -0,0 +1,25 @@
+choice
+ prompt Memory model
+
Hi,
On Wed, 6 Apr 2005, Dave Hansen wrote:
On Wed, 2005-04-06 at 22:58 +0200, Roman Zippel wrote:
Dave Hansen wrote:
--- memhotplug/mm/Kconfig~A6-mm-Kconfig 2005-04-04 09:04:48.0
-0700
+++ memhotplug-dave/mm/Kconfig2005-04-04 10:15:23.0 -0700
@@ -0,0 +1,25
Hi,
On Wed, 6 Apr 2005, Dave Hansen wrote:
Why is this choice needed at all? Why would one choose SPARSEMEM over
DISCONTIGMEM?
For now, it's only so people can test either one, and we don't have to
try to toss DICONTIGMEM out of the kernel in fell swoop. When the
memory hotplug
Hi,
On Tue, 22 Mar 2005, Blaisorblade wrote:
> I've verified multiple times that if we have a situation like this
>
> bool A
> depends on TRUE
> help
> Bla bla1
>
> and
>
> bool A
> depends on FALSE
> help
> Bla bla2
>
> even if the first option is the displayed one, the help text used
Hi,
On Tue, 22 Mar 2005 [EMAIL PROTECTED] wrote:
> Replace a menu_add_prop mimicking menu_add_prompt with the latter.
>
> Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
> ---
>
> linux-2.6.11-paolo/scripts/kconfig/zconf.y |2 +-
> 1 files changed, 1 insertion(+), 1
Hi,
On Tue, 22 Mar 2005 [EMAIL PROTECTED] wrote:
Replace a menu_add_prop mimicking menu_add_prompt with the latter.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso [EMAIL PROTECTED]
---
linux-2.6.11-paolo/scripts/kconfig/zconf.y |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Hi,
On Tue, 22 Mar 2005, Blaisorblade wrote:
I've verified multiple times that if we have a situation like this
bool A
depends on TRUE
help
Bla bla1
and
bool A
depends on FALSE
help
Bla bla2
even if the first option is the displayed one, the help text used is the one
for
Hi,
On Sun, 13 Mar 2005, Matt Mackall wrote:
> I've noticed a few problems with HFS+ support in recent kernels on
> another user's machine running Ubuntu (Warty) running
> 2.6.8.1-3-powerpc. I'm not in a position to extensively test or fix
> either of these problem because of the fs tools
Hi,
On Sun, 13 Mar 2005, Matt Mackall wrote:
I've noticed a few problems with HFS+ support in recent kernels on
another user's machine running Ubuntu (Warty) running
2.6.8.1-3-powerpc. I'm not in a position to extensively test or fix
either of these problem because of the fs tools situation
Hi,
On Tue, 15 Feb 2005, Linus Torvalds wrote:
> So I'd still worry whether that added -1 actually fixes the bug, or just
> means that a off-by-one has to now be off-by-two to be noticeable..
You're right, even if one just writes 4095 bytes, it will also drop
tty->read_cnt characters later.
Hi,
On Tue, 15 Feb 2005, Linus Torvalds wrote:
So I'd still worry whether that added -1 actually fixes the bug, or just
means that a off-by-one has to now be off-by-two to be noticeable..
You're right, even if one just writes 4095 bytes, it will also drop
tty-read_cnt characters later.
Hi,
On Tue, 15 Feb 2005, Linus Torvalds wrote:
> > I've also seen more than one byte missing. For example when sending a big
> > chunk of bytes down the pty via an Emacs *shell* buffer up to 16 bytes are
> > missing somewhere in the middle.
>
> If it's NTTY (and I'm pretty certain it is - the
Hi,
On Tue, 15 Feb 2005, Linus Torvalds wrote:
I've also seen more than one byte missing. For example when sending a big
chunk of bytes down the pty via an Emacs *shell* buffer up to 16 bytes are
missing somewhere in the middle.
If it's NTTY (and I'm pretty certain it is - the generic
Hi,
On Mon, 14 Feb 2005, Len Brown wrote:
> Re: ACPI_BLACKLIST_YEAR depending on ACPI or ACPI_INTERPRETER -- either
> are fine.
Note that a patch that fixes this and a little more is waiting in -mm and
Sam's tree.
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe
Hi,
On Mon, 14 Feb 2005, Nick Warne wrote:
> So I can ignore the debug prints?
Yes.
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
Hi,
On Mon, 14 Feb 2005, Nick Warne wrote:
> Are the optimize && ? lines normal?
They are only debug prints, but I'm quite sure they are fixed in recent
versions.
> This is from a current tree that has an uptime of > 50 days
Could you specify "current tree"?
bye, Roman
-
To unsubscribe
Hi,
On Mon, 14 Feb 2005, Nick Warne wrote:
Are the optimize? lines normal?
They are only debug prints, but I'm quite sure they are fixed in recent
versions.
This is from a current tree that has an uptime of 50 days
Could you specify current tree?
bye, Roman
-
To unsubscribe from
Hi,
On Mon, 14 Feb 2005, Nick Warne wrote:
So I can ignore the debug prints?
Yes.
bye, Roman
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the
Hi,
On Mon, 14 Feb 2005, Len Brown wrote:
Re: ACPI_BLACKLIST_YEAR depending on ACPI or ACPI_INTERPRETER -- either
are fine.
Note that a patch that fixes this and a little more is waiting in -mm and
Sam's tree.
bye, Roman
-
To unsubscribe from this list: send the line unsubscribe
Hi,
On Wed, 9 Feb 2005, Larry McVoy wrote:
> This problem is nowhere near as hard as you are making it out to be
> but it is hard. But it's not that bad, we do this every time we do
> a CVS import, we have to intuit the changeset boundaries themselves,
> which is actually harder than what you
Hi,
On Wed, 9 Feb 2005, Larry McVoy wrote:
This problem is nowhere near as hard as you are making it out to be
but it is hard. But it's not that bad, we do this every time we do
a CVS import, we have to intuit the changeset boundaries themselves,
which is actually harder than what you are
Hi,
On Wed, 9 Feb 2005, Larry McVoy wrote:
(I just sent a similiar mail in private and didn't immediately realize it
didn't went to lkml, so sorry, who gets it twice.)
> On Wed, Feb 09, 2005 at 03:13:48PM -0500, Nicolas Pitre wrote:
> > I think what people want here is the tree structure
Hi,
On Wed, 9 Feb 2005, Jon Smirl wrote:
> Larry has said, write up a proposal for changes you want in bk. Send
> it to him for a quote. Come up with the cash and he will do the work.
Here is a simple one: restore the parent information in the gnupatch
option as they were about a year ago
Hi,
On Tue, 8 Feb 2005, Larry McVoy wrote:
Larry, it's interesting how you try to distract from the main problem
(which you don't mention with a single word) and instead continues to
badmouth me. Let's take a look.
> Short version: let's violate a license.
Wrong, if I wanted to violate the
Hi,
On Tue, 8 Feb 2005, Larry McVoy wrote:
Larry, it's interesting how you try to distract from the main problem
(which you don't mention with a single word) and instead continues to
badmouth me. Let's take a look.
Short version: let's violate a license.
Wrong, if I wanted to violate the
Hi,
On Wed, 9 Feb 2005, Jon Smirl wrote:
Larry has said, write up a proposal for changes you want in bk. Send
it to him for a quote. Come up with the cash and he will do the work.
Here is a simple one: restore the parent information in the gnupatch
option as they were about a year ago
Hi,
On Wed, 9 Feb 2005, Larry McVoy wrote:
(I just sent a similiar mail in private and didn't immediately realize it
didn't went to lkml, so sorry, who gets it twice.)
On Wed, Feb 09, 2005 at 03:13:48PM -0500, Nicolas Pitre wrote:
I think what people want here is the tree structure
Hi,
On Tue, 8 Feb 2005, Jon Smirl wrote:
> Write up a proposal of what you need. Send it to Larry and ask for a
> quote. Larry will probably even help you fill in things you missed in
> the proposal. Come to an agreement on terms for the proposal. Raise
> the cash, send it to Larry, wait for the
Hi,
On Tue, 8 Feb 2005, Larry McVoy wrote:
> Nice, Roman. All I need is a cooperating third party who is willing to
> give me your code under a different (albeit invalid) license.
Short version: Bullshit.
Long version: See previous mails.
bye, Roman
-
To unsubscribe from this list: send the
Hi,
On Tue, 8 Feb 2005, Jon Smirl wrote:
> Larry has said he will do the work you want if you pay him.
Usually I'm all for giving the benefit of the doubt, but in this case I'd
prefer to know exactly, what I would get for the money.
But as I said by now I know enough about this that I can do
Hi,
On Tue, 8 Feb 2005, Theodore Ts'o wrote:
> I don't know how many years it was before people decided to
> give up on the emacs vs. vi wars, but can we please put a more hasty
> end to the bk license flamewars? Many thanks,
It's not really the same, if it would be just about personal
Hi,
On Tue, 8 Feb 2005, Larry McVoy wrote:
> > > I think you are dreaming. You've gone from wanting enough information
> > > to supposedly debug your source tree to being explicit about wanting to
> > > recreate the entire BK history in a different system. The former is a
> > > reasonable
Hi,
On Tue, 8 Feb 2005 [EMAIL PROTECTED] wrote:
> > Why should I pay for something, I could easily do myself in less time?
>
> Why does the phrase "Shut up and code..." suddenly wander through my mind???
You didn't really read what I explained in detail, didn't you?
bye, Roman
-
To
Hi,
On Tue, 8 Feb 2005, Larry McVoy wrote:
> I think you are dreaming. You've gone from wanting enough information
> to supposedly debug your source tree to being explicit about wanting to
> recreate the entire BK history in a different system. The former is a
> reasonable request, I suppose,
Hi,
On Tue, 8 Feb 2005, Jon Smirl wrote:
> Roman, if you want this so bad why don't you just pay Larry for the
> three month's work?
Why should I pay for something, I could easily do myself in less time?
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Hi,
On Sun, 6 Feb 2005, Larry McVoy wrote:
> [Larry continues to pull numbers out of his arse.]
Out of sympathy to Al I cut the crap short. If you (or anyone else) really
want to know, contact me privately.
The 85% number is of secondary interest only anyway, my (undisputed)
argumentation
Hi,
On Tue, 8 Feb 2005, Matthew Wilcox wrote:
>
> David Holland pointed out that Make has a lot of implicit suffix rules
> built in and you can disable them by setting ".SUFFIXES:". As an
> example, checking the debugging information shows we no longer try to
> compile anything from a '.f'
Hi,
On Tue, 8 Feb 2005, Matthew Wilcox wrote:
David Holland pointed out that Make has a lot of implicit suffix rules
built in and you can disable them by setting .SUFFIXES:. As an
example, checking the debugging information shows we no longer try to
compile anything from a '.f' suffix.
Hi,
On Sun, 6 Feb 2005, Larry McVoy wrote:
[Larry continues to pull numbers out of his arse.]
Out of sympathy to Al I cut the crap short. If you (or anyone else) really
want to know, contact me privately.
The 85% number is of secondary interest only anyway, my (undisputed)
argumentation
Hi,
On Tue, 8 Feb 2005, Jon Smirl wrote:
Roman, if you want this so bad why don't you just pay Larry for the
three month's work?
Why should I pay for something, I could easily do myself in less time?
bye, Roman
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
Hi,
On Tue, 8 Feb 2005, Larry McVoy wrote:
I think you are dreaming. You've gone from wanting enough information
to supposedly debug your source tree to being explicit about wanting to
recreate the entire BK history in a different system. The former is a
reasonable request, I suppose, but
Hi,
On Tue, 8 Feb 2005 [EMAIL PROTECTED] wrote:
Why should I pay for something, I could easily do myself in less time?
Why does the phrase Shut up and code... suddenly wander through my mind???
You didn't really read what I explained in detail, didn't you?
bye, Roman
-
To unsubscribe from
Hi,
On Tue, 8 Feb 2005, Larry McVoy wrote:
I think you are dreaming. You've gone from wanting enough information
to supposedly debug your source tree to being explicit about wanting to
recreate the entire BK history in a different system. The former is a
reasonable request, I
Hi,
On Tue, 8 Feb 2005, Theodore Ts'o wrote:
I don't know how many years it was before people decided to
give up on the emacs vs. vi wars, but can we please put a more hasty
end to the bk license flamewars? Many thanks,
It's not really the same, if it would be just about personal
Hi,
On Tue, 8 Feb 2005, Jon Smirl wrote:
Larry has said he will do the work you want if you pay him.
Usually I'm all for giving the benefit of the doubt, but in this case I'd
prefer to know exactly, what I would get for the money.
But as I said by now I know enough about this that I can do
Hi,
On Tue, 8 Feb 2005, Larry McVoy wrote:
Nice, Roman. All I need is a cooperating third party who is willing to
give me your code under a different (albeit invalid) license.
Short version: Bullshit.
Long version: See previous mails.
bye, Roman
-
To unsubscribe from this list: send the
Hi,
On Tue, 8 Feb 2005, Jon Smirl wrote:
Write up a proposal of what you need. Send it to Larry and ask for a
quote. Larry will probably even help you fill in things you missed in
the proposal. Come to an agreement on terms for the proposal. Raise
the cash, send it to Larry, wait for the
Hi,
On Sun, 6 Feb 2005, Larry McVoy wrote:
> > $ find -name \*,v -a ! -path ./BitKeeper\* -a ! -name ChangeSet,v | xargs
> > rlog | egrep '\(Logical change 1.[0-9]+\)' | wc -l
> > 187576
>
> Bzzt. You forgot all the intial deltas which are not marked with the
> logical change comment. And
Hi,
On Fri, 4 Feb 2005, Larry McVoy wrote:
> > > > > CVS BitKeeper [*]
> > > > > Deltas 235,956 280,212
>
> You need to rethink your math, you are way off. I'll explain it so that
> the rest of the people can see this is just pure FUD.
>
> To make
Hi,
On Fri, 4 Feb 2005, Larry McVoy wrote:
CVS BitKeeper [*]
Deltas 235,956 280,212
You need to rethink your math, you are way off. I'll explain it so that
the rest of the people can see this is just pure FUD.
To make sure this was
Hi,
On Sun, 6 Feb 2005, Larry McVoy wrote:
$ find -name \*,v -a ! -path ./BitKeeper\* -a ! -name ChangeSet,v | xargs
rlog | egrep '\(Logical change 1.[0-9]+\)' | wc -l
187576
Bzzt. You forgot all the intial deltas which are not marked with the
logical change comment. And just to
Hi,
On Fri, 4 Feb 2005, Dmitry Torokhov wrote:
> The "generic input layer" submenu is comparable to SCSI or ALSA and
> has similar menu structure with userland interfaces on top and drivers
> below them. Hardware ports (serio, gameport) "live" outside of generic
> input layer and are shown there
Hi,
On Fri, 4 Feb 2005, Vojtech Pavlik wrote:
> > When I go into a menu I explore option and submenus from top to bottom.
> > So I will see PS/2 or serial, and will go there and select what I need.
> > Then I will see that generic input layer is also needed for keyboard
> > and go there.
> >
>
Hi,
On Fri, 4 Feb 2005, Vojtech Pavlik wrote:
When I go into a menu I explore option and submenus from top to bottom.
So I will see PS/2 or serial, and will go there and select what I need.
Then I will see that generic input layer is also needed for keyboard
and go there.
If generic
Hi,
On Fri, 4 Feb 2005, Dmitry Torokhov wrote:
The generic input layer submenu is comparable to SCSI or ALSA and
has similar menu structure with userland interfaces on top and drivers
below them. Hardware ports (serio, gameport) live outside of generic
input layer and are shown there so they
Hi,
On Thu, 3 Feb 2005, Peter Busser wrote:
> - What happens when you run existing commercial applications which have not
> been compiled using GCC.
>From http://pax.grsecurity.net/docs/pax.txt:
The goal of the PaX project is to research various defense mechanisms
against the
Hi,
On Thu, 3 Feb 2005, Peter Busser wrote:
- What happens when you run existing commercial applications which have not
been compiled using GCC.
From http://pax.grsecurity.net/docs/pax.txt:
The goal of the PaX project is to research various defense mechanisms
against the exploitation
Hi,
On Fri, 28 Jan 2005, Tom Zanussi wrote:
> +static inline int rchan_create_file(const char *chanpath,
> + struct dentry **dentry,
> + struct rchan_buf *data)
> +{
> + int err;
> + const char * fname;
> + struct dentry
Hi,
On Mon, 31 Jan 2005, Adrian Bunk wrote:
> > Why not just let XFS_FS select EXPORTFS directly:
> >
> > config XFS_FS
> > select EXPORTFS if NFSD
>
> This has the wrong semantics:
> With NFSD=m and XFS_FS=y it only sets EXPORTFS=m.
This should do it then:
config XFS_FS
select
Hi,
On Mon, 31 Jan 2005, Takashi Iwai wrote:
> > Index: linux-2.6.11/sound/core/Kconfig
> > ===
> > --- linux-2.6.11.orig/sound/core/Kconfig2005-01-29 22:50:43.345956362
> > +0100
> > +++ linux-2.6.11/sound/core/Kconfig
Hi,
On Fri, 28 Jan 2005, Tom Zanussi wrote:
+static inline int rchan_create_file(const char *chanpath,
+ struct dentry **dentry,
+ struct rchan_buf *data)
+{
+ int err;
+ const char * fname;
+ struct dentry
Hi,
On Mon, 31 Jan 2005, Adrian Bunk wrote:
> WANT_EXPORTFS gets selected by NFSD.
>
> EXPORTFS is usually WANT_EXPORTFS, but if WANT_EXPORTFS=m and
> XFS_WANT_EXPORT=y, then EXPORTFS=y.
>
> Since XFS_WANT_EXPORT itself depends on WANT_EXPORTFS this was my
> workaround to avoid a circular
Hi,
On Sun, 30 Jan 2005, Adrian Bunk wrote:
>
> +config WANT_EXPORTFS
> + tristate
> + select EXPORTFS
> +
> config EXPORTFS
> tristate
> - default NFSD
>
What's the difference between these two?
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe
Hi,
On Sat, 29 Jan 2005, Vojtech Pavlik wrote:
> > That doesn't necessarilly mean we have to pack everything into a single
> > structure. E.g. we present pci boards with multiple functions as multiple
> > devices, the same can be done for input devices. More important is that
> > kernel
Hi,
On Sat, 29 Jan 2005, Dmitry Torokhov wrote:
> Ok, what about making some submenus to manage number of options, like in
> the patch below?
I'd rather move it to the bottom and the menus had no dependencies.
Below is an alternative patch, which does a rather complete cleanup.
bye, Roman
---
Hi,
On Sat, 29 Jan 2005, Dmitry Torokhov wrote:
> Well, with the current Kconfig I can de-select INPUT and still select
> serio and serio_raw and access my AUX port via /dev/psaux. I don't know
> if anyone would really do it, but why not?
>
> Btw, what was the point of your patch?
See the
Hi,
On Sat, 29 Jan 2005, Dmitry Torokhov wrote:
> > That's fine, but why is it in the input menu? How do you suggest to make
> > it selectable without selecting input and without messing the menu
> > structure?
>
> Well, probably split input into sections, one of the options would be
>
Hi,
On Sat, 29 Jan 2005, Dmitry Torokhov wrote:
> I can assure you that serio_raw driver _does not_ use input system - it is
> implementation of pre 2.6 /dev/psaux interface giving you access to raw AUX
> data. It was written so we can still use PS/2 devices for which we don't have
> proper
Hi,
On Sat, 29 Jan 2005, Dmitry Torokhov wrote:
> On Saturday 29 January 2005 17:20, Roman Zippel wrote:
> > --- linux-2.6.11.orig/drivers/input/serio/Kconfig 2005-01-29
> > 22:50:43.404946203 +0100
> > +++ linux-2.6.11/drivers/input/serio/Kconfig2005-01-29
&
This properly indents the input menu.
Move SOUND_GAMEPORT to its user, so it's easier to set it to y, even if
GAMEPORT is n.
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
drivers/input/Kconfig |3 +++
drivers/input/gameport/Kconfig | 21 +
d
This properly indents various driver menus.
Remove PARPORT_PC_CML1.
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
mtd/Kconfig | 18 +-
parport/Kconfig | 12 +++-
video/Kconfig | 29 ++---
3 files changed, 26 insertions(
This properly indents the USB menu.
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
Kconfig | 18 ++
host/Kconfig| 18 --
storage/Kconfig |1 +
3 files changed, 19 insertions(+), 18 deletions(-)
Index: linux-2.6.11/drivers/us
This properly indents the sound menu.
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
core/Kconfig |7 ++-
oss/Kconfig |8
2 files changed, 10 insertions(+), 5 deletions(-)
Index: linux-2.6.11/sound/oss/K
MAGIC_SYSRQ menu entries.
Remove unnecessary "default n" options.
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
arch/i386/Kconfig.debug |3 +-
init/Kconfig| 20 --
lib/Kconfig.debug | 53 +++-
This properly indents the cpufreq menu.
Remove CPU_FREQ_TABLE as visible option and use select instead.
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
arch/i386/kernel/cpu/cpufreq/Kconfig | 54 +++
drivers/cpufreq/Kconfig
This properly indents the ACPI menu.
Hide ACPI_BLACKLIST_YEAR when not needed.
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
Kconfig | 36 +---
1 files changed, 13 insertions(+), 23 deletions(-)
Index: linux-2.6.11/drivers/acpi/K
This properly indents the bus options menu.
Merge the two MCA menu entries.
Remove unnecessary "default n" options.
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
arch/i386/Kconfig|8 ++--
drivers/pci/Kconfig |2 +-
drivers/pci/pcie/Kconfig |
Hi,
The following patches cleans up some of the worst offenders, which mess up
the kconfig menu structure. The patches apply to 2.6.11-rc2-mm2 and
2.6.11-rc2-bk7, the only exception is the one below. Andrew, I leave it
to you what to do with it, maybe fold it directly into kgdb-ga.patch?
bye,
Hi,
On Fri, 28 Jan 2005, Vojtech Pavlik wrote:
> I'm very sorry about the locking, but the thing grew up in times of
> kernel 2.0, which didn't require any locking. There are a few possible
> races with device registration/unregistration, and it's on my list to
> fix that, however under normal
Hi,
On Fri, 28 Jan 2005, Vojtech Pavlik wrote:
I'm very sorry about the locking, but the thing grew up in times of
kernel 2.0, which didn't require any locking. There are a few possible
races with device registration/unregistration, and it's on my list to
fix that, however under normal
Hi,
The following patches cleans up some of the worst offenders, which mess up
the kconfig menu structure. The patches apply to 2.6.11-rc2-mm2 and
2.6.11-rc2-bk7, the only exception is the one below. Andrew, I leave it
to you what to do with it, maybe fold it directly into kgdb-ga.patch?
bye,
This properly indents the bus options menu.
Merge the two MCA menu entries.
Remove unnecessary default n options.
Signed-off-by: Roman Zippel [EMAIL PROTECTED]
---
arch/i386/Kconfig|8 ++--
drivers/pci/Kconfig |2 +-
drivers/pci/pcie/Kconfig |2 +-
drivers/pcmcia
This properly indents the ACPI menu.
Hide ACPI_BLACKLIST_YEAR when not needed.
Signed-off-by: Roman Zippel [EMAIL PROTECTED]
---
Kconfig | 36 +---
1 files changed, 13 insertions(+), 23 deletions(-)
Index: linux-2.6.11/drivers/acpi/Kconfig
This properly indents the cpufreq menu.
Remove CPU_FREQ_TABLE as visible option and use select instead.
Signed-off-by: Roman Zippel [EMAIL PROTECTED]
---
arch/i386/kernel/cpu/cpufreq/Kconfig | 54 +++
drivers/cpufreq/Kconfig | 20
MAGIC_SYSRQ menu entries.
Remove unnecessary default n options.
Signed-off-by: Roman Zippel [EMAIL PROTECTED]
---
arch/i386/Kconfig.debug |3 +-
init/Kconfig| 20 --
lib/Kconfig.debug | 53 +++-
3 files changed, 32
This properly indents the sound menu.
Signed-off-by: Roman Zippel [EMAIL PROTECTED]
---
core/Kconfig |7 ++-
oss/Kconfig |8
2 files changed, 10 insertions(+), 5 deletions(-)
Index: linux-2.6.11/sound/oss/Kconfig
This properly indents various driver menus.
Remove PARPORT_PC_CML1.
Signed-off-by: Roman Zippel [EMAIL PROTECTED]
---
mtd/Kconfig | 18 +-
parport/Kconfig | 12 +++-
video/Kconfig | 29 ++---
3 files changed, 26 insertions(+), 33
This properly indents the input menu.
Move SOUND_GAMEPORT to its user, so it's easier to set it to y, even if
GAMEPORT is n.
Signed-off-by: Roman Zippel [EMAIL PROTECTED]
---
drivers/input/Kconfig |3 +++
drivers/input/gameport/Kconfig | 21 +
drivers/input
This properly indents the USB menu.
Signed-off-by: Roman Zippel [EMAIL PROTECTED]
---
Kconfig | 18 ++
host/Kconfig| 18 --
storage/Kconfig |1 +
3 files changed, 19 insertions(+), 18 deletions(-)
Index: linux-2.6.11/drivers/usb/host
Hi,
On Sat, 29 Jan 2005, Dmitry Torokhov wrote:
On Saturday 29 January 2005 17:20, Roman Zippel wrote:
--- linux-2.6.11.orig/drivers/input/serio/Kconfig 2005-01-29
22:50:43.404946203 +0100
+++ linux-2.6.11/drivers/input/serio/Kconfig2005-01-29
22:56:42.549085439 +0100
801 - 900 of 1055 matches
Mail list logo
