Hi,
On Wed, 11 Jul 2007, Rob Landley wrote:
Replace name Linux Kernel in menuconfig with a macro (defaulting to Linux
Kernel if not -Ddefined by the makefile), and remove a few unnecessary
occurrences of kernel in pop-up text.
Could you drop the PROJECT_NAME changes for now? The rest looks
Hi,
On Thu, 12 Jul 2007, I wrote:
On Wed, 11 Jul 2007, Rob Landley wrote:
Replace name Linux Kernel in menuconfig with a macro (defaulting to Linux
Kernel if not -Ddefined by the makefile), and remove a few unnecessary
occurrences of kernel in pop-up text.
Could you drop the
Hi,
On Wed, 11 Jul 2007, Linus Torvalds wrote:
Sure, bugs happen, but code that everybody runs the same generally doesn't
break. So a CPU scheduler doesn't worry me all that much. CPU schedulers
are easy.
A little more advance warning wouldn't have hurt though.
The new scheduler does
Hi,
On Wed, 11 Jul 2007, Lennart Sorensen wrote:
> On Wed, Jul 11, 2007 at 03:18:46AM +0200, Roman Zippel wrote:
> > This is really not an API that needs to deal with such large time range.
>
> No one will want to use PPS API to keep accurate time past 2030? Why
> not? Or s
Hi,
On Wed, 11 Jul 2007, Lennart Sorensen wrote:
On Wed, Jul 11, 2007 at 03:18:46AM +0200, Roman Zippel wrote:
This is really not an API that needs to deal with such large time range.
No one will want to use PPS API to keep accurate time past 2030? Why
not? Or should we be forced
Hi,
On Tuesday 10 July 2007, Lennart Sorensen wrote:
> On Sun, Jul 01, 2007 at 09:24:41PM +0200, Rodolfo Giometti wrote:
> > struct pps_timedata_s {
> >__32 sec;
> >__32 nsec;
> > }
> >
> > Ok? I think 32 bits are enought for keeping seconds... :)
>
> You want to
Hi,
On Tuesday 10 July 2007, Lennart Sorensen wrote:
On Sun, Jul 01, 2007 at 09:24:41PM +0200, Rodolfo Giometti wrote:
struct pps_timedata_s {
__32 sec;
__32 nsec;
}
Ok? I think 32 bits are enought for keeping seconds... :)
You want to purposely define an API
Hi,
On Tuesday 03 July 2007, Thomas Gleixner wrote:
> The clock_was_set() call in seconds_overflow() which happens only when
> leap seconds are inserted / deleted is wrong in two aspects:
>
> 1. it results in a call to on_each_cpu() with interrupts disabled
> 2. it is potential deadlock source
Hi,
On Tuesday 03 July 2007, Thomas Gleixner wrote:
The clock_was_set() call in seconds_overflow() which happens only when
leap seconds are inserted / deleted is wrong in two aspects:
1. it results in a call to on_each_cpu() with interrupts disabled
2. it is potential deadlock source vs.
Hi,
On Sat, 30 Jun 2007, Andrew Morton wrote:
> > > I continue to believe that kbuild's lets-trash-your-symlink behaviour is
> > > obnoxious, but I was unable to persuade anyone else of this.
> >
> > I thought we fixed that long time ago?!?!
>
> Nope, a simple `make oldconfig' breaks the
Hi,
On Fri, 29 Jun 2007, Andrew Morton wrote:
> > Reset generates values only if Kconfig and .config agree.
>
> unclear. Could you please explain further what this change does?
Normally generated values (Kconfig entries without a prompt) are cleared
as they are regenerated anyway and so they
Hi,
On Fri, 29 Jun 2007, Andrew Morton wrote:
Reset generates values only if Kconfig and .config agree.
unclear. Could you please explain further what this change does?
Normally generated values (Kconfig entries without a prompt) are cleared
as they are regenerated anyway and so they
Hi,
On Sat, 30 Jun 2007, Andrew Morton wrote:
I continue to believe that kbuild's lets-trash-your-symlink behaviour is
obnoxious, but I was unable to persuade anyone else of this.
I thought we fixed that long time ago?!?!
Nope, a simple `make oldconfig' breaks the symlink.
fig before
> running oldconfig saved a large number of config items from getting lost.
This patch should help for this, so that this isn't done when Kconfig or
.config has been changed and they are not in sync.
bye, Roman
Reset generates values only if Kconfig and .config agree.
Signed-off
a large number of config items from getting lost.
This patch should help for this, so that this isn't done when Kconfig or
.config has been changed and they are not in sync.
bye, Roman
Reset generates values only if Kconfig and .config agree.
Signed-off-by: Roman Zippel [EMAIL PROTECTED
Hi,
On Fri, 29 Jun 2007, Alan Cox wrote:
> > > check_signature is relevant for anything with MMIO space (for example you
> > > can legitimately want to check_signature a MAC68K Nubus ROM).
> >
> > A generic check_signature() is a little difficult if we have separate io
> > functions for every
Hi,
On Thu, 28 Jun 2007, Alan Cox wrote:
> > check_signature() needs readb() but with some setups (s390, m68k
> > allmodconfig)
> > there is no implementation of readb. This causes build errors with
> > -Werror-implicit-function-declaration.
>
> This completely bogus. readb() should be
Hi,
On Thu, 28 Jun 2007, Jeremy Fitzhardinge wrote:
> Roman Zippel wrote:
> > This could be avoided by reordering things within elf.h, but is it really
> > necessary since there is no user of this right now?
> >
>
> Well, yes, I don't have much need to include EL
Hi,
On Thu, 28 Jun 2007, Jeremy Fitzhardinge wrote:
Roman Zippel wrote:
This could be avoided by reordering things within elf.h, but is it really
necessary since there is no user of this right now?
Well, yes, I don't have much need to include ELF headers in asm now, but I
still
Hi,
On Thu, 28 Jun 2007, Alan Cox wrote:
check_signature() needs readb() but with some setups (s390, m68k
allmodconfig)
there is no implementation of readb. This causes build errors with
-Werror-implicit-function-declaration.
This completely bogus. readb() should be present on M68K,
Hi,
On Fri, 29 Jun 2007, Alan Cox wrote:
check_signature is relevant for anything with MMIO space (for example you
can legitimately want to check_signature a MAC68K Nubus ROM).
A generic check_signature() is a little difficult if we have separate io
functions for every bus.
Does
Hi,
On Tue, 26 Jun 2007, Jeremy Fitzhardinge wrote:
> > We have the __ASSEMBLY__ define for this, so just for asm code we don't need
> > a separate header.
> >
>
> Hm. The number of __ASSEMBLY__s end up being pretty large, and it just seemed
> cleaner to put them in separate headers.
This
Hi,
On Tue, 26 Jun 2007, Jeremy Fitzhardinge wrote:
We have the __ASSEMBLY__ define for this, so just for asm code we don't need
a separate header.
Hm. The number of __ASSEMBLY__s end up being pretty large, and it just seemed
cleaner to put them in separate headers.
This could be
Hi,
On Tue, 26 Jun 2007, Ingo Molnar wrote:
Another BTW before someone takes this seriously:
> ( whether there is any correlation between a decade long fundamental
> suckage and stagnation of the Linux time and NTP subsystem and Roman's
> decade long negative feedback presence in that area
Hi,
On Tue, 26 Jun 2007, Ingo Molnar wrote:
> if you are curious why Roman's reaction to this patch was so negative:
Instead of answering all the open questions, pretty much the second thing
you do is to discredit me personally. :-(
BTW there is a difference between critical and negative...
Hi,
On Tue, 26 Jun 2007, Ingo Molnar wrote:
if you are curious why Roman's reaction to this patch was so negative:
Instead of answering all the open questions, pretty much the second thing
you do is to discredit me personally. :-(
BTW there is a difference between critical and negative...
Hi,
On Tue, 26 Jun 2007, Ingo Molnar wrote:
Another BTW before someone takes this seriously:
( whether there is any correlation between a decade long fundamental
suckage and stagnation of the Linux time and NTP subsystem and Roman's
decade long negative feedback presence in that area of
Hi,
On Tue, 26 Jun 2007, Jesper Juhl wrote:
> Even if it is not faster, what would make it slower? Have you spotted
> something I have not?
There are other ways to read the clock and would require similiar
synchronization hooks.
Some archs can implement sys_time() in userspace, so there this
Hi,
On Mon, 25 Jun 2007, Jesper Juhl wrote:
> > On Monday 25 June 2007, Ingo Molnar wrote:
> >
> > > the patch improves the sysbench OLTP macrobenchmark significantly:
> >
> > Has that any real practical relevance?
> >
> It seems to me that Ingo's patch offers slightly improved performance
>
Hi,
On Monday 25 June 2007, Ingo Molnar wrote:
> the patch improves the sysbench OLTP macrobenchmark significantly:
Has that any real practical relevance?
> @@ -373,6 +376,20 @@ void do_gettimeofday (struct timeval *tv
>
> tv->tv_sec = sec;
> tv->tv_usec = usec;
> +
> + /*
> +
Hi,
On Wed, 20 Jun 2007, Jeremy Fitzhardinge wrote:
> linux/elf-const.h - ELF constants, includable by asm code
BTW who's the maniac who tries to use this in asm code?
Many of these constants are pretty useless without the corresponding
structure definitions.
bye, Roman
-
To
Hi,
On Mon, 25 Jun 2007, Clemens Koller wrote:
> > glibc provides its own version, so it doesn't has to be exported at all.
>
> AFAIK the glibc folks want to rely more on the linux kernel headers
> in the future and not provide more or less redundant headers anymore...
In this case it's more
Hi,
On Mon, 25 Jun 2007, David Woodhouse wrote:
> On Wed, 2007-06-20 at 16:08 -0700, Jeremy Fitzhardinge wrote:
> > This patch cleans up the ELF headers and their users. It does several
> > related things:
>
> Looks good. We can get away with exporting a lot less of this to
> userspace too,
Hi,
On Wed, 20 Jun 2007, Jeremy Fitzhardinge wrote:
> This patch cleans up the ELF headers and their users. It does several
> related things:
>
> 1. split linux/elf.h into pieces
>
> This splits linux/elf.h into several pieces:
> linux/elf.h - still the common elf header,
>
-by: Duane Griffin <[EMAIL PROTECTED]>
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
fs/hfsplus/btree.c |4 +
fs/hfsplus/dir.c|2
fs/hfsplus/hfsplus_fs.h |4 +
fs/hfsplus/inode.c |5 +
fs/hfsplus/super.c |1
ary memory allocation compared to using the string conversion
routine directly in the new functions.
Signed-off-by: Duane Griffin <[EMAIL PROTECTED]>
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
fs/hfsplus/unicode.c | 105 +--
1 f
compared to using the string conversion
routine directly in the new functions.
Signed-off-by: Duane Griffin [EMAIL PROTECTED]
Signed-off-by: Roman Zippel [EMAIL PROTECTED]
---
fs/hfsplus/unicode.c | 105 +--
1 file changed, 60 insertions(+), 45 deletions
PROTECTED]
Signed-off-by: Roman Zippel [EMAIL PROTECTED]
---
fs/hfsplus/btree.c |4 +
fs/hfsplus/dir.c|2
fs/hfsplus/hfsplus_fs.h |4 +
fs/hfsplus/inode.c |5 +
fs/hfsplus/super.c |1
fs/hfsplus/unicode.c| 123
Hi,
On Wed, 20 Jun 2007, Jeremy Fitzhardinge wrote:
This patch cleans up the ELF headers and their users. It does several
related things:
1. split linux/elf.h into pieces
This splits linux/elf.h into several pieces:
linux/elf.h - still the common elf header,
Hi,
On Mon, 25 Jun 2007, David Woodhouse wrote:
On Wed, 2007-06-20 at 16:08 -0700, Jeremy Fitzhardinge wrote:
This patch cleans up the ELF headers and their users. It does several
related things:
Looks good. We can get away with exporting a lot less of this to
userspace too, can't we?
Hi,
On Mon, 25 Jun 2007, Clemens Koller wrote:
glibc provides its own version, so it doesn't has to be exported at all.
AFAIK the glibc folks want to rely more on the linux kernel headers
in the future and not provide more or less redundant headers anymore...
In this case it's more an ABI
Hi,
On Wed, 20 Jun 2007, Jeremy Fitzhardinge wrote:
linux/elf-const.h - ELF constants, includable by asm code
BTW who's the maniac who tries to use this in asm code?
Many of these constants are pretty useless without the corresponding
structure definitions.
bye, Roman
-
To
Hi,
On Monday 25 June 2007, Ingo Molnar wrote:
the patch improves the sysbench OLTP macrobenchmark significantly:
Has that any real practical relevance?
@@ -373,6 +376,20 @@ void do_gettimeofday (struct timeval *tv
tv-tv_sec = sec;
tv-tv_usec = usec;
+
+ /*
+ *
Hi,
On Mon, 25 Jun 2007, Jesper Juhl wrote:
On Monday 25 June 2007, Ingo Molnar wrote:
the patch improves the sysbench OLTP macrobenchmark significantly:
Has that any real practical relevance?
It seems to me that Ingo's patch offers slightly improved performance
for any program
Hi,
On Tue, 26 Jun 2007, Jesper Juhl wrote:
Even if it is not faster, what would make it slower? Have you spotted
something I have not?
There are other ways to read the clock and would require similiar
synchronization hooks.
Some archs can implement sys_time() in userspace, so there this
Hi,
On Sat, 23 Jun 2007, Jan Engelhardt wrote:
> Would it make sense to define a new entity called "configmenu" (or something
> else) that is equivalent to menuconfig with the following changes?
>
> * it creates a CM_ variable instead of a CONFIG_ one
> * the CM_ symbols are not available to
Hi,
On Sat, 23 Jun 2007, Wyatt Banks wrote:
> Besides this redundancy, mode is the BSD file type and mode
> bits (see Apple TechNote 1150 for details) and is never 0.
This is wrong, there is an extra note:
"If the S_IFMT field (upper 4 bits) of the fileMode field is zero, then
Mac OS X
Hi,
On Sat, 23 Jun 2007, Wyatt Banks wrote:
Besides this redundancy, mode is the BSD file type and mode
bits (see Apple TechNote 1150 for details) and is never 0.
This is wrong, there is an extra note:
If the S_IFMT field (upper 4 bits) of the fileMode field is zero, then
Mac OS X assumes
Hi,
On Sat, 23 Jun 2007, Jan Engelhardt wrote:
Would it make sense to define a new entity called configmenu (or something
else) that is equivalent to menuconfig with the following changes?
* it creates a CM_ variable instead of a CONFIG_ one
* the CM_ symbols are not available to
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
> But why? Let it do just one thing, and do it well. Is their
> any requirement anywhere that requires us to give a dual
> meaning to these menuconfig objects -- i.e. to also control
> the inclusion / exclusion of code from the kernel as well as
>
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
> Yup, so how / why am I wrong? I was making the point that a
> "menuconfig" does not have code associated with it.
Which is wrong, it's not and will not be limited to this.
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
> 1. Kconfig symbols will always have code associated with them.
> That's the entire purpose of Kconfig, is it not?
A possible counter example: CONFIG_SCSI.
(RAID_ATTRS is currently a little misplaced).
It's optional for any config symbol to have
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
> > menuconfig is really a type of config symbol, rather than a type of menu.
>
> Well, I'd have to disagree here. A config symbol has code associated
> with it (at least _all_ config symbols in the kernel originally did, till
> when these
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
> given "menuconfig FOO depends on BAR", then all the "config BAZ"s
> inside this menuconfig also automatically "depend on" BAR too.
> This is simpler in the long run because it requires least amount
> (actually none) of redundant typing
I don't
Hi,
On Fri, 22 Jun 2007, Jan Engelhardt wrote:
> V4L_USB_DRIVERS=y turns USB into =y? That can't be. It should give the "this
> depends on another symbol [USB] that is modular".
That's not how it works, the enclosed symbols depend now on
V4L_USB_DRIVERS, which is a boolean and it can only have
But if only want to enable a video driver, I likely don't want a radio
driver...
bye, Roman
Reset generates values only if Kconfig and .config agree.
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
scripts/kconfig/confdata.c | 37 ++---
1 file
Hi,
On Fri, 22 Jun 2007, Mauro Carvalho Chehab wrote:
> Hi Roman,
>
> Several instabilities on Kconfig started to happen after replacing
> Kconfig menus to use menuconfig, as this one, reported by Oliver:
>
> Em Qui, 2007-06-21 às 13:50 +0200, Oliver Neukum escreveu:
> > Am Donnerstag, 21.
Hi,
On Fri, 22 Jun 2007, Mauro Carvalho Chehab wrote:
Hi Roman,
Several instabilities on Kconfig started to happen after replacing
Kconfig menus to use menuconfig, as this one, reported by Oliver:
Em Qui, 2007-06-21 às 13:50 +0200, Oliver Neukum escreveu:
Am Donnerstag, 21. Juni 2007
Hi,
On Fri, 22 Jun 2007, Jan Engelhardt wrote:
V4L_USB_DRIVERS=y turns USB into =y? That can't be. It should give the this
depends on another symbol [USB] that is modular.
That's not how it works, the enclosed symbols depend now on
V4L_USB_DRIVERS, which is a boolean and it can only have two
likely don't want a radio
driver...
bye, Roman
Reset generates values only if Kconfig and .config agree.
Signed-off-by: Roman Zippel [EMAIL PROTECTED]
---
scripts/kconfig/confdata.c | 37 ++---
1 file changed, 26 insertions(+), 11 deletions(-)
Index: linux-2.6
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
given menuconfig FOO depends on BAR, then all the config BAZs
inside this menuconfig also automatically depend on BAR too.
This is simpler in the long run because it requires least amount
(actually none) of redundant typing
I don't like this, as
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
menuconfig is really a type of config symbol, rather than a type of menu.
Well, I'd have to disagree here. A config symbol has code associated
with it (at least _all_ config symbols in the kernel originally did, till
when these menuconfig
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
1. Kconfig symbols will always have code associated with them.
That's the entire purpose of Kconfig, is it not?
A possible counter example: CONFIG_SCSI.
(RAID_ATTRS is currently a little misplaced).
It's optional for any config symbol to have any
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
Yup, so how / why am I wrong? I was making the point that a
menuconfig does not have code associated with it.
Which is wrong, it's not and will not be limited to this.
bye, Roman
-
To unsubscribe from this list: send the line unsubscribe
Hi,
On Sat, 23 Jun 2007, Satyam Sharma wrote:
But why? Let it do just one thing, and do it well. Is their
any requirement anywhere that requires us to give a dual
meaning to these menuconfig objects -- i.e. to also control
the inclusion / exclusion of code from the kernel as well as
also
ig.
Um, I thought it had been fixed already. (I'm a little busy with other
things at the moment.)
> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Acked-by: Roman Zippel <[EMAIL PROTECTED]>
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel&q
already. (I'm a little busy with other
things at the moment.)
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
Acked-by: Roman Zippel [EMAIL PROTECTED]
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
Hi,
On Mon, 21 May 2007, Sam Ravnborg wrote:
> > A simple example would be
> > help texts, right now they are per symbol, but they should really be per
> > menu, so archs can provide different help texts for something.
>
> This one turned out easy.
> I assume what you had in mind was
casts, so gcc can do better
register allocation and generate better code.
bye, Roman
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
include/asm-generic/div64.h | 14 ++
include/asm-i386/div64.h| 20
include/linux/calc64.h | 28 ++
allocation and generate better code.
bye, Roman
Signed-off-by: Roman Zippel [EMAIL PROTECTED]
---
include/asm-generic/div64.h | 14 ++
include/asm-i386/div64.h| 20
include/linux/calc64.h | 28
kernel/time.c
Hi,
On Mon, 21 May 2007, Sam Ravnborg wrote:
A simple example would be
help texts, right now they are per symbol, but they should really be per
menu, so archs can provide different help texts for something.
This one turned out easy.
I assume what you had in mind was something like
Hi,
On Mon, 21 May 2007, Thomas Gleixner wrote:
> diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
> index cb25649..bb1bf86 100644
> --- a/kernel/time/ntp.c
> +++ b/kernel/time/ntp.c
> @@ -304,10 +304,12 @@ int do_adjtimex(struct timex *txc)
> temp64 = time_offset <<
Hi,
On Mon, 21 May 2007, Thomas Gleixner wrote:
diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index cb25649..bb1bf86 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -304,10 +304,12 @@ int do_adjtimex(struct timex *txc)
temp64 = time_offset (SHIFT_NSEC
Hi,
On Sun, 20 May 2007, Andrew Morton wrote:
> On Sun, 20 May 2007 13:08:15 +0200 Elimar Riesebieter <[EMAIL PROTECTED]>
> wrote:
>
> > FYI, building 2.6.22-rc2 with
> > gcc (GCC) 4.1.3 20070514 (prerelease) (Debian 4.1.2-7)
> > on my powerbook (PPC) gives:
> >
> > ...
> > kernel/time/ntp.c:
Hi,
On Sun, 20 May 2007, Sam Ravnborg wrote:
> I did a quick hack so kconfig could scan all Kconfig files
> in the kernel tree.
> By scanning all Kconfig files we gain the following:
>
> -> kconfig can report when a depends on refer to an undefined symbol
> -> kconfig can report when a select
Hi,
On Sat, 19 May 2007, Sam Ravnborg wrote:
> We see a lot of these lately:
> GEN /home/bor/build/linux-2.6.22/Makefile
> scripts/kconfig/conf -s arch/i386/Kconfig
> drivers/macintosh/Kconfig:116:warning: 'select' used by config symbol
> 'PMAC_APM_EMU' refers to undefined symbol
Hi,
On Sat, 19 May 2007, Sam Ravnborg wrote:
We see a lot of these lately:
GEN /home/bor/build/linux-2.6.22/Makefile
scripts/kconfig/conf -s arch/i386/Kconfig
drivers/macintosh/Kconfig:116:warning: 'select' used by config symbol
'PMAC_APM_EMU' refers to undefined symbol
Hi,
On Sun, 20 May 2007, Sam Ravnborg wrote:
I did a quick hack so kconfig could scan all Kconfig files
in the kernel tree.
By scanning all Kconfig files we gain the following:
- kconfig can report when a depends on refer to an undefined symbol
- kconfig can report when a select refer to
Hi,
On Sun, 20 May 2007, Andrew Morton wrote:
On Sun, 20 May 2007 13:08:15 +0200 Elimar Riesebieter [EMAIL PROTECTED]
wrote:
FYI, building 2.6.22-rc2 with
gcc (GCC) 4.1.3 20070514 (prerelease) (Debian 4.1.2-7)
on my powerbook (PPC) gives:
...
kernel/time/ntp.c: In function
Hi,
On Wed, 16 May 2007, Al Viro wrote:
> On Tue, May 15, 2007 at 08:36:20PM +0100, Al Viro wrote:
> >
> > stuff that does select USB should depend on USB_ARCH_HAS_HCD, or we'll
> > end up with unbuildable configs.
>
> BTW, this kind of situation happens often enough, so how about doing
> the
Hi,
On Wed, 16 May 2007, Al Viro wrote:
On Tue, May 15, 2007 at 08:36:20PM +0100, Al Viro wrote:
stuff that does select USB should depend on USB_ARCH_HAS_HCD, or we'll
end up with unbuildable configs.
BTW, this kind of situation happens often enough, so how about doing
the following:
Hi,
On Mon, 7 May 2007, Sam Ravnborg wrote:
> We need to point out _one_ of the faulty spots only.
The problem is you print only a random spot (which may not even be right
one) of one of the involved symbols.
We could actually print out the whole faulty chain, but it would require a
few
Hi,
On Mon, 7 May 2007, Jeff Garzik wrote:
> Tough, the kernel community has voted against you.
>
> It makes far more sense to include a driver during kernel configuration, and
> have that driver pull in its libraries via 'select'. The lame alternative
> requires developers to know which
Hi,
On Mon, 7 May 2007, Krzysztof Halasa wrote:
> Roman Zippel <[EMAIL PROTECTED]> writes:
>
> > HDLC doesn't really look like simple library code, what's up with all the
> > HDLC_* options?
>
> Sub-modules.
So it's not simple library code, or is it?
> A
Hi,
On Mon, 7 May 2007, Jeff Garzik wrote:
> > select seriously screws with the dependencies, it's especially problematic
> > if the selected symbol has other dependencies as HDLC in this case, it makes
> > it only more complicated to get the dependencies correct again.
> > Please use it only if
Hi,
On Mon, 7 May 2007, Krzysztof Halasa wrote:
> Actually I can't see any bad idea here.
> The original dependency was certainly, uhm, not the best one.
select seriously screws with the dependencies, it's especially problematic
if the selected symbol has other dependencies as HDLC in this
Hi,
On Mon, 7 May 2007, Krzysztof Halasa wrote:
> Roman Zippel <[EMAIL PROTECTED]> writes:
>
> > What's the advantage? The HDLC option is directly before this?
>
> You don't have to know it's required, you can just select a driver
> for your hardware,
Hi,
On Mon, 7 May 2007, Krzysztof Halasa wrote:
Roman Zippel [EMAIL PROTECTED] writes:
HDLC doesn't really look like simple library code, what's up with all the
HDLC_* options?
Sub-modules.
So it's not simple library code, or is it?
Anyway, what does the patch screw exactly
Hi,
On Mon, 7 May 2007, Jeff Garzik wrote:
Tough, the kernel community has voted against you.
It makes far more sense to include a driver during kernel configuration, and
have that driver pull in its libraries via 'select'. The lame alternative
requires developers to know which libraries
Hi,
On Mon, 7 May 2007, Sam Ravnborg wrote:
We need to point out _one_ of the faulty spots only.
The problem is you print only a random spot (which may not even be right
one) of one of the involved symbols.
We could actually print out the whole faulty chain, but it would require a
few
Hi,
On Mon, 7 May 2007, Krzysztof Halasa wrote:
Roman Zippel [EMAIL PROTECTED] writes:
What's the advantage? The HDLC option is directly before this?
You don't have to know it's required, you can just select a driver
for your hardware, without enabling HDLC first.
Is this a real
Hi,
On Mon, 7 May 2007, Krzysztof Halasa wrote:
Actually I can't see any bad idea here.
The original dependency was certainly, uhm, not the best one.
select seriously screws with the dependencies, it's especially problematic
if the selected symbol has other dependencies as HDLC in this case,
Hi,
On Mon, 7 May 2007, Jeff Garzik wrote:
select seriously screws with the dependencies, it's especially problematic
if the selected symbol has other dependencies as HDLC in this case, it makes
it only more complicated to get the dependencies correct again.
Please use it only if it
Hi,
On Mon, 7 May 2007, Krzysztof Halasa wrote:
> Allow enabling WAN drivers without selecting generic HDLC first,
> HDLC will be selected automatically.
>
> Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]>
>
> diff --git a/drivers/net/wan/Kconfig b/drivers/net/wan/Kconfig
> index
Hi,
On Sun, 6 May 2007, Sam Ravnborg wrote:
> if (sym->flags & SYMBOL_CHECK) {
> - printf("Warning! Found recursive dependency: %s", sym->name);
> + fprintf(stderr, "%s:%d:error: found recursive dependency: %s",
> + sym->prop->file->name,
Hi,
On Sun, 6 May 2007, Geert Uytterhoeven wrote:
> The recent cleanup uncovered that include/asm-m68k/scatterlist.h
> needs to include
>
> Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
> ---
> include/asm-m68k/scatterlist.h |2 ++
> 1 file changed, 2 insertions(+)
>
> ---
Hi,
On Sun, 6 May 2007, Geert Uytterhoeven wrote:
The recent linux/pci.h cleanup uncovered that include/asm-m68k/scatterlist.h
needs to include asm/types.h
Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED]
---
include/asm-m68k/scatterlist.h |2 ++
1 file changed, 2 insertions(+)
Hi,
On Sun, 6 May 2007, Sam Ravnborg wrote:
if (sym-flags SYMBOL_CHECK) {
- printf(Warning! Found recursive dependency: %s, sym-name);
+ fprintf(stderr, %s:%d:error: found recursive dependency: %s,
+ sym-prop-file-name, sym-prop-lineno,
Hi,
On Mon, 7 May 2007, Krzysztof Halasa wrote:
Allow enabling WAN drivers without selecting generic HDLC first,
HDLC will be selected automatically.
Signed-off-by: Krzysztof Halasa [EMAIL PROTECTED]
diff --git a/drivers/net/wan/Kconfig b/drivers/net/wan/Kconfig
index 8897f53..3a2fe82
Hi,
On Thu, 3 May 2007, Sam Ravnborg wrote:
> Please include Roman Zippel when you propose kconfig changes.
Thanks, the lkml volume lately forces me to skip a lot, so it's quite
possible I miss something. :)
> > xconfig has the menu tree display in the left panel, where on
301 - 400 of 1055 matches
Mail list logo
