Hi,
On Tuesday 02 January 2007 21:50, john stultz wrote:
> > > It should be called every NTP_INTERVAL_FREQ times, but occasionally
> > > it's off
>
> Wait, so second_overflow should be called every NTP_INTERVAL_FREQ times
> (instead of every second)? Surely that's not right.
But it is, that's th
Hi,
On Thu, 4 Jan 2007, Al Viro wrote:
> PS: what would be the sane strategy for timer series merge, BTW?
PPS: I still don't like it. It fixes a rather theoretical problem with
absolutely no practical relevance.
PPPS: type safety is also possible with container_of(), the prototype
patch below
Hi,
On Saturday 06 January 2007 12:44, Cyrill V. Gorcunov wrote:
> I found qconf have a few malloc(), strdup() without any check for NULL
> returned code. May be it should be fixed? Am I wrong?
The code isn't really supposed to deal with it, at most they could be replaced
with a variant that pr
29 16:48:09 2006 -0800
[PATCH] fix mrproper incompleteness
The patch below reverts pretty much everything and instead introduces a
seperate format string for proc.
bye, Roman
[PATCH] fix linux banner format string
Revert previous attempts at messing with the linux banner string and
si
Hi,
On Wed, 10 Jan 2007, Bernhard Schiffner wrote:
> trying to find reasons for some crazy ntpd-behavior I read
> http://lkml.org/lkml/2006/10/27/67
>
> This thread doesn't result in a pulished patch, so I (hopefully) did what was
> said there. The patch doesn't break my system, but it doesn't
Hi,
On Wed, 10 Jan 2007, Linus Torvalds wrote:
> This part:
>
> const char __init linux_banner[] =
>
> CANNOT work, because the stupid SuSE tool that look into the kernel binary
> searches for "Linux version " as the thing, and as such the "linux_banner"
> has to be the _first_ thing to
Hi,
On Mon, 27 Nov 2006, Lukasz Stelmach wrote:
> Greetings.
>
> It seems that someone has broken *conf programs in 2.6.18 because
Unmodified 2.6.18?
> only "make silentoldconfig" recreates autoconf.h and auto.conf
> properly after configuration (.config) has changed.
That's correct. The othe
Hi,
On Wed, 29 Nov 2006, Ben Collins wrote:
> If HVC_CONSOLE provides symbols that HVCS requires.
>
> Signed-off-by: Ben Collins <[EMAIL PROTECTED]>
> ---
> drivers/char/Kconfig |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/char/Kconfig b/drivers/char/Kc
rs/input/keyboard/Kconfig
> so it's always seen by Kconfig.
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 unsu
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
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
hout selecting a V4L
> driver.
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 +
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 like
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 "menuconfi
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 linu
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
> als
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 M
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
d-off-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 |
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
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
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 unsubs
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
> f
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 c
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
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, 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
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 dr
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 Fri, 13 Jul 2007, Mike Galbraith wrote:
> > The new scheduler does _a_lot_ of heavy 64 bit calculations without any
> > attempt to scale that down a little...
>
> See prio_to_weight[], prio_to_wmult[] and sysctl_sched_stat_granularity.
> Perhaps more can be done, but "without any attempt
Hi,
On Mon, 16 Jul 2007, Ingo Molnar wrote:
> yes, the weight multiplier 1.25, but the actual difference in CPU
> utilization, when running two CPU intense tasks, is ~10%:
>
> PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
> 8246 mingo 20 0 1576 244 196 R 55 0
Hi,
On Sun, 15 Jul 2007, Jonathan Corbet wrote:
> Here's another approach: a reimplementation of msleep() and
> msleep_interruptible() using hrtimers. On a system without real
> hrtimers this code will at least drop down to single-jiffy delays much
> of the time (though not deterministically so)
Hi,
On Mon, 16 Jul 2007, Ingo Molnar wrote:
> i dont think there's any significant overhead. The OLPC folks are pretty
> sensitive to performance,
How is a sleep function relevant to performace?
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Hi,
On Mon, 16 Jul 2007, Ingo Molnar wrote:
> > As soon as you add another loop the difference changes again, while
> > it's always correct to say it gets 25% more cpu time [...]
>
> yep, and i'll add the relative effect to the comment too.
Why did you cut off the rest of the sentence?
To illu
Hi,
On Mon, 16 Jul 2007, Ingo Molnar wrote:
> i'm not sure how your question relates/connects to what i wrote above,
> could you please re-phrase your question into a bit more verbose form so
> that i can answer it? Thanks,
Well, you cut out the major question from my initial mail:
One questio
Hi,
On Mon, 16 Jul 2007, Ingo Molnar wrote:
> > > > As soon as you add another loop the difference changes again,
> > > > while it's always correct to say it gets 25% more cpu time [...]
> > >
> > > yep, and i'll add the relative effect to the comment too.
> >
> > Why did you cut off the rest
Hi,
On Mon, 16 Jul 2007, Ingo Molnar wrote:
> > Well, you cut out the major question from my initial mail:
> > One question here would be, is it really a problem to sleep a little more?
>
> oh, i did not want to embarrass you (and distract the discussion) with
> answering a pretty stupid, irrel
Hi,
On Mon, 16 Jul 2007, Ingo Molnar wrote:
> to sum it up: a nice +19 task (the most commonly used nice level in
> practice) gets 9.1%, 3.9%, 3.1% of CPU time on the old scheduler,
> depending on the value of HZ. This is quite inconsistent and illogical.
You're correct that you can find artif
Hi,
On Sun, 15 Jul 2007, Jonathan Corbet wrote:
> The OLPC folks and I recently discovered something interesting: on a
> HZ=100 system, a call to msleep(1) will delay for about 20ms. The
> combination of jiffies timekeeping and rounding up means that the
> minimum delay from msleep will be two j
Hi,
On Mon, 16 Jul 2007, Ingo Molnar wrote:
> because when i assumed the obvious, you called it an
> insult so please dont leave any room for assumptions and remove any
> ambiguity - especially as our communication seems to be marred by what
> appears to be frequent misunderstandings ;-)
What
Hi,
On Mon, 16 Jul 2007, Jonathan Corbet wrote:
> > One possible problem here is that setting up that timer can be
> > considerably more expensive, for a relative timer you have to read the
> > current time, which can be quite expensive (e.g. your machine now uses the
> > PIT timer, because TS
Hi,
On Mon, 16 Jul 2007, Ingo Molnar wrote:
> I explained it numerous times (remember the 'timeout' vs. 'timer event'
> discussion?) that i consider timer granularity important to scalability.
> Basically, in every case where we know with great certainty that a
> time-out will _not_ occur (whe
Hi,
On Mon, 16 Jul 2007, Linus Torvalds wrote:
> How about trying a much less aggressive nice-level (and preferably linear,
> not exponential)?
I think the exponential increase isn't the problem. The old code did
approximate something like this rather crudely with the result that there
was a
Hi,
On Mon, 16 Jul 2007, Matt Mackall wrote:
> > It's nice that these artifacts are gone, but that still doesn't explain
> > why this ratio had to be increase that much from around 1:10 to 1:69.
>
> More dynamic range is better? If you actually want a task to get 20x
> the CPU time of another,
Hi,
On Mon, 16 Jul 2007, Ingo Molnar wrote:
> and note that even on the old scheduler, nice-0 was "3200% more
> powerful" than nice +19 (with CONFIG_HZ=300),
How did you get that value? At any HZ the ratio should be around 1:10
(+- rounding error).
> in fact i like it that nice -20 has a sligh
Hi,
On Tue, 17 Jul 2007, Ingo Molnar wrote:
> * Roman Zippel <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > On Mon, 16 Jul 2007, Ingo Molnar wrote:
> >
> > > and note that even on the old scheduler, nice-0 was "3200% more
> > > powerfu
Hi,
On Tue, 17 Jul 2007, I wrote:
> Playing around with some other nice levels, confirms the theory that
> something is a little off, so I'm quite correct at saying that the ratio
> _should_ be 1:10.
Rechecking everything there was actually a small error in my test program,
so the ratio shoul
Hi,
On Tue, 17 Jul 2007, Ingo Molnar wrote:
> Roman, please do me a favor, and ask me the following question:
>
> " Ingo, you've been maintaining the scheduler for years. In fact you
>wrote the old nice code we are talking about here. You changed it a
>number of times since then. So yo
Hi,
On Tue, 17 Jul 2007, Ingo Molnar wrote:
> * Roman Zippel <[EMAIL PROTECTED]> wrote:
>
> > > > It's nice that these artifacts are gone, but that still doesn't
> > > > explain why this ratio had to be increase that much from around
> >
Hi,
On Wed, 18 Jul 2007, Ingo Molnar wrote:
> > > Roman, please do me a favor, and ask me the following question:
> > >
> > > [insult deleted]
> In this discussion about
> nice levels you were (very) agressively asserting things that were
> untrue,
Instead of simply asserting things, how a
Hi,
On Wed, 18 Jul 2007, Peter Zijlstra wrote:
> I actually like the extra range, it allows for a much softer punch of
> background tasks even on somewhat slower boxen.
The extra range is not really a problem, in
http://www.ussg.iu.edu/hypermail/linux/kernel/0707.2/0850.html
I suggested how w
Hi,
On Wed, 18 Jul 2007, Peter Zijlstra wrote:
> By breaking the UNIX model of nice levels. Not an option in my book.
Breaking user expectations of nice levels is?
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Hi,
On Wed, 18 Jul 2007, Peter Zijlstra wrote:
> By breaking the UNIX model of nice levels. Not an option in my book.
BTW what is the "UNIX model of nice levels"?
SUS specifies the limit via NZERO, which is defined as "Minimum Acceptable
Value: 20", I can't find any information that it must be
Hi,
On Wed, 18 Jul 2007, Peter Zijlstra wrote:
> The only expectation is that a process with a lower nice level gets more
> time. Any other expectation is a bug.
Yes, users are buggy, they expect a lot of stupid things...
Is this really reason enough to break this?
What exactly is the damage if
Hi,
On Wed, 18 Jul 2007, Ingo Molnar wrote:
> _changing_ it is an option within reason, and we've done it a couple of
> times already in the past, and even within CFS (as Peter correctly
> observed) we've been through a couple of iterations already. And as i
> mentioned it before, the outer ed
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...
b
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 o
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 c
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 inclu
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
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 b
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.
Signe
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
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 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 f
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 'SYS_SUPP
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 re
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 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 << (SHIF
asm 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 +
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
Hi,
On Thu, 3 May 2007, Andrew Morton wrote:
> > This finally renames the thread_info field in task structure to stack,
> > so that the assumptions about this field are gone and archs have more
> > freedom about placing the thread_info structure.
>
> It needed this build fix:
>
> --- a/include/
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 o
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(+)
>
> --- linux-
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->pro
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..3
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 hardwar
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
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
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 librar
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 change
Hi,
On Sunday 11 March 2007 20:50, Sam Ravnborg wrote:
> + sym = sym_lookup("KERNELVERSION", 0);
> + sym_calc_value(sym);
> + size = snprintf(menu_backtitle, sizeof(menu_backtitle),
> + _("%s - Linux Kernel v%s Configuration"),
> + config_filena
Hi,
On Thursday 15 March 2007 16:19, Kumar Gala wrote:
> Guys, I was wondering if there was a way to have a fake config
> option, one that acts just like a normal config option, but doesn't
> get a #define CONFIG_ .. for it and thus can't be used in code.
>
> I explain my problem, and maybe there
Hi,
On Tue, 20 Mar 2007, Geert Uytterhoeven wrote:
> On Wed, 14 Mar 2007, Linus Torvalds wrote:
> > In many ways it would be nice if we had two different kinds of "bool": one
> > where "m" in the dependency chain means "y" is ok, and one where "m" means
> > "n".
> >
> > We used to have "dep_bo
Hi,
On Sun, 18 Mar 2007, Alexander E. Patrakov wrote:
> More details on what the patch does:
>
> * Rewords the description of CONFIG_NLS_DEFAULT, because at some point in the
> past it confused some people
> * Removes CONFIG_FAT_DEFAULT_IOCHARSET, now CONFIG_NLS_DEFAULT is used for
> this purpos
Hi,
On Thu, 22 Mar 2007, Alexander E. Patrakov wrote:
> It is exposed as a mount parameter and kernel configuration option only for
> fat and smbfs (the two filesystems that my patch touches for this matter), and
> both of these filesystems come from DOS days, where there was one codepage for
> a
Hi,
On Thu, 22 Mar 2007, Alexander E. Patrakov wrote:
> > hfs has a codepage option as well, but I don't know its default in the
> > various countries, but it could be different from DOS.
>
> Yes. Since this comes from Mac world, it definitely makes sense to add
> CONFIG_MAC_CODEPAGE_DEFAULT, th
Hi,
On Fri, 23 Mar 2007, john stultz wrote:
> @@ -314,8 +314,8 @@ #endif
> freq_adj += time_freq;
> freq_adj = min(freq_adj, (s64)MAXFREQ_NSEC);
> time_freq = max(freq_adj, (s64)-MAXFREQ_NSEC);
> - time_offset = (time_offset /
On Thu, 5 Apr 2007, Martin Bligh wrote:
> We carefully set loglevel to 7, and print the sysrq messsage
> as to what event we're doing, but we can't actually see
> the output as it sets it back before calling the handler,
> rather than after.
>
> Move the assignment down one line.
I think you h
Hi,
On Fri, 6 Apr 2007, Martin Bligh wrote:
> > I think you have to tell sysrq_handle_loglevel() about this too...
>
> Not sure why? That just changes the current loglevel, and seems
> unaffected.
Who's the last to set console_loglevel?
> I did test the patch, and it works fine.
Did you check
Hi,
On Fri, 6 Apr 2007, Roman Zippel wrote:
> > I did test the patch, and it works fine.
>
> Did you check /proc/sys/kernel/printk?
BTW for even more fun check this with "echo 4 > /proc/sys/kernel/sysrq".
bye, Roman
-
To unsubscribe from this list: send the line &quo
Hi,
On Thu, 12 Apr 2007, Christoph Hellwig wrote:
> On Wed, Apr 11, 2007 at 07:49:38PM -0700, Nate Diller wrote:
> > read_mapping_page_async() is going away, so convert its only user to
> > read_mapping_page(). This change has not been benchmarked, however, in
> > order to get real parallelism t
Hi,
On Thu, 12 Apr 2007, Egmont Koblinger wrote:
> I tried to create such a script using ideas for regexps from glibc's
> charmaps/UTF-8, but it seemed to be quite hopeless to create a small table.
> It seems that Markus probably performed some reasonal manual optimisations
> that cannot really b
Hi,
On Thu, 12 Apr 2007, Egmont Koblinger wrote:
> > Considering this possible volatility I'm not certain we really need this
> > in the kernel.
> > The other point is that I have problems imagining, that this should be
> > enough to edit random text files with a random editor without problems.
401 - 500 of 538 matches
Mail list logo
