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;
> >
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
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(-)
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_p
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 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 yo
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 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 situati
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 delet
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
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' suff
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 stil
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, b
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
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 reque
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 pr
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 th
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 li
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:
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 li
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 visib
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 repres
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 ar
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 f
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 t
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 linux-ker
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 g
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 Thu, 27 Jan 2005, Andries Brouwer wrote:
> In short - raw mode in 2.6 is badly broken.
I think not just that. The whole keyboard input layer needs some serious
review. Just the complete lack of any locking is frightening, I'd really
like to know how the input layer could become the stan
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 op
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 |
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 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
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 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
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 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 +--
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
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
&
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 in-ke
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
> somethi
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 subje
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, 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 driver
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 linux
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 dep
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 2005-01-
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 EX
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 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 exploitatio
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, 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, 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 sur
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 jus
Hi,
On Sun, 17 Jun 2001, Alexander Viro wrote:
> > typeof? It's rather popular in the kernel already. Besides, who is going to
>
> Really? 5 instances in PPC arch-specific code, 1 (absolutely gratitious)
> in drivers/mtd, 2 - in m68k (also useless), 4 - in drivers/video, 2 -
> in AFFS and 1 -
Hi,
Martin Wilck wrote:
> Hum - is there no simple way to determine whether a pointer is
> a valid pointer to something returned by __get_free_pages ()? You are
> right, S390 in particular seems to allow arbitrary addresses starting from
> 0.
M68k does so too, although the first page is never u
Hi,
In do_swap_page() we don't flush read ahead pages to memory, so the cpu
might read the wrong data into the icache. I can reproduce this on my ppc
machine and the patch below fixes this problem.
If the patch is ok, you might also want to remove the wait_on_page() since
the following lock_page(
Hi,
On Fri, 14 Jan 2005, Karim Yaghmour wrote:
> > Why should a subsystem care about the details of the buffer management?
>
> Because it wants to enforce a data format on buffer boundaries.
It's interesting to read more about ltt's requirements, but I still think
it's possible to leave this w
Hi,
On Sat, 15 Jan 2005, Karim Yaghmour wrote:
> In addition, and this is a very important issue, quite a few
> kernel developers mistook LTT for a kernel debugging tool, which
> it was never meant to be. When, in fact, if you ask those who have
> looked at using it for that purpose (try Marcelo
Hi,
On Sun, 16 Jan 2005, Karim Yaghmour wrote:
> The per-cpu buffering issue is really specific to the client. It just
> so happens that LTT creates one channel for each CPU. Not everyone
> who needs to ship lots of data to user-space needs/wants one channel
> per cpu. You could, for example, use
Hi,
On Sun, 16 Jan 2005, Karim Yaghmour wrote:
> > You can make it even simpler by dropping this completely. Every buffer is
> > simply a list of events and you can let ltt write periodically a timer
> > event. In userspace you can randomly seek at buffer boundaries and search
> > for the time
Hi,
On Mon, 17 Jan 2005, Karim Yaghmour wrote:
> > Periodically can also mean a buffer start call back from relayfs
> > (although that would mean the first entry is not guaranteed) or a
> > (per cpu) eventcnt from the subsystem. The amount of needed search would
> > be limited. The main point
Hi,
On Mon, 17 Jan 2005, Karim Yaghmour wrote:
> a) create indexes, b) reorder events, and likely c) have to rewrite
An additional comment about the order of events. What you're doing in
lockless_reserve is bogus anyway. There is no single correct time to
write into the event. By artificially
Hi,
On Mon, 17 Jan 2005, Karim Yaghmour wrote:
> With that said, I hope we've agreed that we'll have a callback for
> letting relayfs clients know that they need to write the begining of
> the buffer event. There won't be any associated reserve. Conversly,
> I hope it is not too much to ask to ha
Hi,
On Tue, 18 Jan 2005, Andreas Gruenbacher wrote:
> A user ran into the following problem: They grab a SuSE kernel-source
> package that is more recent than their running kernel. The tree under
> /usr/src/linux is unconfigured by default; there is no .config. User
> does a ``make menuconfig'',
Hi,
On Wed, 19 Jan 2005, Andreas Gruenbacher wrote:
> > > A user ran into the following problem: They grab a SuSE kernel-source
> > > package that is more recent than their running kernel. The tree under
> > > /usr/src/linux is unconfigured by default; there is no .config. User
> > > does a ``mak
Hi,
On Wed, 19 Jan 2005, Andreas Gruenbacher wrote:
> Okay, more verbose then. On your machine which is running kernel version
> x you build kernel version y. You grab the version y kernel source tree,
> let's say a vendor tree, which has meaningful default configurations in
> arch/$ARCH/defconfi
Hi,
On Thu, 20 Jan 2005, Matt Mackall wrote:
> On Thu, Jan 20, 2005 at 08:07:11PM -0800, Andrew Morton wrote:
> > Andrew Morton <[EMAIL PROTECTED]> wrote:
> > >
> > > Next suspects would be:
> > >
> > > +cleanup-vc-array-access.patch
> > > +remove-console_macrosh.patch
> > > +merge-vt_struct-
Hi,
On Fri, 21 Jan 2005, James Simmons wrote:
> Please don't remove strutc vt_struct. What should be done is that struct
> vt_struct is used to hold the data that is shared amoung all the VCs. For
> example struct consw. See we end up with something like this.
>
> struct vt_struct {
> co
Hi,
On Fri, 21 Jan 2005, Karim Yaghmour wrote:
> I should have avoided earlier confusing the use of a certain type of
> relayfs channel for a given purpose (i.e. LTT should not necessarily
> depend on the managed mode.) I believe that there is a need for
> more than one mode in relayfs independen
Hi,
On Fri, 21 Jan 2005, Andrew Morton wrote:
> Paul Mackerras <[EMAIL PROTECTED]> wrote:
> >
> > A cluster of 2^n contiguous pages
> > isn't one page by any normal definition.
>
> It is, actually, from the POV of the page allocator. It's a "higher order
> page" and is controlled by a struct p
Hi,
On Sun, 23 Jan 2005, Karim Yaghmour wrote:
> But how does relayfs organize the namespace then? What if I have
> multiple channels per CPU, each for a different type of data, will
> all channels for the same CPU be under the same directory or will
> each type of data have its own directory wit
Hi,
On Mon, 24 Jan 2005, Andrew Morton wrote:
> - On my test box there is no flashing cursor on the vga console. Known bug,
> please don't report it.
>
> Binary searching shows that the bug was introduced by
> cleanup-vc-array-access.patch but that patch is, unfortunately, huge.
I introd
release_console_sem();
vcs_remove_devfs(tty);
From: Roman Zippel <[EMAIL PROTECTED]>
The vt_struct and vc_data are always allocated together, so there is no need
for a separate vt_struct structure.
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
Signed-off-by: Andrew Mor
Hi,
On Tue, 25 Jan 2005, Pavel Fedin wrote:
> > how about just leave the characters unchanged? (remap them to the same
> > codes in Unicode).
>
> But what to do when i convert then from unicode to 8-bit iocharset?
> This can lead to that several characters in Mac charset will be
> converted t
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 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
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
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.
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
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: Rom
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
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]
> s
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, y
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 decl
Hi,
On Mon, 16 Jul 2007, Jonathan Corbet wrote:
> > That's a bit my problem - we have to consider other setups as well.
> > Is it worth converting all msleep users behind their back or should we
> > just a provide a separate function for those who care?
>
> Any additional overhead is clearly sm
Hi,
On Wed, 18 Jul 2007, Ingo Molnar wrote:
> > > [more rude insults deleted]
> > > I've been waiting for that obvious question, and i _might_ be able
> > > to answer it, but somehow it never occured to you ;-) Thanks,
>
> the ";-)" emoticon (and its contents) clearly signals this as a
> sarcas
Hi,
On Wed, 18 Jul 2007, Ingo Molnar wrote:
> > Why do you constantly stress level 19? Yes, that one is special, all
> > other positive levels were already relatively consistent.
>
> i constantly stress it for the reason i mentioned a good number of
> times: because it's by far the most common
Hi,
On Tuesday 24 July 2007, Rodolfo Giometti wrote:
> By doing:
>
> struct pps_ktime {
> __u64 sec;
> - __u32 nsec;
> + __u64 nsec;
> };
Just using __u32 for both works as well...
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Hi,
On Saturday 21 July 2007, Andrew Morton wrote:
> On Sat, 21 Jul 2007 00:58:01 +0200 Sebastian Siewior
<[EMAIL PROTECTED]> wrote:
> > Got with randconfig
>
> randconfig apparently generates impossible configs. Please always
> run `make oldconfig' after the randconfig, then do the test build.
y one choice. The patch below avoids the setting of the value here.
bye, Roman
Avoid setting the value if the symbol doesn't need to be changed or can't
be changed. Later choices may change the dependencies and thus the
possible input range.
Signed-off-by: Roman Zippel <[EMAIL
Hi,
On Friday 24 August 2007, Linus Torvalds wrote:
> Why the hell can't you just make the code sane and do what the comment
> *says* it does, and just admit that HZ has nothing what-so-ever to do with
> that thing, and then you do
>
> unsigned int sysctl_sched_granularity __read_mostly = 3
Hi,
On Fri, 31 Aug 2007, Ingo Molnar wrote:
> So the most intrusive (math) aspects of your patch have been implemented
> already for CFS (almost a month ago), in a finegrained way.
Interesting claim, please substantiate.
> Peter's patches change the CFS calculations gradually over from
> 'norm
201 - 300 of 538 matches
Mail list logo
