Hi,
On Thu, 21 Feb 2008, David Howells wrote:
> The kernel NTP code shouldn't hand 64-bit *signed* values to do_div(). Make
> it
> instead hand 64-bit unsigned values. This gets rid of a couple of warnings.
I would actually prefer to introduce an explicit API for signed 64
divides to get
Hi,
On Thu, 21 Feb 2008, john stultz wrote:
> > Again, what kind of crappy hardware do you expect? Aren't clocks supposed
> > to get better and not worse?
>
> Well, while I've seen much worse, I consider crappy hardware to be 100
> +ppm error. So if the hardware is perfect and the system
Hi,
On Thu, 21 Feb 2008, john stultz wrote:
Again, what kind of crappy hardware do you expect? Aren't clocks supposed
to get better and not worse?
Well, while I've seen much worse, I consider crappy hardware to be 100
+ppm error. So if the hardware is perfect and the system results in
Hi,
On Thu, 21 Feb 2008, David Howells wrote:
The kernel NTP code shouldn't hand 64-bit *signed* values to do_div(). Make
it
instead hand 64-bit unsigned values. This gets rid of a couple of warnings.
I would actually prefer to introduce an explicit API for signed 64
divides to get rid
ng of a large base drift and thus keeping ntpd happy.
The CLOCK_TICK_ADJUST mechanism was introduced at a time PIT was the
primary clock, but we have a varity of clock sources now, so a global PIT
specific adjustment makes little sense anymore.
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
to allow
adjusting of a large base drift and thus keeping ntpd happy.
The CLOCK_TICK_ADJUST mechanism was introduced at a time PIT was the
primary clock, but we have a varity of clock sources now, so a global PIT
specific adjustment makes little sense anymore.
Signed-off-by: Roman Zippel [EMAIL
Hi,
On Mon, 18 Feb 2008, john stultz wrote:
> If we are building a train station, and each train car is 60ft, it
> doesn't make much sense to build 1000ft stations, right? Instead you'll
> do better if you build a 1020ft station.
That would assume trains are always 60ft long, which is the basic
Hi,
On Mon, 18 Feb 2008, john stultz wrote:
If we are building a train station, and each train car is 60ft, it
doesn't make much sense to build 1000ft stations, right? Instead you'll
do better if you build a 1020ft station.
That would assume trains are always 60ft long, which is the basic
Hi,
On Wed, 13 Feb 2008, john stultz wrote:
> Oh! So your issue is that since time_freq is stored in ppm, or in effect
> a usecs per sec offset, when we add it to something other then 1 second
> we mis-apply what NTP tells us to. Is that right?
Pretty much everything is centered around that
Hi,
On Wed, 13 Feb 2008, john stultz wrote:
Oh! So your issue is that since time_freq is stored in ppm, or in effect
a usecs per sec offset, when we add it to something other then 1 second
we mis-apply what NTP tells us to. Is that right?
Pretty much everything is centered around that 1sec,
Hi,
On Wednesday 13. February 2008, Francis Moreau wrote:
> First I tried to find some documentation on the current implementation
> but haven't found any thing really usefull. Specially there's nothing about
> it in Documentation/ directory. Please correct me if I'm already wrong.
>
> Actually
Hi,
On Wednesday 13. February 2008, Sam Ravnborg wrote:
> config foo
> tristate "do you want foo?"
> depends on USB && BAR
> module
> obj-$(CONFIG_FOO) += foo.o
> foo-y := file1.o file2.o
> help
> foo will allow you to explode your PC
I'm more
Hi,
On Wednesday 13. February 2008, Francis Moreau wrote:
First I tried to find some documentation on the current implementation
but haven't found any thing really usefull. Specially there's nothing about
it in Documentation/ directory. Please correct me if I'm already wrong.
Actually I
Hi,
On Wednesday 13. February 2008, Sam Ravnborg wrote:
config foo
tristate do you want foo?
depends on USB BAR
module
obj-$(CONFIG_FOO) += foo.o
foo-y := file1.o file2.o
help
foo will allow you to explode your PC
I'm more thinking about
Hi,
On Mon, 11 Feb 2008, john stultz wrote:
> > I don't want to just send a patch, I want you to understand why your
> > approach is wrong.
>
> With all due respect, it also keeps the critique in one direction and
> makes your review less collaborative and more confrontational then I
> suspect
Hi,
On Mon, 11 Feb 2008, john stultz wrote:
I don't want to just send a patch, I want you to understand why your
approach is wrong.
With all due respect, it also keeps the critique in one direction and
makes your review less collaborative and more confrontational then I
suspect (or
Hi,
On Fri, 8 Feb 2008, john stultz wrote:
> -ENOPATCH
>
> We're taking weeks to critique fairly small bug fix. I'm sure we both
> have better things to do then continue to misunderstand each other. I'll
> do the testing and will happily ack it if it resolves the issue.
I don't want to just
Hi,
On Fri, 8 Feb 2008, john stultz wrote:
-ENOPATCH
We're taking weeks to critique fairly small bug fix. I'm sure we both
have better things to do then continue to misunderstand each other. I'll
do the testing and will happily ack it if it resolves the issue.
I don't want to just send a
Hi,
On Fri, 8 Feb 2008, Andrew Morton wrote:
> > Only now I noticed that the first patch had been merged without any
> > further question. :-(
> > What point is there in reviewing patches, if everything is merged anyway.
> > :-(
> >
>
> oops, mistake, sorry. There's plenty of time to fix it
Hi,
On Fri, 8 Feb 2008, Andrew Morton wrote:
Only now I noticed that the first patch had been merged without any
further question. :-(
What point is there in reviewing patches, if everything is merged anyway.
:-(
oops, mistake, sorry. There's plenty of time to fix it though.
It
Hi,
On Fri, 8 Feb 2008, john stultz wrote:
>
> clock = clocksource_get_next();
> - clocksource_calculate_interval(clock,
> - (unsigned long)(current_tick_length()>>TICK_LENGTH_SHIFT));
> + clocksource_calculate_interval(clock, NTP_INTERVAL_LENGTH);
>
Hi,
On Wed, 30 Jan 2008, Miklos Szeredi wrote:
> > How does this deal with certain special cases:
> > - chroot: how will mount/df only show the for chroot relevant mounts?
>
> That is a very good question. Andreas Gruenbacher had some patches
> for fixing behavior of /proc/mounts under a
Hi,
On Fri, 1 Feb 2008, John Stultz wrote:
> > CLOCK_TICK_ADJUST is based on LATCH and HZ, if the update frequency isn't
> > based on HZ, there is no point in using it!
>
> Hey Roman,
>
> Again, I'm sorry I don't seem to be following your objections. If you
> want to suggest a different patch
Hi,
On Fri, 8 Feb 2008, john stultz wrote:
clock = clocksource_get_next();
- clocksource_calculate_interval(clock,
- (unsigned long)(current_tick_length()TICK_LENGTH_SHIFT));
+ clocksource_calculate_interval(clock, NTP_INTERVAL_LENGTH);
clock-cycle_last =
Hi,
On Fri, 1 Feb 2008, John Stultz wrote:
CLOCK_TICK_ADJUST is based on LATCH and HZ, if the update frequency isn't
based on HZ, there is no point in using it!
Hey Roman,
Again, I'm sorry I don't seem to be following your objections. If you
want to suggest a different patch to fix
Hi,
On Wed, 30 Jan 2008, john stultz wrote:
> My concern is we state the accumulation interval is X ns long. Then
> current_tick_length() is to return (X + ntp_adjustment), so each
> accumulation interval we can keep track of the error and adjust our
> interval length.
>
> So if
Hi,
On Tue, 29 Jan 2008, john stultz wrote:
> +/* Because using NSEC_PER_SEC would be too easy */
> +#define NTP_INTERVAL_LENGTH
> s64)TICK_USEC*NSEC_PER_USEC*USER_HZ)+CLOCK_TICK_ADJUST)/NTP_INTERVAL_FREQ)
Why are you using USER_HZ? Did you test this with HZ!=100?
Anyway, please don't make
Hi,
On Tue, 29 Jan 2008, john stultz wrote:
+/* Because using NSEC_PER_SEC would be too easy */
+#define NTP_INTERVAL_LENGTH
s64)TICK_USEC*NSEC_PER_USEC*USER_HZ)+CLOCK_TICK_ADJUST)/NTP_INTERVAL_FREQ)
Why are you using USER_HZ? Did you test this with HZ!=100?
Anyway, please don't make
Hi,
On Wed, 30 Jan 2008, john stultz wrote:
My concern is we state the accumulation interval is X ns long. Then
current_tick_length() is to return (X + ntp_adjustment), so each
accumulation interval we can keep track of the error and adjust our
interval length.
So if
Hi,
On Thursday 24. January 2008, Miklos Szeredi wrote:
> Q: Why do we need correct option showing in /proc/mounts?
> A: We want /proc/mounts to fully replace /etc/mtab. The reasons for
>this are:
> - unprivileged mounters won't be able to update /etc/mtab
> - /etc/mtab doesn't work
Hi,
On Thursday 24. January 2008, Miklos Szeredi wrote:
Q: Why do we need correct option showing in /proc/mounts?
A: We want /proc/mounts to fully replace /etc/mtab. The reasons for
this are:
- unprivileged mounters won't be able to update /etc/mtab
- /etc/mtab doesn't work with
Hi,
On Mon, 28 Jan 2008, john stultz wrote:
> Regardless, current_tick_length() really is the base interval we're
> using in the error accumulation loop, so it seems the cleanest interface
> to use (just to avoid redundancy at least) when establishing the
> clocksource's interval length. Or do
Hi,
On Mon, 28 Jan 2008, john stultz wrote:
Regardless, current_tick_length() really is the base interval we're
using in the error accumulation loop, so it seems the cleanest interface
to use (just to avoid redundancy at least) when establishing the
clocksource's interval length. Or do you
Hi,
On Wed, 23 Jan 2008, john stultz wrote:
> This difference in calculation was causing the clocksource correction
> code to apply a correction factor to the clocksource so the two
> intervals were the same, however this results in the actual frequency of
> the clocksource to be made incorrect.
Hi,
On Wed, 23 Jan 2008, john stultz wrote:
This difference in calculation was causing the clocksource correction
code to apply a correction factor to the clocksource so the two
intervals were the same, however this results in the actual frequency of
the clocksource to be made incorrect. I
Hi,
On Wed, 16 Jan 2008, Sam Ravnborg wrote:
> But one feature I really would like to see is named chocies so we can do
> stuff like:
>
> choice X86_PROCESSOR
>
> config GENERIC_PROCESSOR
> bool "A generic X86 processor"
> endchoice
>
>
> ...
>
> choice PPC_PROCESSOR
>
> config
Hi,
On Wed, 16 Jan 2008, Jan Beulich wrote:
> now that I finally found time to look into the problems that caused the
> patch changing boolean/tristate choice behavior to be reverted I find
> that due to the way things worked in the past there are a couple of
> cases where config options not
Add the possibility to import a value from the environment into kconfig
via the option syntax. Beside flexibility this has the advantage
providing proper dependencies.
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
Documentation/kbuild/kconfig-language.txt | 21 ++
s
Use the environment option to provide the ARCH symbol.
Remove the unused KERNELVERSION symbol.
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
init/Kconfig |4
scripts/kconfig/symbol.c | 14 --
2 files changed, 4 insertions(+), 14 deletions(-)
Rename E_CHOICE to E_LIST to explicitly add support for expression
lists. Add a helper macro expr_list_for_each_sym to more easily iterate
over the list.
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
scripts/kconfig/confdata.c |8
scripts/kconfig/expr.c
Hi,
On Sun, 6 Jan 2008, Sam Ravnborg wrote:
> Please get back to me so we can finsih this patch and have it applied.
> I will split the patch in two btw.
I reworked the patch a little and split it into three.
> > + if (sym->flags & SYMBOL_AUTO)
> > + sym->flags &= ~SYMBOL_WRITE;
>
Hi,
On Sun, 6 Jan 2008, Sam Ravnborg wrote:
Please get back to me so we can finsih this patch and have it applied.
I will split the patch in two btw.
I reworked the patch a little and split it into three.
+ if (sym-flags SYMBOL_AUTO)
+ sym-flags = ~SYMBOL_WRITE;
+
Why
Rename E_CHOICE to E_LIST to explicitly add support for expression
lists. Add a helper macro expr_list_for_each_sym to more easily iterate
over the list.
Signed-off-by: Roman Zippel [EMAIL PROTECTED]
---
scripts/kconfig/confdata.c |8
scripts/kconfig/expr.c | 16
Add the possibility to import a value from the environment into kconfig
via the option syntax. Beside flexibility this has the advantage
providing proper dependencies.
Signed-off-by: Roman Zippel [EMAIL PROTECTED]
---
Documentation/kbuild/kconfig-language.txt | 21 ++
scripts
Use the environment option to provide the ARCH symbol.
Remove the unused KERNELVERSION symbol.
Signed-off-by: Roman Zippel [EMAIL PROTECTED]
---
init/Kconfig |4
scripts/kconfig/symbol.c | 14 --
2 files changed, 4 insertions(+), 14 deletions(-)
Index: linux
Hi,
On Thursday 3. January 2008, Ph. Marek wrote:
> So I took a look at "Help", and saw that blob:
>
> Selected by: NETFILTER_XT_TARGET_CONNMARK && NET && INET && NETFILTER &&
> NETFILTER_XTABLES && (IP_NF_MANGLE || IP6_NF_MANGLE) && NF_CONNTRACK
> || NETFILTER_XT_MATCH_CONNMARK && NET &&
Hi,
On Wednesday 2. January 2008, Eric Sandeen wrote:
> Roman, with this on top does it look better to you?
Looks good, thanks.
> I'll get hfsplus done in a bit.
I'm mainly concerned about brec.c/bfind.c, the patch should be pretty much
identical.
bye, Roman
--
To unsubscribe from this
Hi,
On Thursday 3. January 2008, Ph. Marek wrote:
So I took a look at Help, and saw that blob:
Selected by: NETFILTER_XT_TARGET_CONNMARK NET INET NETFILTER
NETFILTER_XTABLES (IP_NF_MANGLE || IP6_NF_MANGLE) NF_CONNTRACK
|| NETFILTER_XT_MATCH_CONNMARK NET INET NETFILTER
Hi,
On Wednesday 2. January 2008, Eric Sandeen wrote:
Roman, with this on top does it look better to you?
Looks good, thanks.
I'll get hfsplus done in a bit.
I'm mainly concerned about brec.c/bfind.c, the patch should be pretty much
identical.
bye, Roman
--
To unsubscribe from this list:
Hi,
On Monday 17 December 2007, H. Peter Anvin wrote:
> kernel/timeconst.pl | 340
I agree with Jan that it would be better to put this into scripts.
In the long term we could also detect some of the simple special cases, so we
can finally inline some of these functions again, this
Hi,
On Thursday 20 December 2007, Eric Sandeen wrote:
> Index: linux-2.6.24-rc3/fs/hfs/brec.c
> ===
> --- linux-2.6.24-rc3.orig/fs/hfs/brec.c
> +++ linux-2.6.24-rc3/fs/hfs/brec.c
> @@ -44,10 +44,21 @@ u16 hfs_brec_keylen(struct
Hi,
On Thursday 20 December 2007, Eric Sandeen wrote:
Index: linux-2.6.24-rc3/fs/hfs/brec.c
===
--- linux-2.6.24-rc3.orig/fs/hfs/brec.c
+++ linux-2.6.24-rc3/fs/hfs/brec.c
@@ -44,10 +44,21 @@ u16 hfs_brec_keylen(struct hfs_bnode
Hi,
On Monday 17 December 2007, H. Peter Anvin wrote:
kernel/timeconst.pl | 340
I agree with Jan that it would be better to put this into scripts.
In the long term we could also detect some of the simple special cases, so we
can finally inline some of these functions again, this
Hi,
On Sunday 16 December 2007, Geert Uytterhoeven wrote:
> --- a/init/main.c
> +++ b/init/main.c
> @@ -598,9 +598,9 @@ asmlinkage void __init start_kernel(void
>
> #ifdef CONFIG_BLK_DEV_INITRD
> if (initrd_start && !initrd_below_start_ok &&
> - initrd_start <
Hi,
On Sunday 16 December 2007, Geert Uytterhoeven wrote:
--- a/init/main.c
+++ b/init/main.c
@@ -598,9 +598,9 @@ asmlinkage void __init start_kernel(void
#ifdef CONFIG_BLK_DEV_INITRD
if (initrd_start !initrd_below_start_ok
- initrd_start min_low_pfn
Hi,
On Wed, 28 Nov 2007, Paul Mundt wrote:
> Adrian mentioned a few weeks ago that KCONFIG_ALLCONFIG is the way to
> go to ensure that things like allyes/allmod/allnoconfig work with a
> constrained set of symbols, with the implication that this holds
> true for randconfig as well.
BTW another
Hi,
On Wed, 28 Nov 2007, Paul Mundt wrote:
Adrian mentioned a few weeks ago that KCONFIG_ALLCONFIG is the way to
go to ensure that things like allyes/allmod/allnoconfig work with a
constrained set of symbols, with the implication that this holds
true for randconfig as well.
BTW another
Hi,
On Thu, 15 Nov 2007, Randy Dunlap wrote:
> This all began (AFAIK) because some of us want to continue to be
> able to specify ARCH={i386,x86_64} on the (make) command line --
> not by using a .config file. Taking away ARCH= on the command line
> is a regression (in some minds, at least), so
Hi,
On Fri, 16 Nov 2007, Sam Ravnborg wrote:
> 1) make all*config, randconfig, defconfig is broken on 64-bit boxes
With your approach you made it impossible to set 64BIT from all*.config,
which is the proper way to set the defaults.
> 2) A pure code refactoring patch is reverted for no obvious
Hi,
On Fri, 16 Nov 2007, Sam Ravnborg wrote:
1) make all*config, randconfig, defconfig is broken on 64-bit boxes
With your approach you made it impossible to set 64BIT from all*.config,
which is the proper way to set the defaults.
2) A pure code refactoring patch is reverted for no obvious
Hi,
On Thu, 15 Nov 2007, Randy Dunlap wrote:
This all began (AFAIK) because some of us want to continue to be
able to specify ARCH={i386,x86_64} on the (make) command line --
not by using a .config file. Taking away ARCH= on the command line
is a regression (in some minds, at least), so Sam
he kernel configuration - which
> your solution fail to do.
To make this easy I attached the patch which reverts the problematic
changes and then you only need this simple change to force the 64BIT value
for ARCH={i386,x86_64}, otherwise it's set by the user:
bye, Roman
Signed-off-by: Roman Zi
Hi,
On Thu, 15 Nov 2007, Sam Ravnborg wrote:
> > Can we please can get some consistency in this?
> > We have a .config file for a reason, what's wrong with using it?
>
> We need to set a selected few values in a few cases where we do
> not have a .config file.
> allmodconfig for x86 for
Hi,
On Thu, 15 Nov 2007, Sam Ravnborg wrote:
> > > The value can be supplied on the command-line so we need to validate
> > > input.
> >
> > Is there a need for this?
> Yes. We would like to set 64BIT or not in other than x86 cases.
> And way forward was not to override ARCH as in the x86
n doesn't depend on another (which is currently
enforced by the syntax).
bye, Roman
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
init/Kconfig |4 ++
scripts/kconfig/expr.c | 16 +-
scripts/kconfig/expr.h
-by: Roman Zippel [EMAIL PROTECTED]
---
init/Kconfig |4 ++
scripts/kconfig/expr.c | 16 +-
scripts/kconfig/expr.h |5 +--
scripts/kconfig/lkc.h|5 +++
scripts/kconfig/menu.c |7 +++-
scripts/kconfig
Hi,
On Thu, 15 Nov 2007, Sam Ravnborg wrote:
The value can be supplied on the command-line so we need to validate
input.
Is there a need for this?
Yes. We would like to set 64BIT or not in other than x86 cases.
And way forward was not to override ARCH as in the x86 case.
Can we
Hi,
On Thu, 15 Nov 2007, Sam Ravnborg wrote:
Can we please can get some consistency in this?
We have a .config file for a reason, what's wrong with using it?
We need to set a selected few values in a few cases where we do
not have a .config file.
allmodconfig for x86 for instance. We
configuration - which
your solution fail to do.
To make this easy I attached the patch which reverts the problematic
changes and then you only need this simple change to force the 64BIT value
for ARCH={i386,x86_64}, otherwise it's set by the user:
bye, Roman
Signed-off-by: Roman Zippel [EMAIL PROTECTED
Hi,
On Sat, 10 Nov 2007, Sam Ravnborg wrote:
> + if (p) {
> + char warning[100];
> + sprintf(warning, "Environment variable (%s = \"%s\")", env, p);
> + conf_filename = warning;
> + def_flags = SYMBOL_DEF << def;
> + if (def ==
Hi,
On Fri, 9 Nov 2007, Jeff Garzik wrote:
> > > I switch between other cross-compiled arches (alpha, usually) on the
> > > makefile command line
> > >
> > > Yes, I know other 32/64-bit arches require .config editing. That
> > > doesn't change the basic fact that this is a workflow regression.
Hi,
On Fri, 9 Nov 2007, Jeff Garzik wrote:
I switch between other cross-compiled arches (alpha, usually) on the
makefile command line
Yes, I know other 32/64-bit arches require .config editing. That
doesn't change the basic fact that this is a workflow regression.
Hi,
On Sat, 10 Nov 2007, Sam Ravnborg wrote:
+ if (p) {
+ char warning[100];
+ sprintf(warning, Environment variable (%s = \%s\), env, p);
+ conf_filename = warning;
+ def_flags = SYMBOL_DEF def;
+ if (def == S_DEF_USER) {
+
Hi,
On Sat, 10 Nov 2007, Sam Ravnborg wrote:
> As discussed in another thread the right thing is to add a generic solution
> to select between 32 and 64 bit - useable for powerpc, s390, ppc et al.
Could you please point me to this discussion?
Thanks.
bye, Roman
-
To unsubscribe from this list:
Hi,
On Sat, 10 Nov 2007, Sam Ravnborg wrote:
As discussed in another thread the right thing is to add a generic solution
to select between 32 and 64 bit - useable for powerpc, s390, ppc et al.
Could you please point me to this discussion?
Thanks.
bye, Roman
-
To unsubscribe from this list:
Hi,
On Thursday 01 November 2007, Ralf Baechle wrote:
> kernel/time/ntp.c contains the following piece of code:
>
> #define CLOCK_TICK_OVERFLOW (LATCH * HZ - CLOCK_TICK_RATE)
> #define CLOCK_TICK_ADJUST (((s64)CLOCK_TICK_OVERFLOW * NSEC_PER_SEC)
> / \ (s64)CLOCK_TICK_RATE)
>
> static
Hi,
On Thursday 01 November 2007, Ralf Baechle wrote:
kernel/time/ntp.c contains the following piece of code:
#define CLOCK_TICK_OVERFLOW (LATCH * HZ - CLOCK_TICK_RATE)
#define CLOCK_TICK_ADJUST (((s64)CLOCK_TICK_OVERFLOW * NSEC_PER_SEC)
/ \ (s64)CLOCK_TICK_RATE)
static void
Hi,
On Sunday 28 October 2007, Russell King wrote:
> On Sat, Oct 27, 2007 at 03:40:04PM -0700, Joe Perches wrote:
> > and forward declarations of
> >
> > struct proc_dir_entry;
> > struct file_operations;
> >
> > As a general rule, I think it better to use includes
> > than use naked forward
Hi,
On Sunday 28 October 2007, Russell King wrote:
On Sat, Oct 27, 2007 at 03:40:04PM -0700, Joe Perches wrote:
and forward declarations of
struct proc_dir_entry;
struct file_operations;
As a general rule, I think it better to use includes
than use naked forward declarations.
If
Hi,
On Thursday 25 October 2007, Sam Ravnborg wrote:
> > It's clearly invalid in that it depends on what it selects, but it should
> > just abort instead.
>
> Thanks for the report and especially for the testcase!
> I will try to look at it a bit later if noone bites me (I'm afraid not).
Well,
Hi,
On Monday 22 October 2007, Randy Dunlap wrote:
> ~
> Another common idiom that we see (and sometimes have problems
> with) is this:
>
> When B (module or subsystem) uses interfaces from A (module or
> subsystem), A can be linked
Hi,
On Sun, 28 Oct 2007, Alexey Dobriyan wrote:
> > If it's just about the type checking, something like below should pretty
> > much do the same.
>
> It won't catch, the following if both variables are unsigned long:
>
> spin_lock_irqsave(, flags);
> [stuff]
>
Hi,
On Sun, 21 Oct 2007, Alexey Dobriyan wrote:
> So far remedies were:
> a) grep(1) -- obviously fragile. I tried at some point grepping for
>spin_lock_irqsave(), found quite a few, but it became bring quickly.
> b) BUILD_BUG_ON(sizeof(flags) != sizeof(unsigned long)) -- was tried,
>
Hi,
On Sun, 21 Oct 2007, Alexey Dobriyan wrote:
So far remedies were:
a) grep(1) -- obviously fragile. I tried at some point grepping for
spin_lock_irqsave(), found quite a few, but it became bring quickly.
b) BUILD_BUG_ON(sizeof(flags) != sizeof(unsigned long)) -- was tried,
Hi,
On Sun, 28 Oct 2007, Alexey Dobriyan wrote:
If it's just about the type checking, something like below should pretty
much do the same.
It won't catch, the following if both variables are unsigned long:
spin_lock_irqsave(lock, flags);
[stuff]
Hi,
On Monday 22 October 2007, Randy Dunlap wrote:
~
Another common idiom that we see (and sometimes have problems
with) is this:
When B (module or subsystem) uses interfaces from A (module or
subsystem), A can be linked
Hi,
On Thursday 25 October 2007, Sam Ravnborg wrote:
It's clearly invalid in that it depends on what it selects, but it should
just abort instead.
Thanks for the report and especially for the testcase!
I will try to look at it a bit later if noone bites me (I'm afraid not).
Well, you're
Hi,
On Sat, 13 Oct 2007, Geert Uytterhoeven wrote:
> m68k: ignore restart_syscall, which is not needed on m68k.
It's somewhat needed, but nobody has gotten around to actually implement
it yet...
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
Hi,
On Sat, 13 Oct 2007, Geert Uytterhoeven wrote:
m68k: ignore restart_syscall, which is not needed on m68k.
It's somewhat needed, but nobody has gotten around to actually implement
it yet...
bye, Roman
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
Hi,
On Mon, 1 Oct 2007, Oleg Verych wrote:
> Today's kconfig was proposed and accepted in a very unpleasant
> circumstances, has very poor design, development and no working
> alternative (for 5+ years now).
If you want to make such statements, you have to offer a little more than
the hot air
Hi,
On Thu, 20 Sep 2007, Shlomi Fish wrote:
> Which specific problems do you see with the coding style of the patch? Can
> you
> comment on it?
Mostly whitespace around any braces, please keep it close to the other
source.
> > I would also prefer to move more of the search functionality
Hi,
On Thu, 20 Sep 2007, Shlomi Fish wrote:
Which specific problems do you see with the coding style of the patch? Can
you
comment on it?
Mostly whitespace around any braces, please keep it close to the other
source.
I would also prefer to move more of the search functionality into the
Hi,
On Mon, 1 Oct 2007, Oleg Verych wrote:
Today's kconfig was proposed and accepted in a very unpleasant
circumstances, has very poor design, development and no working
alternative (for 5+ years now).
If you want to make such statements, you have to offer a little more than
the hot air
Hi,
On Sun, 16 Sep 2007, Sam Ravnborg wrote:
> > On Sun, 16 Sep 2007, Sam Ravnborg wrote:
> >
> > > But can you take a look at distingushing between non-selectable options
> > > due to dependency issues and seleted-by symbols.
> >
> > Do you have an example in mind? If a symbol is not
Hi,
On Sun, 16 Sep 2007, Matej Laitl wrote:
> The v2 was maybe more intuitive, but had at least one flaw, where it claimed
> the option was selected by another, while it was in fact only made
> unchangeable by 'bool "Enable block layer" if EMBEDDED', defaulting to y.
The point is that I'm
Hi,
On Sun, 16 Sep 2007, Matej Laitl wrote:
> +tristate sym_get_minimal_value(struct symbol *sym)
> +{
> + return sym->rev_dep.tri;
> +}
> +
> +tristate sym_get_maximal_value(struct symbol *sym)
> +{
> + return sym->visible;
> +}
> +
Right now I prefer the previous version. This maximum
Hi,
On Mon, 10 Sep 2007, Jan Beulich wrote:
> --- linux-2.6.23-rc5/scripts/kconfig/menu.c 2007-09-07 16:48:23.0
> +0200
> +++ 2.6.23-rc5-tristate-choices/scripts/kconfig/menu.c2007-09-03
> 10:29:41.0 +0200
> @@ -235,16 +235,23 @@ void menu_finalize(struct menu
Hi,
On Sun, 16 Sep 2007, Sam Ravnborg wrote:
> But can you take a look at distingushing between non-selectable options
> due to dependency issues and seleted-by symbols.
Do you have an example in mind? If a symbol is not changable, but still
visible, a select is usually involved.
bye, Roman
-
his, but initially I wanted to
keep it simple. It's a compromise between overloading the user interface
with information and keeping it simple. That's the only concern I have
with it, but if everyone else likes I don't mind either. :)
> Signed-off-by: Matěj Laitl <[EMAIL PROTECTED]>
Signed-of
Hi,
On Thu, 13 Sep 2007, Shlomi Fish wrote:
> This patch adds an option to use either substring match, regular expression
> match, or keywords search in the "make xconfig" Edit->Find dialog.
>
> It also allows searching on the "help" field of the menus as well as
> the "name" of the symbol.
>
1 - 100 of 1055 matches
Mail list logo
