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:
>
> ---
Hi,
On Thu, 3 May 2007, Dmitry Torokhov wrote:
> > I never said that. Many keyboard _types_ need a separate key mapping.
> > Localization is a completely different problem (and could be solved via
> > separate localization tables).
> > Most of it can be solved in userspace and we wouldn't have
Hi,
On Thu, 3 May 2007, Dmitry Torokhov wrote:
> > I explained already at a earlier occasion, why this "generic" keycode
> > thing is broken by design, which makes connecting multiple keyboards with
> > different mappings impossible.
> >
>
> No, I don't think so. Your points were:
>
> 1) You
Hi,
On Thu, 3 May 2007, Michael Schmitz wrote:
> > > + for (i = 1; i < 0x72; i++) {
> > > + atakbd_keycode[i] = i;
> > > + set_bit(atakbd_keycode[i], atakbd_dev->keybit);
> >
> > It looks like this driver is not using standard input event codes.
Actually it
Hi,
On Wed, 2 May 2007, Andrew Morton wrote:
> On Tue, 1 May 2007 02:10:34 +0200 (CEST) Roman Zippel <[EMAIL PROTECTED]>
> wrote:
>
> > This finally renames the thread_info field in task structure to stack,
> > so that the assumptions about this field are gone and
Hi,
On Wed, 2 May 2007, Andrew Morton wrote:
On Tue, 1 May 2007 02:10:34 +0200 (CEST) Roman Zippel [EMAIL PROTECTED]
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
Hi,
On Thu, 3 May 2007, Michael Schmitz wrote:
+ for (i = 1; i 0x72; i++) {
+ atakbd_keycode[i] = i;
+ set_bit(atakbd_keycode[i], atakbd_dev-keybit);
It looks like this driver is not using standard input event codes.
Actually it does, it just sort
Hi,
On Thu, 3 May 2007, Dmitry Torokhov wrote:
I explained already at a earlier occasion, why this generic keycode
thing is broken by design, which makes connecting multiple keyboards with
different mappings impossible.
No, I don't think so. Your points were:
1) You did not want
Hi,
On Thu, 3 May 2007, Dmitry Torokhov wrote:
I never said that. Many keyboard _types_ need a separate key mapping.
Localization is a completely different problem (and could be solved via
separate localization tables).
Most of it can be solved in userspace and we wouldn't have to
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:
---
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 one can see the
overall
Hi,
On Tuesday 01 May 2007 22:49, Christoph Hellwig wrote:
> Btw, is there any chance you could update m68k to use the generic
> irq code? The only architectures that don't have a conversion
> in progress are m68k, m68knommu and arm26
I haven't looked seriously into it since it was pretty much
Hi,
On Tuesday 01 May 2007 22:49, Christoph Hellwig wrote:
Btw, is there any chance you could update m68k to use the generic
irq code? The only architectures that don't have a conversion
in progress are m68k, m68knommu and arm26
I haven't looked seriously into it since it was pretty much
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.
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
arch/h8300/kernel/asm-offsets.c |2 +-
Recently a few direct accesses to the thread_info in the task structure
snuck back, so this wraps them with the appropriate wrapper.
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
This only leaves blackfin in -mm which I'll fix separately (depending on
how quickly Andrew is with m
Hi,
This will later allow an arch to add module specific information via
linker generated tables instead of poking directly in the module object
structure.
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
include/linux/mod
Hi,
This will later allow an arch to add module specific information via
linker generated tables instead of poking directly in the module object
structure.
Signed-off-by: Roman Zippel [EMAIL PROTECTED]
Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED]
---
include/linux/module.h |3
Recently a few direct accesses to the thread_info in the task structure
snuck back, so this wraps them with the appropriate wrapper.
Signed-off-by: Roman Zippel [EMAIL PROTECTED]
---
This only leaves blackfin in -mm which I'll fix separately (depending on
how quickly Andrew is with merging
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.
Signed-off-by: Roman Zippel [EMAIL PROTECTED]
---
arch/h8300/kernel/asm-offsets.c |2 +-
arch/ia64
Hi,
On Thu, 12 Apr 2007, Egmont Koblinger wrote:
> On Thu, Apr 12, 2007 at 05:52:49PM +0200, Roman Zippel wrote:
>
> > Well, it often doesn't end there, other users may report these as bugs and
> > want to get them fixed, so we have to look ahead a little for poss
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
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
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
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 this
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 be
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.
Hi,
On Thu, 12 Apr 2007, Egmont Koblinger wrote:
On Thu, Apr 12, 2007 at 05:52:49PM +0200, Roman Zippel wrote:
Well, it often doesn't end there, other users may report these as bugs and
want to get them fixed, so we have to look ahead a little for possible
problems.
They may even
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
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
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
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 have
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 unsubscribe linux-kernel in
the body
Hi,
On Sat, 31 Mar 2007, Sam Ravnborg wrote:
> The problem is that tristate symbol represent three values.
> =n => CONFIG_SYMBOL is undefined
> =y => CONFIG_SYMBOL is defined
> =m => COMFIG_SYMBOL_MODULE is defined
>
> The function split_config does not take into account the
> different values
Hi,
On Sat, 31 Mar 2007, Sam Ravnborg wrote:
The problem is that tristate symbol represent three values.
=n = CONFIG_SYMBOL is undefined
=y = CONFIG_SYMBOL is defined
=m = COMFIG_SYMBOL_MODULE is defined
The function split_config does not take into account the
different values and
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 /
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 /
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,
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
>
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
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 purpose.
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, the
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
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_bool and dep_mbool for
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
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"),
> +
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_filename,
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_FOOBAR .. for it and thus can't be used in code.
I explain my problem, and maybe
Hi,
On Tuesday 06 March 2007 10:29, Christoph Hellwig wrote:
> PAGE_SIZE should not be available at all. Please use getpagesize()
> instead.
While I agree, NBPG is a bit of a problem, although it's only needed for aout
coredumps AFAICT, but still needed to compile e.g. gdb.
bye, Roman
-
To
Hi,
On Tuesday 06 March 2007 10:29, Christoph Hellwig wrote:
PAGE_SIZE should not be available at all. Please use getpagesize()
instead.
While I agree, NBPG is a bit of a problem, although it's only needed for aout
coredumps AFAICT, but still needed to compile e.g. gdb.
bye, Roman
-
To
Hi,
On Wednesday 21 February 2007 13:04, Rodolfo Giometti wrote:
> RFC simply doesn't consider the fact that you can have a PPS source
> __without__ a filedes connected with, and a single filedes is
> considered __always__ connected with a single PPS source.
That's not entirely true. It doesn't
Hi,
On Wednesday 21 February 2007 13:04, Rodolfo Giometti wrote:
RFC simply doesn't consider the fact that you can have a PPS source
__without__ a filedes connected with, and a single filedes is
considered __always__ connected with a single PPS source.
That's not entirely true. It doesn't
Hi,
On Fri, 16 Feb 2007, Kumar Gala wrote:
> > Could you please be more specific about the problem you're trying to
> > solve, instead of how you're trying to solve it?
> > A real example would help a lot to understand the actual problem.
>
> Sure, on powerpc for some of the embedded
Hi,
On Sun, 18 Feb 2007, Olaf Hering wrote:
> > On Fri, 16 Feb 2007, Olaf Hering wrote:
> >
> > > Pass a timestamp to kbuild via an enviroment variable.
> > >
> > > TZ=UTC BUILD_TIMESTAMP=2007-01-01 make -kj O=../O vmlinux
> > >
> > > This can be used when the kernel source is in a SCM
Hi,
On Sun, 18 Feb 2007, Olaf Hering wrote:
On Fri, 16 Feb 2007, Olaf Hering wrote:
Pass a timestamp to kbuild via an enviroment variable.
TZ=UTC BUILD_TIMESTAMP=2007-01-01 make -kj O=../O vmlinux
This can be used when the kernel source is in a SCM and uname -v
is
Hi,
On Fri, 16 Feb 2007, Kumar Gala wrote:
Could you please be more specific about the problem you're trying to
solve, instead of how you're trying to solve it?
A real example would help a lot to understand the actual problem.
Sure, on powerpc for some of the embedded sub-architectures
Hi,
On Fri, 16 Feb 2007, Olaf Hering wrote:
> Pass a timestamp to kbuild via an enviroment variable.
>
> TZ=UTC BUILD_TIMESTAMP=2007-01-01 make -kj O=../O vmlinux
>
> This can be used when the kernel source is in a SCM and uname -v
> is supposed to give the commit date and not the package
Hi,
On Sat, 17 Feb 2007, Oleg Verych wrote:
> could you make separate patch with exporting 'LANG=C' on the very
> beginning and delete all other occurrences of it? It's a C header file
> generation and afaik, it must be ASCII.
Bad idea, most user output should be localized (even if it's only
Hi,
On Sat, 17 Feb 2007, Oleg Verych wrote:
could you make separate patch with exporting 'LANG=C' on the very
beginning and delete all other occurrences of it? It's a C header file
generation and afaik, it must be ASCII.
Bad idea, most user output should be localized (even if it's only
Hi,
On Fri, 16 Feb 2007, Olaf Hering wrote:
Pass a timestamp to kbuild via an enviroment variable.
TZ=UTC BUILD_TIMESTAMP=2007-01-01 make -kj O=../O vmlinux
This can be used when the kernel source is in a SCM and uname -v
is supposed to give the commit date and not the package build
Hi,
On Thu, 15 Feb 2007, Kumar Gala wrote:
> I was wondering if there was some way to make a Kconfig menu either be just a
> menu or a choice depending on another bool being set or not.
>
> What I'm trying to accomplish is if CONFIG_ONLY_HAVE_ONE is set I want it so
> you can only select on
Hi,
On Thu, 15 Feb 2007, Kumar Gala wrote:
I was wondering if there was some way to make a Kconfig menu either be just a
menu or a choice depending on another bool being set or not.
What I'm trying to accomplish is if CONFIG_ONLY_HAVE_ONE is set I want it so
you can only select on option,
Hi,
On Thu, 15 Feb 2007, David Lang wrote:
> this issue, and these holes keep comeing up in discussions, why can't these
> holes be closed? I seem to remember seeing patches that would remove /dev/kmem
> being sent to the list, but they weren't accepted into the kernel (and I seem
> to remember
Hi,
On Thu, 15 Feb 2007, David Howells wrote:
> > This is really the weak point - it offers no advantage over an equivalent
> > implementation in user space (e.g. in the module tools). So why has to be
> > done in the kernel?
>
> Because the init_module() system call is the common point of
Hi,
On Wed, 14 Feb 2007, David Howells wrote:
> Now, this is not a complete solution by any means: the core kernel is not
> protected, and nor are /dev/mem or /dev/kmem, but it denies (or at least
> controls) one relatively simple attack vector.
This is really the weak point - it offers no
Hi,
On Wed, 14 Feb 2007, David Howells wrote:
Now, this is not a complete solution by any means: the core kernel is not
protected, and nor are /dev/mem or /dev/kmem, but it denies (or at least
controls) one relatively simple attack vector.
This is really the weak point - it offers no
Hi,
On Thu, 15 Feb 2007, David Howells wrote:
This is really the weak point - it offers no advantage over an equivalent
implementation in user space (e.g. in the module tools). So why has to be
done in the kernel?
Because the init_module() system call is the common point of module
Hi,
On Thu, 15 Feb 2007, David Lang wrote:
this issue, and these holes keep comeing up in discussions, why can't these
holes be closed? I seem to remember seeing patches that would remove /dev/kmem
being sent to the list, but they weren't accepted into the kernel (and I seem
to remember
are using this, it may not be perfect, but I think in
the end it's just a matter of taste.
bye, Roman
[PATCH] refix localversion handling
This reverts part of the localversion patch, which now already got into
git. It removes the unnecessary find call, with the simpler $(notdir ...)
fix.
Signe
patch, which now already got into
git. It removes the unnecessary find call, with the simpler $(notdir ...)
fix.
Signed-off-by: Roman Zippel [EMAIL PROTECTED]
---
Makefile | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
Index: linux-2.6/Makefile
Hi,
On Fri, 9 Feb 2007, Heiko Carstens wrote:
> And indeed all the __initdata annotated local and global variables on
> s390 are in the init.data section. So I'm wondering what this patch
> series is about. Or I must have missed something.
I think it reaches back to times when gcc 2.7.* was
Hi,
On Fri, 9 Feb 2007, Oleg Verych wrote:
> > - else if [ -x /bin/bash ]; then echo /bin/bash; \
> > - else echo sh; fi ; fi)
> > + else if [ -x /bin/bash ]; then echo /bin/bash; fi; fi)
> > +ifeq ($(CONFIG_SHELL),)
> > +$(error bash is required to build the kernel)
> > +endif
> >
Hi,
On Fri, 9 Feb 2007, Oleg Verych wrote:
- else if [ -x /bin/bash ]; then echo /bin/bash; \
- else echo sh; fi ; fi)
+ else if [ -x /bin/bash ]; then echo /bin/bash; fi; fi)
+ifeq ($(CONFIG_SHELL),)
+$(error bash is required to build the kernel)
+endif
+SHELL :=
Hi,
On Fri, 9 Feb 2007, Heiko Carstens wrote:
And indeed all the __initdata annotated local and global variables on
s390 are in the init.data section. So I'm wondering what this patch
series is about. Or I must have missed something.
I think it reaches back to times when gcc 2.7.* was still
Hi,
On Fri, 9 Feb 2007, Andreas Schwab wrote:
> Roman Zippel <[EMAIL PROTECTED]> writes:
>
> > - printf has other side effects, instead stop pretending we support
> > something else than bash
>
> printf is a much better echo, but you need to use it properly as
Hi,
On Thu, 8 Feb 2007, Linus Torvalds wrote:
> On Thu, 8 Feb 2007, Roman Zippel wrote:
>
> > I don't quite understand, the Makefile doesn't care anymore about /bin/sh
> > with this patch, the Makefile checks only for $BASH and /bin/bash
>
> Exactly.
>
> T
Hi,
On Thu, 8 Feb 2007, Linus Torvalds wrote:
> Historically, people used to do:
> - /bin/sh was the "standard shell" (bash)
> - /bin/[t]csh is what clueless weenies use for interactive work.
>
> (Yeah, I'm not a [t]csh fan ;)
>
> And you did break that.
>
> It's quite possible that all
ndentation
bye, Roman
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
Makefile |9 --
scripts/Kbuild.include | 72 -
2 files changed, 42 insertions(+), 39 deletions(-)
Index: li
Hi,
On Thu, 8 Feb 2007, Oleg Verych wrote:
> BTW, Debian shell policy is to be bashizms-clear. Purpose -- to have
> compatibility with any `sh'. Shall we?
Wrong.
http://www.debian.org/doc/debian-policy/ch-files.html#s-scripts
bye, Roman
-
To unsubscribe from this list: send the line
Hi,
On Wed, 7 Feb 2007, Andrew Morton wrote:
> I'm sitting on these:
>
> search-a-little-harder-for-mkimage.patch
> make-mkcompile_h-use-lang=c-and-lc_all=c-for-cc-v.patch
> add-mailmap-for-proper-git-shortlog-output.patch
>
Hi,
On Wed, 7 Feb 2007, Andrew Morton wrote:
I'm sitting on these:
search-a-little-harder-for-mkimage.patch
make-mkcompile_h-use-lang=c-and-lc_all=c-for-cc-v.patch
add-mailmap-for-proper-git-shortlog-output.patch
Hi,
On Thu, 8 Feb 2007, Oleg Verych wrote:
BTW, Debian shell policy is to be bashizms-clear. Purpose -- to have
compatibility with any `sh'. Shall we?
Wrong.
http://www.debian.org/doc/debian-policy/ch-files.html#s-scripts
bye, Roman
-
To unsubscribe from this list: send the line unsubscribe
bye, Roman
Signed-off-by: Roman Zippel [EMAIL PROTECTED]
---
Makefile |9 --
scripts/Kbuild.include | 72 -
2 files changed, 42 insertions(+), 39 deletions(-)
Index: linux-2.6/Makefile
Hi,
On Thu, 8 Feb 2007, Linus Torvalds wrote:
Historically, people used to do:
- /bin/sh was the standard shell (bash)
- /bin/[t]csh is what clueless weenies use for interactive work.
(Yeah, I'm not a [t]csh fan ;)
And you did break that.
It's quite possible that all modern
Hi,
On Thu, 8 Feb 2007, Linus Torvalds wrote:
On Thu, 8 Feb 2007, Roman Zippel wrote:
I don't quite understand, the Makefile doesn't care anymore about /bin/sh
with this patch, the Makefile checks only for $BASH and /bin/bash
Exactly.
The point is, neither $BASH nor /bin/bash may
Hi,
On Fri, 9 Feb 2007, Andreas Schwab wrote:
Roman Zippel [EMAIL PROTECTED] writes:
- printf has other side effects, instead stop pretending we support
something else than bash
printf is a much better echo, but you need to use it properly as well.
Either use %s to print a literal
Hi,
On Thu, 8 Feb 2007, Oleg Verych wrote:
> -- `find | sort' in localversion (i insist on split between paths and
> files)
make has dedicated functions for this.
> -- symlinks to /dev/null in option checking -- isn't it better to not
>have any (though cached) access to files on
Hi,
This reverts part of the localversion patch, which now already got into
git. It removes the unnecessary find call, with the simpler $(notdir ...)
fix.
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
Makefile | 14 --
1 file changed, 8 insertions(+), 6 del
Hi,
On Wed, 7 Feb 2007, Linus Torvalds wrote:
> So I end up in a situation where I just basically will apply the patches
> just becauseif I don't, nothing ever happens. The good news is that _once_
> I apply them, people will usually notice problems and send in fixes fairly
> quickly. But
Hi,
On Wed, 7 Feb 2007, Randy Dunlap wrote:
> > > > Linus, please revert. Thanks.
> > >
> > > Roman, while it went so fast to Linus, i didn't expect that, let me
> > > try to fix all this with this little patch.
> >
> > Sorry, it needs more changes, the patch simply wasn't ready.
>
> Can you
Hi,
On Wed, 7 Feb 2007, Oleg Verych wrote:
> > Linus, please revert. Thanks.
>
> Roman, while it went so fast to Linus, i didn't expect that, let me
> try to fix all this with this little patch.
Sorry, it needs more changes, the patch simply wasn't ready.
bye, Roman
-
To unsubscribe from
Hi,
On Wed, 7 Feb 2007, Alexey Dobriyan wrote:
> The change below is shitting i386 defconfig (as well as my usual config)
> build log with warnings:
>
> CC init/main.o
> `-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
> `-mcpu=' is deprecated. Use `-mtune=' or '-march='
Hi,
On Tue, 6 Feb 2007, Oleg Verych wrote:
> -nullstring :=
> -space := $(nullstring) # end of line
> +pattern = ".*/localversion[^~]*"
> +string = $(shell cat /dev/null \
> +`find $(objtree) $(srctree) -maxdepth 1 -regex $(pattern) | sort`)
Calling find here is overkill, if the
Hi,
On Tue, 6 Feb 2007, Oleg Verych wrote:
> -- all checks by shell united in one macro -- checker-shell;
> -- one disposable output sym. link to /dev/null per shell,
>thus no racing, `-Z' is removed;
> -- modules' build output directory is used, if supplied;
> -- every option checking
Hi,
On Tue, 6 Feb 2007, Oleg Verych wrote:
> scripts: replace gawk, head, bc with shell, update
>
> Replacing overhead of using some (external) programs
> instead of good old `sh'.
awk is indeed a bit of overkill.
>
> Cc: Roman Zippel <[EMAIL PROTECTED]>
&g
Hi,
On Tue, 6 Feb 2007, Oleg Verych wrote:
scripts: replace gawk, head, bc with shell, update
Replacing overhead of using some (external) programs
instead of good old `sh'.
awk is indeed a bit of overkill.
Cc: Roman Zippel [EMAIL PROTECTED]
Cc: Sam Ravnborg [EMAIL PROTECTED]
Cc
Hi,
On Tue, 6 Feb 2007, Oleg Verych wrote:
-- all checks by shell united in one macro -- checker-shell;
-- one disposable output sym. link to /dev/null per shell,
thus no racing, `-Z' is removed;
-- modules' build output directory is used, if supplied;
-- every option checking function
Hi,
On Tue, 6 Feb 2007, Oleg Verych wrote:
-nullstring :=
-space := $(nullstring) # end of line
+pattern = .*/localversion[^~]*
+string = $(shell cat /dev/null \
+`find $(objtree) $(srctree) -maxdepth 1 -regex $(pattern) | sort`)
Calling find here is overkill, if the same can
Hi,
On Wed, 7 Feb 2007, Alexey Dobriyan wrote:
The change below is shitting i386 defconfig (as well as my usual config)
build log with warnings:
CC init/main.o
`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
401 - 500 of 1055 matches
Mail list logo
