Re: [PATCH] Start to genericize kconfig for use by other projects.
Hi, On Wed, 11 Jul 2007, Rob Landley wrote: Replace name Linux Kernel in menuconfig with a macro (defaulting to Linux Kernel if not -Ddefined by the makefile), and remove a few unnecessary occurrences of kernel in pop-up text. Could you drop the PROJECT_NAME changes for now? The rest looks fine. I would prefer if the project would be settable via Kconfig. If you want to play with it add this to Kconfig: config PROJECT_NAME string default Linux kernel and at the end of conf_parse() you can lookup, calculate and cache the value. 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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Start to genericize kconfig for use by other projects.
Hi, On Thu, 12 Jul 2007, I wrote: On Wed, 11 Jul 2007, Rob Landley wrote: Replace name Linux Kernel in menuconfig with a macro (defaulting to Linux Kernel if not -Ddefined by the makefile), and remove a few unnecessary occurrences of kernel in pop-up text. Could you drop the PROJECT_NAME changes for now? Or at least replace it with a variable at first. 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 the FAQ at http://www.tux.org/lkml/
Re: x86 status was Re: -mm merge plans for 2.6.23
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 _a_lot_ of heavy 64 bit calculations without any attempt to scale that down a little... One can blame me now for not having it brought up earlier, but discussions with Ingo are not something I'm looking forward to. :( 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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH] LinuxPPS (with new syscalls API) - new version
Hi, On Wed, 11 Jul 2007, Lennart Sorensen wrote: > On Wed, Jul 11, 2007 at 03:18:46AM +0200, Roman Zippel wrote: > > This is really not an API that needs to deal with such large time range. > > No one will want to use PPS API to keep accurate time past 2030? Why > not? Or should we be forced to invent a new PPS API before then to fix > this one? That's not necessary. > Actually, come to think of it, is this passing a current time, or it it > passing an interval since last PPS? If it is an interval, then yes > never mind, we don't need that many seconds (usually 1 or 2 at most). > For some reason I thought this was for passing the current time of a > stamp. It's an absolute time stamp, but users of this interface are more interested in the time difference between events and how they change over time. E.g. NTP time stamps are 64bit fixed point values with a 32bit integral part. This is not an interface to read the current system time, so 32bit will continue to work. 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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH] LinuxPPS (with new syscalls API) - new version
Hi, On Wed, 11 Jul 2007, Lennart Sorensen wrote: On Wed, Jul 11, 2007 at 03:18:46AM +0200, Roman Zippel wrote: This is really not an API that needs to deal with such large time range. No one will want to use PPS API to keep accurate time past 2030? Why not? Or should we be forced to invent a new PPS API before then to fix this one? That's not necessary. Actually, come to think of it, is this passing a current time, or it it passing an interval since last PPS? If it is an interval, then yes never mind, we don't need that many seconds (usually 1 or 2 at most). For some reason I thought this was for passing the current time of a stamp. It's an absolute time stamp, but users of this interface are more interested in the time difference between events and how they change over time. E.g. NTP time stamps are 64bit fixed point values with a 32bit integral part. This is not an interface to read the current system time, so 32bit will continue to work. 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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH] LinuxPPS (with new syscalls API) - new version
Hi,
On Tuesday 10 July 2007, Lennart Sorensen wrote:
> On Sun, Jul 01, 2007 at 09:24:41PM +0200, Rodolfo Giometti wrote:
> > struct pps_timedata_s {
> >__32 sec;
> >__32 nsec;
> > }
> >
> > Ok? I think 32 bits are enought for keeping seconds... :)
>
> You want to purposely define an API that will break in 23 years (or is
> that 83 years since you made it unsigned potentially)?
This is really not an API that needs to deal with such large time range.
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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH] LinuxPPS (with new syscalls API) - new version
Hi,
On Tuesday 10 July 2007, Lennart Sorensen wrote:
On Sun, Jul 01, 2007 at 09:24:41PM +0200, Rodolfo Giometti wrote:
struct pps_timedata_s {
__32 sec;
__32 nsec;
}
Ok? I think 32 bits are enought for keeping seconds... :)
You want to purposely define an API that will break in 23 years (or is
that 83 years since you made it unsigned potentially)?
This is really not an API that needs to deal with such large time range.
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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH] NTP: remove clock_was_set() call to prevent deadlock
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. call_lock in smp_call_function() > > The only possible side effect of the removal might be, that an absolute > CLOCK_REALTIME timer fires 1 second too late, in the rare case of leap > second deletion and an absolute CLOCK_REALTIME timer which expires in > the affected time frame. It will never fire too early. That's a bit of an easy solution and doesn't fix the real problem. The clock_was_set() calls were correct, what's broken is the locking. Why wasn't that fixed instead? I would at least like to see a comment there, why these calls were removed. 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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH] NTP: remove clock_was_set() call to prevent deadlock
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. call_lock in smp_call_function() The only possible side effect of the removal might be, that an absolute CLOCK_REALTIME timer fires 1 second too late, in the rare case of leap second deletion and an absolute CLOCK_REALTIME timer which expires in the affected time frame. It will never fire too early. That's a bit of an easy solution and doesn't fix the real problem. The clock_was_set() calls were correct, what's broken is the locking. Why wasn't that fixed instead? I would at least like to see a comment there, why these calls were removed. 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 the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1
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. KCONFIG_OVERWRITECONFIG was added especially for you. :-) 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 the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1
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 appear as new should they become visible and defaults work as expected (once a value is set defaults aren't used anymore). The detection whether a value is generated or not is only based on its visibility status, which can quickly change for a lot of symbols by just removing a single line from .config or adding a dependency to Kconfig as you noticed. The patch now suppresses this logic when .config and Kconfig aren't in sync and .config needs to be updated, so that you can remove now a random value from .config and oldconfig won't reask for many other values. 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 the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1
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 appear as new should they become visible and defaults work as expected (once a value is set defaults aren't used anymore). The detection whether a value is generated or not is only based on its visibility status, which can quickly change for a lot of symbols by just removing a single line from .config or adding a dependency to Kconfig as you noticed. The patch now suppresses this logic when .config and Kconfig aren't in sync and .config needs to be updated, so that you can remove now a random value from .config and oldconfig won't reask for many other values. 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 the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1
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. KCONFIG_OVERWRITECONFIG was added especially for you. :-) 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 the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1
Hi,
On Thu, 28 Jun 2007, Andrew Morton wrote:
> So save yourself some hassle and check your .config carefully before
> building this kernel. Make sure that everything you need is still enabled.
>
> I found that manually adding "CONFIG_BLK_DEV=y" to the .config before
> running oldconfig saved a large number of config items from getting lost.
This patch should help for this, so that this isn't done when Kconfig or
.config has been changed and they are not in sync.
bye, Roman
Reset generates values only if Kconfig and .config agree.
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
scripts/kconfig/confdata.c | 37 ++---
1 file changed, 26 insertions(+), 11 deletions(-)
Index: linux-2.6/scripts/kconfig/confdata.c
===
--- linux-2.6.orig/scripts/kconfig/confdata.c
+++ linux-2.6/scripts/kconfig/confdata.c
@@ -341,27 +341,42 @@ int conf_read(const char *name)
conf_unsaved++;
/* maybe print value in verbose mode... */
sym_ok:
+ if (!sym_is_choice(sym))
+ continue;
+ /* The choice symbol only has a set value (and thus is not new)
+* if all its visible childs have values.
+*/
+ prop = sym_get_choice_prop(sym);
+ flags = sym->flags;
+ for (e = prop->expr; e; e = e->left.expr)
+ if (e->right.sym->visible != no)
+ flags &= e->right.sym->flags;
+ sym->flags &= flags | ~SYMBOL_DEF_USER;
+ }
+
+ for_all_symbols(i, sym) {
if (sym_has_value(sym) && !sym_is_choice_value(sym)) {
- if (sym->visible == no)
+ /* Reset values of generates values, so they'll appear
+* as new, if they should become visible, but that
+* doesn't quite work if the Kconfig and the saved
+* configuration disagree.
+*/
+ if (sym->visible == no && !conf_unsaved)
sym->flags &= ~SYMBOL_DEF_USER;
switch (sym->type) {
case S_STRING:
case S_INT:
case S_HEX:
- if (!sym_string_within_range(sym,
sym->def[S_DEF_USER].val))
- sym->flags &=
~(SYMBOL_VALID|SYMBOL_DEF_USER);
+ /* Reset a string value if it's out of range */
+ if (sym_string_within_range(sym,
sym->def[S_DEF_USER].val))
+ break;
+ sym->flags &= ~(SYMBOL_VALID|SYMBOL_DEF_USER);
+ conf_unsaved++;
+ break;
default:
break;
}
}
- if (!sym_is_choice(sym))
- continue;
- prop = sym_get_choice_prop(sym);
- flags = sym->flags;
- for (e = prop->expr; e; e = e->left.expr)
- if (e->right.sym->visible != no)
- flags &= e->right.sym->flags;
- sym->flags &= flags | ~SYMBOL_DEF_USER;
}
sym_add_change_count(conf_warnings || conf_unsaved);
-
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 the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6-mm1
Hi,
On Thu, 28 Jun 2007, Andrew Morton wrote:
So save yourself some hassle and check your .config carefully before
building this kernel. Make sure that everything you need is still enabled.
I found that manually adding CONFIG_BLK_DEV=y to the .config before
running oldconfig saved a large number of config items from getting lost.
This patch should help for this, so that this isn't done when Kconfig or
.config has been changed and they are not in sync.
bye, Roman
Reset generates values only if Kconfig and .config agree.
Signed-off-by: Roman Zippel [EMAIL PROTECTED]
---
scripts/kconfig/confdata.c | 37 ++---
1 file changed, 26 insertions(+), 11 deletions(-)
Index: linux-2.6/scripts/kconfig/confdata.c
===
--- linux-2.6.orig/scripts/kconfig/confdata.c
+++ linux-2.6/scripts/kconfig/confdata.c
@@ -341,27 +341,42 @@ int conf_read(const char *name)
conf_unsaved++;
/* maybe print value in verbose mode... */
sym_ok:
+ if (!sym_is_choice(sym))
+ continue;
+ /* The choice symbol only has a set value (and thus is not new)
+* if all its visible childs have values.
+*/
+ prop = sym_get_choice_prop(sym);
+ flags = sym-flags;
+ for (e = prop-expr; e; e = e-left.expr)
+ if (e-right.sym-visible != no)
+ flags = e-right.sym-flags;
+ sym-flags = flags | ~SYMBOL_DEF_USER;
+ }
+
+ for_all_symbols(i, sym) {
if (sym_has_value(sym) !sym_is_choice_value(sym)) {
- if (sym-visible == no)
+ /* Reset values of generates values, so they'll appear
+* as new, if they should become visible, but that
+* doesn't quite work if the Kconfig and the saved
+* configuration disagree.
+*/
+ if (sym-visible == no !conf_unsaved)
sym-flags = ~SYMBOL_DEF_USER;
switch (sym-type) {
case S_STRING:
case S_INT:
case S_HEX:
- if (!sym_string_within_range(sym,
sym-def[S_DEF_USER].val))
- sym-flags =
~(SYMBOL_VALID|SYMBOL_DEF_USER);
+ /* Reset a string value if it's out of range */
+ if (sym_string_within_range(sym,
sym-def[S_DEF_USER].val))
+ break;
+ sym-flags = ~(SYMBOL_VALID|SYMBOL_DEF_USER);
+ conf_unsaved++;
+ break;
default:
break;
}
}
- if (!sym_is_choice(sym))
- continue;
- prop = sym_get_choice_prop(sym);
- flags = sym-flags;
- for (e = prop-expr; e; e = e-left.expr)
- if (e-right.sym-visible != no)
- flags = e-right.sym-flags;
- sym-flags = flags | ~SYMBOL_DEF_USER;
}
sym_add_change_count(conf_warnings || conf_unsaved);
-
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 the FAQ at http://www.tux.org/lkml/
Re: [patch -mm] Make check_signature() depend on CONFIG_HAS_IOMEM
Hi, On Fri, 29 Jun 2007, Alan Cox wrote: > > > check_signature is relevant for anything with MMIO space (for example you > > > can legitimately want to check_signature a MAC68K Nubus ROM). > > > > A generic check_signature() is a little difficult if we have separate io > > functions for every bus. > > Does M68K implement iomap() and pci_iomap and friends yet ? How is that related? > check_signature has fairly few users so moving to be iomap based wouldn't > be hard if that was a problem. The other option would seem to be > bus->check_signature() ? IMO the first question would be whether that function is really this important. We can also just leave it as a PCI/ISA template and other bus specific header can implement when necessary. 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 the FAQ at http://www.tux.org/lkml/
Re: [patch -mm] Make check_signature() depend on CONFIG_HAS_IOMEM
Hi, On Thu, 28 Jun 2007, Alan Cox wrote: > > check_signature() needs readb() but with some setups (s390, m68k > > allmodconfig) > > there is no implementation of readb. This causes build errors with > > -Werror-implicit-function-declaration. > > This completely bogus. readb() should be present on M68K, fix the > platform to implement readb() for MMIO, even if your MMIO readb is a > moveb instruction. > > check_signature is relevant for anything with MMIO space (for example you > can legitimately want to check_signature a MAC68K Nubus ROM). A generic check_signature() is a little difficult if we have separate io functions for every bus. 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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cross-architecture ELF clean up
Hi, On Thu, 28 Jun 2007, Jeremy Fitzhardinge wrote: > Roman Zippel wrote: > > This could be avoided by reordering things within elf.h, but is it really > > necessary since there is no user of this right now? > > > > Well, yes, I don't have much need to include ELF headers in asm now, but I > still think its worth separating the arch-specific definitions from asm/elf.h > and all the other stuff they pull in. Specifically, the structure forward > declarations and constants have very few external dependencies, but the > structure definitions - particularly the arch-specific ones - have very wide > dependencies, which is what I'm trying to solve. Very few pieces of code care > about the arch-specific structures. The problem I have is that you want to separate _all_ constants, which doesn't really make sense to me, because many of them are useless without the correspending structures. > > module.h does indeed pull in way too much, but instead of hacking headers > > into little pieces, IMO it would be better to solve the real problem. > > > > No, that's not the real problem; its a side-effect of the real problem. The > real problem is that linux/elf.h ends up bringing in too much. Please define the problem more specific. :) > arch/powerpc, > for example, has its own stripped down copy of elf.h for bootloader stuff in > order to avoid this extra crud. The fix is to make it possible to get just > the appropriate ELF definitions without getting everything else. The bootloader is no kernel code and thus the elf header pull in a lot less: $ gcc -c foo.c -Iusr/include --trace-includes . usr/include/linux/elf.h .. usr/include/linux/types.h ... usr/include/linux/posix_types.h usr/include/linux/stddef.h usr/include/asm/posix_types.h ... usr/include/asm/types.h .. usr/include/linux/auxvec.h ... usr/include/asm/auxvec.h .. usr/include/linux/elf-em.h .. usr/include/asm/elf.h ... usr/include/asm/ptrace.h usr/include/asm/ptrace-abi.h ... usr/include/asm/user.h usr/include/asm/page.h One could remove ptrace.h but otherwise the result looks quite reasonable. > There's the secondary problem that lots of ELF stuff is copy'n'paste > duplicated across all the architectures, but all they really care about is one > of two sets of parallel definitions (32 or 64 ELF structures). That was the > secondary Some of it you could put into linux/elf, e.g.: #if ELF_CLASS == ELFCLASS32 typedef Elf32_Ehdr Elf_Ehdr; typedef Elf32_Phdr Elf_Phdr; typedef Elf32_Shdr Elf_Shdr; typedef Elf32_Sym Elf_Sym; typedef Elf32_Dyn Elf_Dyn; typedef Elf32_Rel Elf_Rel; typedef Elf32_Rela Elf_Rela; typedef Elf32_Addr Elf_Addr; #elif ELF_CLASS == ELFCLASS64 typedef Elf64_Ehdr Elf_Ehdr; typedef Elf64_Phdr Elf_Phdr; typedef Elf64_Shdr Elf_Shdr; typedef Elf64_Sym Elf_Sym; typedef Elf64_Dyn Elf_Dyn; typedef Elf64_Rel Elf_Rel; typedef Elf64_Rela Elf_Rela; typedef Elf64_Addr Elf_Addr; #else #error #endif > > I played with it a little and the patch below moves a lot stuff out of > > module.h, so this would drastically reduce the header dependencies. > > Unless there are major objections, I can test the patch a little more and > > convert the other archs. > > > > Well, it seems like a large fiddly patch which only solves part of the problem > I want to solve; actually it doesn't help me at all, but it achieves one of > the side-effects of my patch. The arch changes make it look pretty awkward to > merge. The patch does help you quite a bit, you don't have to cleanup elf.h so it's usable by the whole kernel. Only few parts now really need it and depend on it, which makes the extensive splitup unnecessary only to reduce header dependencies. 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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cross-architecture ELF clean up
Hi, On Thu, 28 Jun 2007, Jeremy Fitzhardinge wrote: Roman Zippel wrote: This could be avoided by reordering things within elf.h, but is it really necessary since there is no user of this right now? Well, yes, I don't have much need to include ELF headers in asm now, but I still think its worth separating the arch-specific definitions from asm/elf.h and all the other stuff they pull in. Specifically, the structure forward declarations and constants have very few external dependencies, but the structure definitions - particularly the arch-specific ones - have very wide dependencies, which is what I'm trying to solve. Very few pieces of code care about the arch-specific structures. The problem I have is that you want to separate _all_ constants, which doesn't really make sense to me, because many of them are useless without the correspending structures. module.h does indeed pull in way too much, but instead of hacking headers into little pieces, IMO it would be better to solve the real problem. No, that's not the real problem; its a side-effect of the real problem. The real problem is that linux/elf.h ends up bringing in too much. Please define the problem more specific. :) arch/powerpc, for example, has its own stripped down copy of elf.h for bootloader stuff in order to avoid this extra crud. The fix is to make it possible to get just the appropriate ELF definitions without getting everything else. The bootloader is no kernel code and thus the elf header pull in a lot less: $ gcc -c foo.c -Iusr/include --trace-includes . usr/include/linux/elf.h .. usr/include/linux/types.h ... usr/include/linux/posix_types.h usr/include/linux/stddef.h usr/include/asm/posix_types.h ... usr/include/asm/types.h .. usr/include/linux/auxvec.h ... usr/include/asm/auxvec.h .. usr/include/linux/elf-em.h .. usr/include/asm/elf.h ... usr/include/asm/ptrace.h usr/include/asm/ptrace-abi.h ... usr/include/asm/user.h usr/include/asm/page.h One could remove ptrace.h but otherwise the result looks quite reasonable. There's the secondary problem that lots of ELF stuff is copy'n'paste duplicated across all the architectures, but all they really care about is one of two sets of parallel definitions (32 or 64 ELF structures). That was the secondary Some of it you could put into linux/elf, e.g.: #if ELF_CLASS == ELFCLASS32 typedef Elf32_Ehdr Elf_Ehdr; typedef Elf32_Phdr Elf_Phdr; typedef Elf32_Shdr Elf_Shdr; typedef Elf32_Sym Elf_Sym; typedef Elf32_Dyn Elf_Dyn; typedef Elf32_Rel Elf_Rel; typedef Elf32_Rela Elf_Rela; typedef Elf32_Addr Elf_Addr; #elif ELF_CLASS == ELFCLASS64 typedef Elf64_Ehdr Elf_Ehdr; typedef Elf64_Phdr Elf_Phdr; typedef Elf64_Shdr Elf_Shdr; typedef Elf64_Sym Elf_Sym; typedef Elf64_Dyn Elf_Dyn; typedef Elf64_Rel Elf_Rel; typedef Elf64_Rela Elf_Rela; typedef Elf64_Addr Elf_Addr; #else #error #endif I played with it a little and the patch below moves a lot stuff out of module.h, so this would drastically reduce the header dependencies. Unless there are major objections, I can test the patch a little more and convert the other archs. Well, it seems like a large fiddly patch which only solves part of the problem I want to solve; actually it doesn't help me at all, but it achieves one of the side-effects of my patch. The arch changes make it look pretty awkward to merge. The patch does help you quite a bit, you don't have to cleanup elf.h so it's usable by the whole kernel. Only few parts now really need it and depend on it, which makes the extensive splitup unnecessary only to reduce header dependencies. 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 the FAQ at http://www.tux.org/lkml/
Re: [patch -mm] Make check_signature() depend on CONFIG_HAS_IOMEM
Hi, On Thu, 28 Jun 2007, Alan Cox wrote: check_signature() needs readb() but with some setups (s390, m68k allmodconfig) there is no implementation of readb. This causes build errors with -Werror-implicit-function-declaration. This completely bogus. readb() should be present on M68K, fix the platform to implement readb() for MMIO, even if your MMIO readb is a moveb instruction. check_signature is relevant for anything with MMIO space (for example you can legitimately want to check_signature a MAC68K Nubus ROM). A generic check_signature() is a little difficult if we have separate io functions for every bus. 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 the FAQ at http://www.tux.org/lkml/
Re: [patch -mm] Make check_signature() depend on CONFIG_HAS_IOMEM
Hi, On Fri, 29 Jun 2007, Alan Cox wrote: check_signature is relevant for anything with MMIO space (for example you can legitimately want to check_signature a MAC68K Nubus ROM). A generic check_signature() is a little difficult if we have separate io functions for every bus. Does M68K implement iomap() and pci_iomap and friends yet ? How is that related? check_signature has fairly few users so moving to be iomap based wouldn't be hard if that was a problem. The other option would seem to be bus-check_signature() ? IMO the first question would be whether that function is really this important. We can also just leave it as a PCI/ISA template and other bus specific header can implement when necessary. 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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cross-architecture ELF clean up
Hi,
On Tue, 26 Jun 2007, Jeremy Fitzhardinge wrote:
> > We have the __ASSEMBLY__ define for this, so just for asm code we don't need
> > a separate header.
> >
>
> Hm. The number of __ASSEMBLY__s end up being pretty large, and it just seemed
> cleaner to put them in separate headers.
This could be avoided by reordering things within elf.h, but is it really
necessary since there is no user of this right now?
Having actual users would help to decide how to deal with this, since e.g.
if only a few constants were needed this could also be done via
asm-offsets.h.
> > > linux/elf-decl.h- ELF type declarations, without definitions
> > > linux/elf-defn.h- ELF type definitions
> > >
> >
> > What's the point in splitting these two?
> >
>
> Because there are other headers which just need some type
> forward-declarations, and don't need the whole set of ELF types defined. In
> particular, linux/module.h - which is included all over the place in the
> kernel - needs a couple of ELF types declared, and including it all over the
> place is just a waste.
module.h does indeed pull in way too much, but instead of hacking headers
into little pieces, IMO it would be better to solve the real problem.
I played with it a little and the patch below moves a lot stuff out of
module.h, so this would drastically reduce the header dependencies.
Unless there are major objections, I can test the patch a little more and
convert the other archs.
bye, Roman
---
arch/i386/kernel/module.c| 24 +--
drivers/base/bus.c |4
include/linux/module.h | 173 ---
include/linux/moduleloader.h | 212 +-
include/linux/moduleparam.h | 22 ---
include/linux/unwind.h |4
kernel/module.c | 267 +--
kernel/params.c | 13 +-
scripts/mod/modpost.c|9 -
9 files changed, 369 insertions(+), 359 deletions(-)
Index: linux-2.6/include/linux/module.h
===
--- linux-2.6.orig/include/linux/module.h
+++ linux-2.6/include/linux/module.h
@@ -44,23 +44,6 @@ struct modversion_info
struct module;
-struct module_attribute {
-struct attribute attr;
-ssize_t (*show)(struct module_attribute *, struct module *, char *);
-ssize_t (*store)(struct module_attribute *, struct module *,
-const char *, size_t count);
- void (*setup)(struct module *, const char *);
- int (*test)(struct module *);
- void (*free)(struct module *);
-};
-
-struct module_kobject
-{
- struct kobject kobj;
- struct module *mod;
- struct kobject *drivers_dir;
-};
-
/* These are either module local, or the kernel's dummy ones. */
extern int init_module(void);
extern void cleanup_module(void);
@@ -229,95 +212,13 @@ enum module_state
MODULE_STATE_GOING,
};
-/* Similar stuff for section attributes. */
-struct module_sect_attr
-{
- struct module_attribute mattr;
- char *name;
- unsigned long address;
-};
-
-struct module_sect_attrs
-{
- struct attribute_group grp;
- int nsections;
- struct module_sect_attr attrs[0];
-};
-
-struct module_param_attrs;
-
struct module
{
enum module_state state;
- /* Member of list of modules */
- struct list_head list;
-
/* Unique handle for this module */
char name[MODULE_NAME_LEN];
- /* Sysfs stuff. */
- struct module_kobject mkobj;
- struct module_param_attrs *param_attrs;
- struct module_attribute *modinfo_attrs;
- const char *version;
- const char *srcversion;
- struct kobject *holders_dir;
-
- /* Exported symbols */
- const struct kernel_symbol *syms;
- unsigned int num_syms;
- const unsigned long *crcs;
-
- /* GPL-only exported symbols. */
- const struct kernel_symbol *gpl_syms;
- unsigned int num_gpl_syms;
- const unsigned long *gpl_crcs;
-
- /* unused exported symbols. */
- const struct kernel_symbol *unused_syms;
- unsigned int num_unused_syms;
- const unsigned long *unused_crcs;
- /* GPL-only, unused exported symbols. */
- const struct kernel_symbol *unused_gpl_syms;
- unsigned int num_unused_gpl_syms;
- const unsigned long *unused_gpl_crcs;
-
- /* symbols that will be GPL-only in the near future. */
- const struct kernel_symbol *gpl_future_syms;
- unsigned int num_gpl_future_syms;
- const unsigned long *gpl_future_crcs;
-
- /* Exception table */
- unsigned int num_exentries;
- const struct exception_table_entry *extable;
-
- /* Startup function. */
- int (*init)(void);
-
- /* If this is non-NULL, vfree after init() returns */
- void *module_init;
-
- /* Here is the actual code + data, vfree'd on unload.
Re: [PATCH] cross-architecture ELF clean up
Hi,
On Tue, 26 Jun 2007, Jeremy Fitzhardinge wrote:
We have the __ASSEMBLY__ define for this, so just for asm code we don't need
a separate header.
Hm. The number of __ASSEMBLY__s end up being pretty large, and it just seemed
cleaner to put them in separate headers.
This could be avoided by reordering things within elf.h, but is it really
necessary since there is no user of this right now?
Having actual users would help to decide how to deal with this, since e.g.
if only a few constants were needed this could also be done via
asm-offsets.h.
linux/elf-decl.h- ELF type declarations, without definitions
linux/elf-defn.h- ELF type definitions
What's the point in splitting these two?
Because there are other headers which just need some type
forward-declarations, and don't need the whole set of ELF types defined. In
particular, linux/module.h - which is included all over the place in the
kernel - needs a couple of ELF types declared, and including it all over the
place is just a waste.
module.h does indeed pull in way too much, but instead of hacking headers
into little pieces, IMO it would be better to solve the real problem.
I played with it a little and the patch below moves a lot stuff out of
module.h, so this would drastically reduce the header dependencies.
Unless there are major objections, I can test the patch a little more and
convert the other archs.
bye, Roman
---
arch/i386/kernel/module.c| 24 +--
drivers/base/bus.c |4
include/linux/module.h | 173 ---
include/linux/moduleloader.h | 212 +-
include/linux/moduleparam.h | 22 ---
include/linux/unwind.h |4
kernel/module.c | 267 +--
kernel/params.c | 13 +-
scripts/mod/modpost.c|9 -
9 files changed, 369 insertions(+), 359 deletions(-)
Index: linux-2.6/include/linux/module.h
===
--- linux-2.6.orig/include/linux/module.h
+++ linux-2.6/include/linux/module.h
@@ -44,23 +44,6 @@ struct modversion_info
struct module;
-struct module_attribute {
-struct attribute attr;
-ssize_t (*show)(struct module_attribute *, struct module *, char *);
-ssize_t (*store)(struct module_attribute *, struct module *,
-const char *, size_t count);
- void (*setup)(struct module *, const char *);
- int (*test)(struct module *);
- void (*free)(struct module *);
-};
-
-struct module_kobject
-{
- struct kobject kobj;
- struct module *mod;
- struct kobject *drivers_dir;
-};
-
/* These are either module local, or the kernel's dummy ones. */
extern int init_module(void);
extern void cleanup_module(void);
@@ -229,95 +212,13 @@ enum module_state
MODULE_STATE_GOING,
};
-/* Similar stuff for section attributes. */
-struct module_sect_attr
-{
- struct module_attribute mattr;
- char *name;
- unsigned long address;
-};
-
-struct module_sect_attrs
-{
- struct attribute_group grp;
- int nsections;
- struct module_sect_attr attrs[0];
-};
-
-struct module_param_attrs;
-
struct module
{
enum module_state state;
- /* Member of list of modules */
- struct list_head list;
-
/* Unique handle for this module */
char name[MODULE_NAME_LEN];
- /* Sysfs stuff. */
- struct module_kobject mkobj;
- struct module_param_attrs *param_attrs;
- struct module_attribute *modinfo_attrs;
- const char *version;
- const char *srcversion;
- struct kobject *holders_dir;
-
- /* Exported symbols */
- const struct kernel_symbol *syms;
- unsigned int num_syms;
- const unsigned long *crcs;
-
- /* GPL-only exported symbols. */
- const struct kernel_symbol *gpl_syms;
- unsigned int num_gpl_syms;
- const unsigned long *gpl_crcs;
-
- /* unused exported symbols. */
- const struct kernel_symbol *unused_syms;
- unsigned int num_unused_syms;
- const unsigned long *unused_crcs;
- /* GPL-only, unused exported symbols. */
- const struct kernel_symbol *unused_gpl_syms;
- unsigned int num_unused_gpl_syms;
- const unsigned long *unused_gpl_crcs;
-
- /* symbols that will be GPL-only in the near future. */
- const struct kernel_symbol *gpl_future_syms;
- unsigned int num_gpl_future_syms;
- const unsigned long *gpl_future_crcs;
-
- /* Exception table */
- unsigned int num_exentries;
- const struct exception_table_entry *extable;
-
- /* Startup function. */
- int (*init)(void);
-
- /* If this is non-NULL, vfree after init() returns */
- void *module_init;
-
- /* Here is the actual code + data, vfree'd on unload. */
- void *module_core;
Re: [patch, v2.6.22-rc6] sys_time() speedup
Hi, On Tue, 26 Jun 2007, Ingo Molnar wrote: Another BTW before someone takes this seriously: > ( whether there is any correlation between a decade long fundamental > suckage and stagnation of the Linux time and NTP subsystem and Roman's > decade long negative feedback presence in that area of code is left up > to the reader. :) That's complete bullshit. > This current ... interesting piece of Roman about a _single_ trivial > unlikely() branch in do_gettimeofday() borders on the ridiculous. My > patch might be wrong for various reasons, but that single > 'if (unlikely())' statement is not one of those reasons =B-) That's even more nonsense, that wasn't what my mail was about and Andrew understood me correctly, so you could have too. Ingo, I at least know that I'm difficult to deal with and try to take this into account, which is hard for me, but you don't even seem to know what kind of ass you are towards people who don't suck up to you (I guess you simply get away with it far too often). 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 the FAQ at http://www.tux.org/lkml/
Re: [patch, v2.6.22-rc6] sys_time() speedup
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... 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 the FAQ at http://www.tux.org/lkml/
Re: [patch, v2.6.22-rc6] sys_time() speedup
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... 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 the FAQ at http://www.tux.org/lkml/
Re: [patch, v2.6.22-rc6] sys_time() speedup
Hi, On Tue, 26 Jun 2007, Ingo Molnar wrote: Another BTW before someone takes this seriously: ( whether there is any correlation between a decade long fundamental suckage and stagnation of the Linux time and NTP subsystem and Roman's decade long negative feedback presence in that area of code is left up to the reader. :) That's complete bullshit. This current ... interesting piece of Roman about a _single_ trivial unlikely() branch in do_gettimeofday() borders on the ridiculous. My patch might be wrong for various reasons, but that single 'if (unlikely())' statement is not one of those reasons =B-) That's even more nonsense, that wasn't what my mail was about and Andrew understood me correctly, so you could have too. Ingo, I at least know that I'm difficult to deal with and try to take this into account, which is hard for me, but you don't even seem to know what kind of ass you are towards people who don't suck up to you (I guess you simply get away with it far too often). 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 the FAQ at http://www.tux.org/lkml/
Re: [patch, v2.6.22-rc6] sys_time() speedup
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 change would be useless. I don't know what clock was used in the test, so maybe it can be replaced with a faster clock. AFAICT OLTP is not really a common application for most users, so there may be other ways to optimize this special case. Just reading the patch isn't enough here, you have to look at the whole picture and some pieces are still missing... 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 the FAQ at http://www.tux.org/lkml/
Re: [patch, v2.6.22-rc6] sys_time() speedup
Hi, On Mon, 25 Jun 2007, Jesper Juhl wrote: > > On Monday 25 June 2007, Ingo Molnar wrote: > > > > > the patch improves the sysbench OLTP macrobenchmark significantly: > > > > Has that any real practical relevance? > > > It seems to me that Ingo's patch offers slightly improved performance > for any program using the time() system call, with no real drawbacks, > so why wouldn't we want to use it? How do you come to the conclusion it has no real drawbacks? Ingo provided no information about his test setup and his patch was a little strange, so I can't say that yet. 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 the FAQ at http://www.tux.org/lkml/
Re: [patch, v2.6.22-rc6] sys_time() speedup
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;
> +
> + /*
> + * Make sure xtime.tv_sec [returned by sys_time()] always
> + * follows the gettimeofday() result precisely. This
> + * condition is extremely unlikely, it can hit at most
> + * once per second:
> + */
> + if (unlikely(xtime.tv_sec != tv->tv_sec)) {
> + unsigned long flags;
> +
> + write_seqlock_irqsave(_lock);
> + update_wall_time();
> + write_seqlock_irqrestore(_lock);
> + }
> }
>
> EXPORT_SYMBOL(do_gettimeofday);
Is this the do_gettimeofday() inside CONFIG_TIME_INTERPOLATION?
What did you test?
There can be many ways to read the clock, do you want to put this hook
everywhere? Wouldn't it be better to improve the clock performance?
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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cross-architecture ELF clean up
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 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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cross-architecture ELF clean up
Hi, On Mon, 25 Jun 2007, Clemens Koller wrote: > > glibc provides its own version, so it doesn't has to be exported at all. > > AFAIK the glibc folks want to rely more on the linux kernel headers > in the future and not provide more or less redundant headers anymore... In this case it's more an ABI header, it doesn't export any kernel interfaces. 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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cross-architecture ELF clean up
Hi, On Mon, 25 Jun 2007, David Woodhouse wrote: > On Wed, 2007-06-20 at 16:08 -0700, Jeremy Fitzhardinge wrote: > > This patch cleans up the ELF headers and their users. It does several > > related things: > > Looks good. We can get away with exporting a lot less of this to > userspace too, can't we? glibc provides its own version, so it doesn't has to be exported at all. 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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cross-architecture ELF clean up
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, > functionally unchanged > linux/elf-const.h - ELF constants, includable by asm code We have the __ASSEMBLY__ define for this, so just for asm code we don't need a separate header. > linux/elf-decl.h- ELF type declarations, without definitions > linux/elf-defn.h- ELF type definitions What's the point in splitting these two? After this patch seems to be pretty much empty, I'd rather suggest to move the function declarations to elfcore.h and leave the basic elf definitions in elf.h. Many small header files have the disadvantage that it takes longer to find the needed information. 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 the FAQ at http://www.tux.org/lkml/
Re: [patch 2/2] HFS+: Add custom dentry hash and comparison operations
Hi,
On Wed, 20 Jun 2007, Duane Griffin wrote:
> Add custom dentry hash and comparison operations for HFS+ filesystems
> that are case-insensitive and/or do automatic unicode decomposition.
> The new operations reuse the existing HFS+ ASCII to unicode conversion,
> unicode decomposition and case folding functionality.
The changes in the previous patch required a few changes in this patch as
well, but there were also a few small problems. The case condition wasn't
quite correct and some characters have to be ignored during compare/hash.
bye, Roman
From: Duane Griffin <[EMAIL PROTECTED]>
Add custom dentry hash and comparison operations for HFS+ filesystems
that are case-insensitive and/or do automatic unicode decomposition.
The new operations reuse the existing HFS+ ASCII to unicode conversion,
unicode decomposition and case folding functionality.
Signed-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 |1
fs/hfsplus/unicode.c| 123
6 files changed, 138 insertions(+), 1 deletion(-)
Index: linux-2.6/fs/hfsplus/dir.c
===
--- linux-2.6.orig/fs/hfsplus/dir.c 2007-04-26 19:45:57.0 +0200
+++ linux-2.6/fs/hfsplus/dir.c 2007-06-25 13:39:46.0 +0200
@@ -36,6 +36,8 @@ static struct dentry *hfsplus_lookup(str
u16 type;
sb = dir->i_sb;
+
+ dentry->d_op = _dentry_operations;
dentry->d_fsdata = NULL;
hfs_find_init(HFSPLUS_SB(sb).cat_tree, );
hfsplus_cat_build_key(sb, fd.search_key, dir->i_ino, >d_name);
Index: linux-2.6/fs/hfsplus/hfsplus_fs.h
===
--- linux-2.6.orig/fs/hfsplus/hfsplus_fs.h 2007-04-26 19:45:57.0
+0200
+++ linux-2.6/fs/hfsplus/hfsplus_fs.h 2007-06-25 12:59:16.0 +0200
@@ -150,6 +150,7 @@ struct hfsplus_sb_info {
#define HFSPLUS_SB_NODECOMPOSE 0x0002
#define HFSPLUS_SB_FORCE 0x0004
#define HFSPLUS_SB_HFSX0x0008
+#define HFSPLUS_SB_CASEFOLD0x0010
struct hfsplus_inode_info {
@@ -321,6 +322,7 @@ void hfsplus_file_truncate(struct inode
/* inode.c */
extern const struct address_space_operations hfsplus_aops;
extern const struct address_space_operations hfsplus_btree_aops;
+extern struct dentry_operations hfsplus_dentry_operations;
void hfsplus_inode_read_fork(struct inode *, struct hfsplus_fork_raw *);
void hfsplus_inode_write_fork(struct inode *, struct hfsplus_fork_raw *);
@@ -353,6 +355,8 @@ int hfsplus_strcasecmp(const struct hfsp
int hfsplus_strcmp(const struct hfsplus_unistr *, const struct hfsplus_unistr
*);
int hfsplus_uni2asc(struct super_block *, const struct hfsplus_unistr *, char
*, int *);
int hfsplus_asc2uni(struct super_block *, struct hfsplus_unistr *, const char
*, int);
+int hfsplus_hash_dentry(struct dentry *dentry, struct qstr *str);
+int hfsplus_compare_dentry(struct dentry *dentry, struct qstr *s1, struct qstr
*s2);
/* wrapper.c */
int hfsplus_read_wrapper(struct super_block *);
Index: linux-2.6/fs/hfsplus/inode.c
===
--- linux-2.6.orig/fs/hfsplus/inode.c 2007-04-26 19:45:57.0 +0200
+++ linux-2.6/fs/hfsplus/inode.c2007-06-25 13:52:54.0 +0200
@@ -130,6 +130,11 @@ const struct address_space_operations hf
.writepages = hfsplus_writepages,
};
+struct dentry_operations hfsplus_dentry_operations = {
+ .d_hash = hfsplus_hash_dentry,
+ .d_compare= hfsplus_compare_dentry,
+};
+
static struct dentry *hfsplus_file_lookup(struct inode *dir, struct dentry
*dentry,
struct nameidata *nd)
{
Index: linux-2.6/fs/hfsplus/unicode.c
===
--- linux-2.6.orig/fs/hfsplus/unicode.c 2007-06-25 12:59:15.0 +0200
+++ linux-2.6/fs/hfsplus/unicode.c 2007-06-25 13:35:23.0 +0200
@@ -312,3 +312,126 @@ int hfsplus_asc2uni(struct super_block *
return -ENAMETOOLONG;
return 0;
}
+
+/*
+ * Hash a string to an integer as appropriate for the HFS+ filesystem.
+ * Composed unicode characters are decomposed and case-folding is performed
+ * if the appropriate bits are (un)set on the superblock.
+ */
+int hfsplus_hash_dentry(struct dentry *dentry, struct qstr *str)
+{
+ struct super_block *sb = dentry->d_sb;
+ const char *astr;
+ const u16 *dstr;
+ int casefold, decompose, size, dsize, len;
+ unsigned long hash;
+ wchar_t c;
+ u16 c2;
+
+ casefold = (HFSPLUS_SB(sb).flags & HFSPLUS_SB_CASEFOLD);
+ decompose = !(HFSPLUS_
Re: [patch 1/2] HFS+: Refactor ASCII to unicode conversion routine for later reuse
Hi,
On Wed, 20 Jun 2007, Duane Griffin wrote:
> Refactor existing HFS+ ASCII to unicode string conversion routine to
> split out character conversion functionality. This will be reused by
> the custom dentry hash and comparison routines. This approach avoids
> unnecessary memory allocation compared to using the string conversion
> routine directly in the new functions.
I like the idea of this, but not that it generates larger code, so I
reformatted it a little to get rid of the decomposed_uc struct which
required an unnecessary data copy, so now the it even generates slightly
smaller code. :)
bye, Roman
From: Duane Griffin <[EMAIL PROTECTED]>
Refactor existing HFS+ ASCII to unicode string conversion routine to
split out character conversion functionality. This will be reused by
the custom dentry hash and comparison routines. This approach avoids
unnecessary 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 file changed, 60 insertions(+), 45 deletions(-)
Index: linux-2.6/fs/hfsplus/unicode.c
===
--- linux-2.6.orig/fs/hfsplus/unicode.c
+++ linux-2.6/fs/hfsplus/unicode.c
@@ -239,58 +239,73 @@ out:
return res;
}
-int hfsplus_asc2uni(struct super_block *sb, struct hfsplus_unistr *ustr, const
char *astr, int len)
+/*
+ * Convert one or more ASCII characters into a single unicode character.
+ * Returns the number of ASCII characters corresponding to the unicode char.
+ */
+static inline int asc2unichar(struct super_block *sb, const char *astr, int
len,
+ wchar_t *uc)
{
- struct nls_table *nls = HFSPLUS_SB(sb).nls;
- int size, off, decompose;
+ int size = HFSPLUS_SB(sb).nls->char2uni(astr, len, uc);
+ if (size <= 0) {
+ *uc = '?';
+ size = 1;
+ }
+ switch (*uc) {
+ case 0x2400:
+ *uc = 0;
+ break;
+ case ':':
+ *uc = '/';
+ break;
+ }
+ return size;
+}
+
+/* Decomposes a single unicode character. */
+static inline u16 *decompose_unichar(wchar_t uc, int *size)
+{
+ int off;
+
+ off = hfsplus_decompose_table[(uc >> 12) & 0xf];
+ if (off == 0 || off == 0x)
+ return NULL;
+
+ off = hfsplus_decompose_table[off + ((uc >> 8) & 0xf)];
+ if (!off)
+ return NULL;
+
+ off = hfsplus_decompose_table[off + ((uc >> 4) & 0xf)];
+ if (!off)
+ return NULL;
+
+ off = hfsplus_decompose_table[off + (uc & 0xf)];
+ *size = off & 3;
+ return hfsplus_decompose_table + (off / 4);
+}
+
+int hfsplus_asc2uni(struct super_block *sb, struct hfsplus_unistr *ustr,
+ const char *astr, int len)
+{
+ int size, dsize, decompose;
+ u16 *dstr, outlen = 0;
wchar_t c;
- u16 outlen = 0;
decompose = !(HFSPLUS_SB(sb).flags & HFSPLUS_SB_NODECOMPOSE);
-
while (outlen < HFSPLUS_MAX_STRLEN && len > 0) {
- size = nls->char2uni(astr, len, );
- if (size <= 0) {
- c = '?';
- size = 1;
- }
- astr += size;
- len -= size;
- switch (c) {
- case 0x2400:
- c = 0;
- break;
- case ':':
- c = '/';
- break;
- }
- if (c >= 0xc0 && decompose) {
- off = hfsplus_decompose_table[(c >> 12) & 0xf];
- if (!off)
- goto done;
- if (off == 0x) {
- goto done;
- }
- off = hfsplus_decompose_table[off + ((c >> 8) & 0xf)];
- if (!off)
- goto done;
- off = hfsplus_decompose_table[off + ((c >> 4) & 0xf)];
- if (!off)
- goto done;
- off = hfsplus_decompose_table[off + (c & 0xf)];
- size = off & 3;
- if (!size)
- goto done;
- off /= 4;
- if (outlen + size > HFSPLUS_MAX_STRLEN)
+ size = asc2unichar(sb, astr, len, );
+
+ if (decompose && (dstr = decompose_unichar(c, ))) {
+ if (outlen + dsize > HFSPLUS_MAX_STRLEN)
Re: [patch 1/2] HFS+: Refactor ASCII to unicode conversion routine for later reuse
Hi,
On Wed, 20 Jun 2007, Duane Griffin wrote:
Refactor existing HFS+ ASCII to unicode string conversion routine to
split out character conversion functionality. This will be reused by
the custom dentry hash and comparison routines. This approach avoids
unnecessary memory allocation compared to using the string conversion
routine directly in the new functions.
I like the idea of this, but not that it generates larger code, so I
reformatted it a little to get rid of the decomposed_uc struct which
required an unnecessary data copy, so now the it even generates slightly
smaller code. :)
bye, Roman
From: Duane Griffin [EMAIL PROTECTED]
Refactor existing HFS+ ASCII to unicode string conversion routine to
split out character conversion functionality. This will be reused by
the custom dentry hash and comparison routines. This approach avoids
unnecessary 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 file changed, 60 insertions(+), 45 deletions(-)
Index: linux-2.6/fs/hfsplus/unicode.c
===
--- linux-2.6.orig/fs/hfsplus/unicode.c
+++ linux-2.6/fs/hfsplus/unicode.c
@@ -239,58 +239,73 @@ out:
return res;
}
-int hfsplus_asc2uni(struct super_block *sb, struct hfsplus_unistr *ustr, const
char *astr, int len)
+/*
+ * Convert one or more ASCII characters into a single unicode character.
+ * Returns the number of ASCII characters corresponding to the unicode char.
+ */
+static inline int asc2unichar(struct super_block *sb, const char *astr, int
len,
+ wchar_t *uc)
{
- struct nls_table *nls = HFSPLUS_SB(sb).nls;
- int size, off, decompose;
+ int size = HFSPLUS_SB(sb).nls-char2uni(astr, len, uc);
+ if (size = 0) {
+ *uc = '?';
+ size = 1;
+ }
+ switch (*uc) {
+ case 0x2400:
+ *uc = 0;
+ break;
+ case ':':
+ *uc = '/';
+ break;
+ }
+ return size;
+}
+
+/* Decomposes a single unicode character. */
+static inline u16 *decompose_unichar(wchar_t uc, int *size)
+{
+ int off;
+
+ off = hfsplus_decompose_table[(uc 12) 0xf];
+ if (off == 0 || off == 0x)
+ return NULL;
+
+ off = hfsplus_decompose_table[off + ((uc 8) 0xf)];
+ if (!off)
+ return NULL;
+
+ off = hfsplus_decompose_table[off + ((uc 4) 0xf)];
+ if (!off)
+ return NULL;
+
+ off = hfsplus_decompose_table[off + (uc 0xf)];
+ *size = off 3;
+ return hfsplus_decompose_table + (off / 4);
+}
+
+int hfsplus_asc2uni(struct super_block *sb, struct hfsplus_unistr *ustr,
+ const char *astr, int len)
+{
+ int size, dsize, decompose;
+ u16 *dstr, outlen = 0;
wchar_t c;
- u16 outlen = 0;
decompose = !(HFSPLUS_SB(sb).flags HFSPLUS_SB_NODECOMPOSE);
-
while (outlen HFSPLUS_MAX_STRLEN len 0) {
- size = nls-char2uni(astr, len, c);
- if (size = 0) {
- c = '?';
- size = 1;
- }
- astr += size;
- len -= size;
- switch (c) {
- case 0x2400:
- c = 0;
- break;
- case ':':
- c = '/';
- break;
- }
- if (c = 0xc0 decompose) {
- off = hfsplus_decompose_table[(c 12) 0xf];
- if (!off)
- goto done;
- if (off == 0x) {
- goto done;
- }
- off = hfsplus_decompose_table[off + ((c 8) 0xf)];
- if (!off)
- goto done;
- off = hfsplus_decompose_table[off + ((c 4) 0xf)];
- if (!off)
- goto done;
- off = hfsplus_decompose_table[off + (c 0xf)];
- size = off 3;
- if (!size)
- goto done;
- off /= 4;
- if (outlen + size HFSPLUS_MAX_STRLEN)
+ size = asc2unichar(sb, astr, len, c);
+
+ if (decompose (dstr = decompose_unichar(c, dsize))) {
+ if (outlen + dsize HFSPLUS_MAX_STRLEN)
break;
do {
- ustr-unicode[outlen++] =
cpu_to_be16(hfsplus_decompose_table[off++]);
- } while (--size 0
Re: [patch 2/2] HFS+: Add custom dentry hash and comparison operations
Hi,
On Wed, 20 Jun 2007, Duane Griffin wrote:
Add custom dentry hash and comparison operations for HFS+ filesystems
that are case-insensitive and/or do automatic unicode decomposition.
The new operations reuse the existing HFS+ ASCII to unicode conversion,
unicode decomposition and case folding functionality.
The changes in the previous patch required a few changes in this patch as
well, but there were also a few small problems. The case condition wasn't
quite correct and some characters have to be ignored during compare/hash.
bye, Roman
From: Duane Griffin [EMAIL PROTECTED]
Add custom dentry hash and comparison operations for HFS+ filesystems
that are case-insensitive and/or do automatic unicode decomposition.
The new operations reuse the existing HFS+ ASCII to unicode conversion,
unicode decomposition and case folding functionality.
Signed-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 |1
fs/hfsplus/unicode.c| 123
6 files changed, 138 insertions(+), 1 deletion(-)
Index: linux-2.6/fs/hfsplus/dir.c
===
--- linux-2.6.orig/fs/hfsplus/dir.c 2007-04-26 19:45:57.0 +0200
+++ linux-2.6/fs/hfsplus/dir.c 2007-06-25 13:39:46.0 +0200
@@ -36,6 +36,8 @@ static struct dentry *hfsplus_lookup(str
u16 type;
sb = dir-i_sb;
+
+ dentry-d_op = hfsplus_dentry_operations;
dentry-d_fsdata = NULL;
hfs_find_init(HFSPLUS_SB(sb).cat_tree, fd);
hfsplus_cat_build_key(sb, fd.search_key, dir-i_ino, dentry-d_name);
Index: linux-2.6/fs/hfsplus/hfsplus_fs.h
===
--- linux-2.6.orig/fs/hfsplus/hfsplus_fs.h 2007-04-26 19:45:57.0
+0200
+++ linux-2.6/fs/hfsplus/hfsplus_fs.h 2007-06-25 12:59:16.0 +0200
@@ -150,6 +150,7 @@ struct hfsplus_sb_info {
#define HFSPLUS_SB_NODECOMPOSE 0x0002
#define HFSPLUS_SB_FORCE 0x0004
#define HFSPLUS_SB_HFSX0x0008
+#define HFSPLUS_SB_CASEFOLD0x0010
struct hfsplus_inode_info {
@@ -321,6 +322,7 @@ void hfsplus_file_truncate(struct inode
/* inode.c */
extern const struct address_space_operations hfsplus_aops;
extern const struct address_space_operations hfsplus_btree_aops;
+extern struct dentry_operations hfsplus_dentry_operations;
void hfsplus_inode_read_fork(struct inode *, struct hfsplus_fork_raw *);
void hfsplus_inode_write_fork(struct inode *, struct hfsplus_fork_raw *);
@@ -353,6 +355,8 @@ int hfsplus_strcasecmp(const struct hfsp
int hfsplus_strcmp(const struct hfsplus_unistr *, const struct hfsplus_unistr
*);
int hfsplus_uni2asc(struct super_block *, const struct hfsplus_unistr *, char
*, int *);
int hfsplus_asc2uni(struct super_block *, struct hfsplus_unistr *, const char
*, int);
+int hfsplus_hash_dentry(struct dentry *dentry, struct qstr *str);
+int hfsplus_compare_dentry(struct dentry *dentry, struct qstr *s1, struct qstr
*s2);
/* wrapper.c */
int hfsplus_read_wrapper(struct super_block *);
Index: linux-2.6/fs/hfsplus/inode.c
===
--- linux-2.6.orig/fs/hfsplus/inode.c 2007-04-26 19:45:57.0 +0200
+++ linux-2.6/fs/hfsplus/inode.c2007-06-25 13:52:54.0 +0200
@@ -130,6 +130,11 @@ const struct address_space_operations hf
.writepages = hfsplus_writepages,
};
+struct dentry_operations hfsplus_dentry_operations = {
+ .d_hash = hfsplus_hash_dentry,
+ .d_compare= hfsplus_compare_dentry,
+};
+
static struct dentry *hfsplus_file_lookup(struct inode *dir, struct dentry
*dentry,
struct nameidata *nd)
{
Index: linux-2.6/fs/hfsplus/unicode.c
===
--- linux-2.6.orig/fs/hfsplus/unicode.c 2007-06-25 12:59:15.0 +0200
+++ linux-2.6/fs/hfsplus/unicode.c 2007-06-25 13:35:23.0 +0200
@@ -312,3 +312,126 @@ int hfsplus_asc2uni(struct super_block *
return -ENAMETOOLONG;
return 0;
}
+
+/*
+ * Hash a string to an integer as appropriate for the HFS+ filesystem.
+ * Composed unicode characters are decomposed and case-folding is performed
+ * if the appropriate bits are (un)set on the superblock.
+ */
+int hfsplus_hash_dentry(struct dentry *dentry, struct qstr *str)
+{
+ struct super_block *sb = dentry-d_sb;
+ const char *astr;
+ const u16 *dstr;
+ int casefold, decompose, size, dsize, len;
+ unsigned long hash;
+ wchar_t c;
+ u16 c2;
+
+ casefold = (HFSPLUS_SB(sb).flags HFSPLUS_SB_CASEFOLD);
+ decompose = !(HFSPLUS_SB(sb).flags HFSPLUS_SB_NODECOMPOSE);
+ hash
Re: [PATCH] cross-architecture ELF clean up
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, functionally unchanged linux/elf-const.h - ELF constants, includable by asm code We have the __ASSEMBLY__ define for this, so just for asm code we don't need a separate header. linux/elf-decl.h- ELF type declarations, without definitions linux/elf-defn.h- ELF type definitions What's the point in splitting these two? After this patch linux/elf.h seems to be pretty much empty, I'd rather suggest to move the function declarations to elfcore.h and leave the basic elf definitions in elf.h. Many small header files have the disadvantage that it takes longer to find the needed information. 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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cross-architecture ELF clean up
Hi, On Mon, 25 Jun 2007, David Woodhouse wrote: On Wed, 2007-06-20 at 16:08 -0700, Jeremy Fitzhardinge wrote: This patch cleans up the ELF headers and their users. It does several related things: Looks good. We can get away with exporting a lot less of this to userspace too, can't we? glibc provides its own version, so it doesn't has to be exported at all. 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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cross-architecture ELF clean up
Hi, On Mon, 25 Jun 2007, Clemens Koller wrote: glibc provides its own version, so it doesn't has to be exported at all. AFAIK the glibc folks want to rely more on the linux kernel headers in the future and not provide more or less redundant headers anymore... In this case it's more an ABI header, it doesn't export any kernel interfaces. 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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cross-architecture ELF clean up
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 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 the FAQ at http://www.tux.org/lkml/
Re: [patch, v2.6.22-rc6] sys_time() speedup
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;
+
+ /*
+ * Make sure xtime.tv_sec [returned by sys_time()] always
+ * follows the gettimeofday() result precisely. This
+ * condition is extremely unlikely, it can hit at most
+ * once per second:
+ */
+ if (unlikely(xtime.tv_sec != tv-tv_sec)) {
+ unsigned long flags;
+
+ write_seqlock_irqsave(xtime_lock);
+ update_wall_time();
+ write_seqlock_irqrestore(xtime_lock);
+ }
}
EXPORT_SYMBOL(do_gettimeofday);
Is this the do_gettimeofday() inside CONFIG_TIME_INTERPOLATION?
What did you test?
There can be many ways to read the clock, do you want to put this hook
everywhere? Wouldn't it be better to improve the clock performance?
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 the FAQ at http://www.tux.org/lkml/
Re: [patch, v2.6.22-rc6] sys_time() speedup
Hi, On Mon, 25 Jun 2007, Jesper Juhl wrote: On Monday 25 June 2007, Ingo Molnar wrote: the patch improves the sysbench OLTP macrobenchmark significantly: Has that any real practical relevance? It seems to me that Ingo's patch offers slightly improved performance for any program using the time() system call, with no real drawbacks, so why wouldn't we want to use it? How do you come to the conclusion it has no real drawbacks? Ingo provided no information about his test setup and his patch was a little strange, so I can't say that yet. 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 the FAQ at http://www.tux.org/lkml/
Re: [patch, v2.6.22-rc6] sys_time() speedup
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 change would be useless. I don't know what clock was used in the test, so maybe it can be replaced with a faster clock. AFAICT OLTP is not really a common application for most users, so there may be other ways to optimize this special case. Just reading the patch isn't enough here, you have to look at the whole picture and some pieces are still missing... 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 the FAQ at http://www.tux.org/lkml/
Re: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
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 Makefiles or C files >(so in fact, just to menuconfig and that they are listed in .config) I really don't understand why this should be needed in first place. Where is the problem with using tristate? Nobody forces anyone to set it to 'm' if you don't like it. I could also argue it easily allows me to quickly restrict enclosed options to module status. It's just another choice, where is that fascination coming from that it has to be an on/off switch? Whether the config option is visible in the Makefile and produces any code, is completely irrelevant in this context, as the user trying to configure the kernel has no idea of it. 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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH] HFSPlus: simplify inode mode settting logic
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 that the permissions structure is uninitialized" 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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH] HFSPlus: simplify inode mode settting logic
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 that the permissions structure is uninitialized 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 the FAQ at http://www.tux.org/lkml/
Re: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
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 Makefiles or C files (so in fact, just to menuconfig and that they are listed in .config) I really don't understand why this should be needed in first place. Where is the problem with using tristate? Nobody forces anyone to set it to 'm' if you don't like it. I could also argue it easily allows me to quickly restrict enclosed options to module status. It's just another choice, where is that fascination coming from that it has to be an on/off switch? Whether the config option is visible in the Makefile and produces any code, is completely irrelevant in this context, as the user trying to configure the kernel has no idea of it. 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 the FAQ at http://www.tux.org/lkml/
Re: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
Hi, On Sat, 23 Jun 2007, Satyam Sharma wrote: > But why? Let it do just one thing, and do it well. Is their > any requirement anywhere that requires us to give a dual > meaning to these menuconfig objects -- i.e. to also control > the inclusion / exclusion of code from the kernel as well as > also for the presentation + user interface purpose that it > currently serves? This getting ridiculous. :-( You're the one who is attaching a new meaning to it. Any config symbol has multiple meanings depending on the context, the menu property only changes _one_ of them, you want to drastically redefine it and that's not going to happen. 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 the FAQ at http://www.tux.org/lkml/
Re: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
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 linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
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 code attached to it, menuconfig doesn't change anything. > 2. "menuconfig" symbols, otoh, were _invented_ for another reason > entirely: presentation and user interface i.e. so that users are able > to disable entire menus (and all the options contained therein) > without having to enter into the menu first, and without having to > disable all options individually (which was the situation that existed > before the introduction of these menuconfig objects). Since I'm the one who _invented_ it, I can tell you you're wrong. :) This functionality isn't limited to menuconfig symbols. The menu option simply changes how the child symbols can be displayed. 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 the FAQ at http://www.tux.org/lkml/
Re: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
Hi, On Sat, 23 Jun 2007, Satyam Sharma wrote: > > menuconfig is really a type of config symbol, rather than a type of menu. > > Well, I'd have to disagree here. A config symbol has code associated > with it (at least _all_ config symbols in the kernel originally did, till > when these "menuconfig" things got introduced, which is precisely > what made them "special"). Only because it's currently used mostly like this, it doesn't add any "special" meaning. 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 the FAQ at http://www.tux.org/lkml/
Re: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
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 this, as this would attach special meaning to a menuconfig. menuconfig is really a type of config symbol, rather than a type of menu. Potentially this could also be written as: config FOO option menu ... 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 the FAQ at http://www.tux.org/lkml/
Re: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
Hi, On Fri, 22 Jun 2007, Jan Engelhardt wrote: > V4L_USB_DRIVERS=y turns USB into =y? That can't be. It should give the "this > depends on another symbol [USB] that is modular". That's not how it works, the enclosed symbols depend now on V4L_USB_DRIVERS, which is a boolean and it can only have two states. It doesn't matter on what V4L_USB_DRIVERS depends only the final value matters. (BTW if check the dependency debug output in menuconfig/xconfig, you'll see which values are relevant in the calculation of a symbol value.) > >I'm also a little irritated by the "default y", if I enable V4L I'm very > >tempted to check what other useless stuff has been automatically enabled, > >which I have to turn off again. > > The default y only applies to the "menu" folders, not actual code. I don't know that without checking the Makefile. > There have been discussions to remove the default-ys again, I've sent a patch > [http://lkml.org/lkml/2007/5/12/216], but nothing happened. > > So, should all affected menuconfigs be transformed into tristates, what > do you think, Roman? Let me know so I can cook up a patch (hopefully > before 2.6.22) should they become tristate. Using bool is clearly a bug and I'd prefer if it removed the defaults as well. 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 the FAQ at http://www.tux.org/lkml/
Re: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
Hi,
On Fri, 22 Jun 2007, Mauro Carvalho Chehab wrote:
> I'm to keep "default y" for the menuconfig items.
>
> Since those don't generate any code (there's no Makefile items
> associated with the menuconfig vars),
I don't know that without checking Makefiles/sources, so I have to assume
it may produce some infrastructure code I don't need.
> this will just improve the
> usability for the final user (and will allow make oldconfig to work).
I'd rather change that.
> There's not much sense on selecting V4L support without 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 ++---
1 file changed, 26 insertions(+), 11 deletions(-)
Index: linux-2.6/scripts/kconfig/confdata.c
===
--- linux-2.6.orig/scripts/kconfig/confdata.c
+++ linux-2.6/scripts/kconfig/confdata.c
@@ -341,27 +341,42 @@ int conf_read(const char *name)
conf_unsaved++;
/* maybe print value in verbose mode... */
sym_ok:
+ if (!sym_is_choice(sym))
+ continue;
+ /* The choice symbol only has a set value (and thus is not new)
+* if all its visible childs have values.
+*/
+ prop = sym_get_choice_prop(sym);
+ flags = sym->flags;
+ for (e = prop->expr; e; e = e->left.expr)
+ if (e->right.sym->visible != no)
+ flags &= e->right.sym->flags;
+ sym->flags &= flags | ~SYMBOL_DEF_USER;
+ }
+
+ for_all_symbols(i, sym) {
if (sym_has_value(sym) && !sym_is_choice_value(sym)) {
- if (sym->visible == no)
+ /* Reset values of generates values, so they'll appear
+* as new, if they should become visible, but that
+* doesn't quite work if the Kconfig and the saved
+* configuration disagrees.
+*/
+ if (sym->visible == no && !conf_unsaved)
sym->flags &= ~SYMBOL_DEF_USER;
switch (sym->type) {
case S_STRING:
case S_INT:
case S_HEX:
- if (!sym_string_within_range(sym,
sym->def[S_DEF_USER].val))
- sym->flags &=
~(SYMBOL_VALID|SYMBOL_DEF_USER);
+ /* Reset a string value if it's out of range */
+ if (sym_string_within_range(sym,
sym->def[S_DEF_USER].val))
+ break;
+ sym->flags &= ~(SYMBOL_VALID|SYMBOL_DEF_USER);
+ conf_unsaved++;
+ break;
default:
break;
}
}
- if (!sym_is_choice(sym))
- continue;
- prop = sym_get_choice_prop(sym);
- flags = sym->flags;
- for (e = prop->expr; e; e = e->left.expr)
- if (e->right.sym->visible != no)
- flags &= e->right.sym->flags;
- sym->flags &= flags | ~SYMBOL_DEF_USER;
}
sym_add_change_count(conf_warnings || conf_unsaved);
-
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 the FAQ at http://www.tux.org/lkml/
Re: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
Hi, On Fri, 22 Jun 2007, Mauro Carvalho Chehab wrote: > Hi Roman, > > Several instabilities on Kconfig started to happen after replacing > Kconfig menus to use menuconfig, as this one, reported by Oliver: > > Em Qui, 2007-06-21 às 13:50 +0200, Oliver Neukum escreveu: > > Am Donnerstag, 21. Juni 2007 schrieb Toralf Förster: > > > Right, but IMHO this issue is typical for a problem with the Kconfig > > > definitions of this module. > > > > > > I'll set USB devs as Cc: therefore. There is too little context here, what was the exact error? I'm assuming it's the module vs. builtin problem? > In this specific case, all V4L USB drivers depends on V4L_USB_DRIVERS, > that depends, in turn, on USB. So, if USB is not selected, > V4L_USB_DRIVERS should be unselected, unselecting zc0301. > > Unfortunately, the Kernel building system is not properly handling it. > > This is the (snipped) media/video/Kconfig: > > menuconfig V4L_USB_DRIVERS > bool "V4L USB devices" > depends on USB > default y > The menuconfig patches were a little aggressive here, it created a config symbol where there was none before and in this case it even changed dependencies (it turns USB into a bool). I'm also a little irritated by the "default y", if I enable V4L I'm very tempted to check what other useless stuff has been automatically enabled, which I have to turn off again. bye, Roman
Re: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
Hi, On Fri, 22 Jun 2007, Mauro Carvalho Chehab wrote: Hi Roman, Several instabilities on Kconfig started to happen after replacing Kconfig menus to use menuconfig, as this one, reported by Oliver: Em Qui, 2007-06-21 às 13:50 +0200, Oliver Neukum escreveu: Am Donnerstag, 21. Juni 2007 schrieb Toralf Förster: Right, but IMHO this issue is typical for a problem with the Kconfig definitions of this module. I'll set USB devs as Cc: therefore. There is too little context here, what was the exact error? I'm assuming it's the module vs. builtin problem? In this specific case, all V4L USB drivers depends on V4L_USB_DRIVERS, that depends, in turn, on USB. So, if USB is not selected, V4L_USB_DRIVERS should be unselected, unselecting zc0301. Unfortunately, the Kernel building system is not properly handling it. This is the (snipped) media/video/Kconfig: menuconfig V4L_USB_DRIVERS bool V4L USB devices depends on USB default y The menuconfig patches were a little aggressive here, it created a config symbol where there was none before and in this case it even changed dependencies (it turns USB into a bool). I'm also a little irritated by the default y, if I enable V4L I'm very tempted to check what other useless stuff has been automatically enabled, which I have to turn off again. bye, Roman
Re: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
Hi, On Fri, 22 Jun 2007, Jan Engelhardt wrote: V4L_USB_DRIVERS=y turns USB into =y? That can't be. It should give the this depends on another symbol [USB] that is modular. That's not how it works, the enclosed symbols depend now on V4L_USB_DRIVERS, which is a boolean and it can only have two states. It doesn't matter on what V4L_USB_DRIVERS depends only the final value matters. (BTW if check the dependency debug output in menuconfig/xconfig, you'll see which values are relevant in the calculation of a symbol value.) I'm also a little irritated by the default y, if I enable V4L I'm very tempted to check what other useless stuff has been automatically enabled, which I have to turn off again. The default y only applies to the menu folders, not actual code. I don't know that without checking the Makefile. There have been discussions to remove the default-ys again, I've sent a patch [http://lkml.org/lkml/2007/5/12/216], but nothing happened. So, should all affected menuconfigs be transformed into tristates, what do you think, Roman? Let me know so I can cook up a patch (hopefully before 2.6.22) should they become tristate. Using bool is clearly a bug and I'd prefer if it removed the defaults as well. 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 the FAQ at http://www.tux.org/lkml/
Re: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
Hi,
On Fri, 22 Jun 2007, Mauro Carvalho Chehab wrote:
I'm to keep default y for the menuconfig items.
Since those don't generate any code (there's no Makefile items
associated with the menuconfig vars),
I don't know that without checking Makefiles/sources, so I have to assume
it may produce some infrastructure code I don't need.
this will just improve the
usability for the final user (and will allow make oldconfig to work).
I'd rather change that.
There's not much sense on selecting V4L support without 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 ++---
1 file changed, 26 insertions(+), 11 deletions(-)
Index: linux-2.6/scripts/kconfig/confdata.c
===
--- linux-2.6.orig/scripts/kconfig/confdata.c
+++ linux-2.6/scripts/kconfig/confdata.c
@@ -341,27 +341,42 @@ int conf_read(const char *name)
conf_unsaved++;
/* maybe print value in verbose mode... */
sym_ok:
+ if (!sym_is_choice(sym))
+ continue;
+ /* The choice symbol only has a set value (and thus is not new)
+* if all its visible childs have values.
+*/
+ prop = sym_get_choice_prop(sym);
+ flags = sym-flags;
+ for (e = prop-expr; e; e = e-left.expr)
+ if (e-right.sym-visible != no)
+ flags = e-right.sym-flags;
+ sym-flags = flags | ~SYMBOL_DEF_USER;
+ }
+
+ for_all_symbols(i, sym) {
if (sym_has_value(sym) !sym_is_choice_value(sym)) {
- if (sym-visible == no)
+ /* Reset values of generates values, so they'll appear
+* as new, if they should become visible, but that
+* doesn't quite work if the Kconfig and the saved
+* configuration disagrees.
+*/
+ if (sym-visible == no !conf_unsaved)
sym-flags = ~SYMBOL_DEF_USER;
switch (sym-type) {
case S_STRING:
case S_INT:
case S_HEX:
- if (!sym_string_within_range(sym,
sym-def[S_DEF_USER].val))
- sym-flags =
~(SYMBOL_VALID|SYMBOL_DEF_USER);
+ /* Reset a string value if it's out of range */
+ if (sym_string_within_range(sym,
sym-def[S_DEF_USER].val))
+ break;
+ sym-flags = ~(SYMBOL_VALID|SYMBOL_DEF_USER);
+ conf_unsaved++;
+ break;
default:
break;
}
}
- if (!sym_is_choice(sym))
- continue;
- prop = sym_get_choice_prop(sym);
- flags = sym-flags;
- for (e = prop-expr; e; e = e-left.expr)
- if (e-right.sym-visible != no)
- flags = e-right.sym-flags;
- sym-flags = flags | ~SYMBOL_DEF_USER;
}
sym_add_change_count(conf_warnings || conf_unsaved);
-
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 the FAQ at http://www.tux.org/lkml/
Re: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
Hi, On Sat, 23 Jun 2007, Satyam Sharma wrote: given menuconfig FOO depends on BAR, then all the config BAZs inside this menuconfig also automatically depend on BAR too. This is simpler in the long run because it requires least amount (actually none) of redundant typing I don't like this, as this would attach special meaning to a menuconfig. menuconfig is really a type of config symbol, rather than a type of menu. Potentially this could also be written as: config FOO option menu ... 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 the FAQ at http://www.tux.org/lkml/
Re: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
Hi, On Sat, 23 Jun 2007, Satyam Sharma wrote: menuconfig is really a type of config symbol, rather than a type of menu. Well, I'd have to disagree here. A config symbol has code associated with it (at least _all_ config symbols in the kernel originally did, till when these menuconfig things got introduced, which is precisely what made them special). Only because it's currently used mostly like this, it doesn't add any special meaning. 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 the FAQ at http://www.tux.org/lkml/
Re: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
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 code attached to it, menuconfig doesn't change anything. 2. menuconfig symbols, otoh, were _invented_ for another reason entirely: presentation and user interface i.e. so that users are able to disable entire menus (and all the options contained therein) without having to enter into the menu first, and without having to disable all options individually (which was the situation that existed before the introduction of these menuconfig objects). Since I'm the one who _invented_ it, I can tell you you're wrong. :) This functionality isn't limited to menuconfig symbols. The menu option simply changes how the child symbols can be displayed. 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 the FAQ at http://www.tux.org/lkml/
Re: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
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 linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
Hi, On Sat, 23 Jun 2007, Satyam Sharma wrote: But why? Let it do just one thing, and do it well. Is their any requirement anywhere that requires us to give a dual meaning to these menuconfig objects -- i.e. to also control the inclusion / exclusion of code from the kernel as well as also for the presentation + user interface purpose that it currently serves? This getting ridiculous. :-( You're the one who is attaching a new meaning to it. Any config symbol has multiple meanings depending on the context, the menu property only changes _one_ of them, you want to drastically redefine it and that's not going to happen. 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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH for 2.6.22] [5/10] x86_64: Quieten Atari keyboard warnings in Kconfig
Hi, On Wed, 20 Jun 2007, Andi Kleen wrote: > Not directly related to x86, but I got tired of seeing these warnings on every > kconfig update when building on a non m68k box: > > drivers/input/keyboard/Kconfig:170:warning: 'select' used by config symbol > 'KEYBOARD_ATARI' refers to undefined symbol 'ATARI_KBD_CORE' > drivers/input/mouse/Kconfig:182:warning: 'select' used by config symbol > 'MOUSE_ATARI' refers to undefined symbol 'ATARI_KBD_CORE' > > I moved the definition of ATARI_KBD_CORE into drivers/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 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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH for 2.6.22] [5/10] x86_64: Quieten Atari keyboard warnings in Kconfig
Hi, On Wed, 20 Jun 2007, Andi Kleen wrote: Not directly related to x86, but I got tired of seeing these warnings on every kconfig update when building on a non m68k box: drivers/input/keyboard/Kconfig:170:warning: 'select' used by config symbol 'KEYBOARD_ATARI' refers to undefined symbol 'ATARI_KBD_CORE' drivers/input/mouse/Kconfig:182:warning: 'select' used by config symbol 'MOUSE_ATARI' refers to undefined symbol 'ATARI_KBD_CORE' I moved the definition of ATARI_KBD_CORE into drivers/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 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 the FAQ at http://www.tux.org/lkml/
Re: kconfig - scan all Kconfig files
Hi, On Mon, 21 May 2007, Sam Ravnborg wrote: > > A simple example would be > > help texts, right now they are per symbol, but they should really be per > > menu, so archs can provide different help texts for something. > > This one turned out easy. > I assume what you had in mind was something like the attached. Yes, but if we change it, we should also add wrapper functions like menu_get_help()/menu_has_help() (where menu_get_help() could also return some generated text). 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 the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] do_div_signed()
Hi,
On Mon, 21 May 2007, john stultz wrote:
> Here's a quick pass at adding do_div_signed() which provides a signed
> version of do_div, avoiding having do_div users hack around signed
> issues (like in ntp.c).
>
> It probably could be optimized further, so let me know if you have any
> suggestions.
>
>
> Other thoughts?
Did I mention that this API could use a little cleanup? :)
Below is what I had in mind, this makes it more clear what types the
functions are working on. As bonus I cleaned up the i386 div64
implementation to get rid of the ugly 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
kernel/time.c | 26 +++---
kernel/time/ntp.c | 21 +
lib/div64.c | 21 -
6 files changed, 94 insertions(+), 36 deletions(-)
Index: linux-2.6/include/asm-generic/div64.h
===
--- linux-2.6.orig/include/asm-generic/div64.h
+++ linux-2.6/include/asm-generic/div64.h
@@ -35,6 +35,20 @@ static inline uint64_t div64_64(uint64_t
return dividend / divisor;
}
+static inline u64 div_u64_rem(u64 dividend, u32 divisor, u32 *remainder)
+{
+ *remainder = dividend % divisor;
+ return dividend / divisor;
+}
+#define div_u64_remdiv_u64_rem
+
+static inline s64 div_s64_rem(s64 dividend, s32 divisor, s32 *remainder)
+{
+ *remainder = dividend % divisor;
+ return dividend / divisor;
+}
+#define div_s64_remdiv_s64_rem
+
#elif BITS_PER_LONG == 32
extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);
Index: linux-2.6/include/asm-i386/div64.h
===
--- linux-2.6.orig/include/asm-i386/div64.h
+++ linux-2.6/include/asm-i386/div64.h
@@ -48,5 +48,25 @@ div_ll_X_l_rem(long long divs, long div,
}
+static inline u64 div_u64_rem(u64 dividend, u32 divisor, u32 *remainder)
+{
+ union {
+ u64 v64;
+ u32 v32[2];
+ } d = { dividend };
+ u32 upper;
+
+ upper = d.v32[1];
+ if (upper) {
+ upper = d.v32[1] % divisor;
+ d.v32[1] = d.v32[1] / divisor;
+ }
+ asm ("divl %2" : "=a" (d.v32[0]), "=d" (*remainder) :
+ "rm" (divisor), "0" (d.v32[0]), "1" (upper));
+ return d.v64;
+}
+#define div_u64_remdiv_u64_rem
+
extern uint64_t div64_64(uint64_t dividend, uint64_t divisor);
+
#endif
Index: linux-2.6/include/linux/calc64.h
===
--- linux-2.6.orig/include/linux/calc64.h
+++ linux-2.6/include/linux/calc64.h
@@ -46,4 +46,32 @@ static inline long div_long_long_rem_sig
return res;
}
+#ifndef div_u64_rem
+static inline u64 div_u64_rem(u64 dividend, u32 divisor, u32 *remainder)
+{
+ *remainder = do_div(dividend, divisor);
+ return dividend;
+}
+#endif
+
+#ifndef div_u64
+static inline u64 div_u64(u64 dividend, u32 divisor)
+{
+ u32 remainder;
+ return div_u64_rem(dividend, divisor, );
+}
+#endif
+
+#ifndef div_s64_rem
+extern s64 div_s64_rem(s64 dividend, s32 divisor, s32 *remainder);
+#endif
+
+#ifndef div_s64
+static inline s64 div_s64(s64 dividend, s32 divisor)
+{
+ s32 remainder;
+ return div_s64_rem(dividend, divisor, );
+}
+#endif
+
#endif
Index: linux-2.6/kernel/time.c
===
--- linux-2.6.orig/kernel/time.c
+++ linux-2.6/kernel/time.c
@@ -661,9 +661,7 @@ clock_t jiffies_to_clock_t(long x)
#if (TICK_NSEC % (NSEC_PER_SEC / USER_HZ)) == 0
return x / (HZ / USER_HZ);
#else
- u64 tmp = (u64)x * TICK_NSEC;
- do_div(tmp, (NSEC_PER_SEC / USER_HZ));
- return (long)tmp;
+ return div_u64((u64)x * TICK_NSEC, NSEC_PER_SEC / USER_HZ);
#endif
}
EXPORT_SYMBOL(jiffies_to_clock_t);
@@ -675,16 +673,12 @@ unsigned long clock_t_to_jiffies(unsigne
return ~0UL;
return x * (HZ / USER_HZ);
#else
- u64 jif;
-
/* Don't worry about loss of precision here .. */
if (x >= ~0UL / HZ * USER_HZ)
return ~0UL;
/* .. but do try to contain it here */
- jif = x * (u64) HZ;
- do_div(jif, USER_HZ);
- return jif;
+ return div_u64((u64)x * HZ, USER_HZ);
#endif
}
EXPORT_SYMBOL(clock_t_to_jiffies);
@@ -692,17 +686,15 @@ EXPORT_SYMBOL(clock_t_to_jiffies);
u64 jiffies_64_to_clock_t(u64 x)
{
#if (TICK_NSEC % (NSEC_PER_SEC / USER_HZ)) == 0
- do_div(x, HZ / USER_HZ);
+ return div_u64(x, HZ / USER_HZ);
Re: [RFC][PATCH] do_div_signed()
Hi,
On Mon, 21 May 2007, john stultz wrote:
Here's a quick pass at adding do_div_signed() which provides a signed
version of do_div, avoiding having do_div users hack around signed
issues (like in ntp.c).
It probably could be optimized further, so let me know if you have any
suggestions.
Other thoughts?
Did I mention that this API could use a little cleanup? :)
Below is what I had in mind, this makes it more clear what types the
functions are working on. As bonus I cleaned up the i386 div64
implementation to get rid of the ugly 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
kernel/time.c | 26 +++---
kernel/time/ntp.c | 21 +
lib/div64.c | 21 -
6 files changed, 94 insertions(+), 36 deletions(-)
Index: linux-2.6/include/asm-generic/div64.h
===
--- linux-2.6.orig/include/asm-generic/div64.h
+++ linux-2.6/include/asm-generic/div64.h
@@ -35,6 +35,20 @@ static inline uint64_t div64_64(uint64_t
return dividend / divisor;
}
+static inline u64 div_u64_rem(u64 dividend, u32 divisor, u32 *remainder)
+{
+ *remainder = dividend % divisor;
+ return dividend / divisor;
+}
+#define div_u64_remdiv_u64_rem
+
+static inline s64 div_s64_rem(s64 dividend, s32 divisor, s32 *remainder)
+{
+ *remainder = dividend % divisor;
+ return dividend / divisor;
+}
+#define div_s64_remdiv_s64_rem
+
#elif BITS_PER_LONG == 32
extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);
Index: linux-2.6/include/asm-i386/div64.h
===
--- linux-2.6.orig/include/asm-i386/div64.h
+++ linux-2.6/include/asm-i386/div64.h
@@ -48,5 +48,25 @@ div_ll_X_l_rem(long long divs, long div,
}
+static inline u64 div_u64_rem(u64 dividend, u32 divisor, u32 *remainder)
+{
+ union {
+ u64 v64;
+ u32 v32[2];
+ } d = { dividend };
+ u32 upper;
+
+ upper = d.v32[1];
+ if (upper) {
+ upper = d.v32[1] % divisor;
+ d.v32[1] = d.v32[1] / divisor;
+ }
+ asm (divl %2 : =a (d.v32[0]), =d (*remainder) :
+ rm (divisor), 0 (d.v32[0]), 1 (upper));
+ return d.v64;
+}
+#define div_u64_remdiv_u64_rem
+
extern uint64_t div64_64(uint64_t dividend, uint64_t divisor);
+
#endif
Index: linux-2.6/include/linux/calc64.h
===
--- linux-2.6.orig/include/linux/calc64.h
+++ linux-2.6/include/linux/calc64.h
@@ -46,4 +46,32 @@ static inline long div_long_long_rem_sig
return res;
}
+#ifndef div_u64_rem
+static inline u64 div_u64_rem(u64 dividend, u32 divisor, u32 *remainder)
+{
+ *remainder = do_div(dividend, divisor);
+ return dividend;
+}
+#endif
+
+#ifndef div_u64
+static inline u64 div_u64(u64 dividend, u32 divisor)
+{
+ u32 remainder;
+ return div_u64_rem(dividend, divisor, remainder);
+}
+#endif
+
+#ifndef div_s64_rem
+extern s64 div_s64_rem(s64 dividend, s32 divisor, s32 *remainder);
+#endif
+
+#ifndef div_s64
+static inline s64 div_s64(s64 dividend, s32 divisor)
+{
+ s32 remainder;
+ return div_s64_rem(dividend, divisor, remainder);
+}
+#endif
+
#endif
Index: linux-2.6/kernel/time.c
===
--- linux-2.6.orig/kernel/time.c
+++ linux-2.6/kernel/time.c
@@ -661,9 +661,7 @@ clock_t jiffies_to_clock_t(long x)
#if (TICK_NSEC % (NSEC_PER_SEC / USER_HZ)) == 0
return x / (HZ / USER_HZ);
#else
- u64 tmp = (u64)x * TICK_NSEC;
- do_div(tmp, (NSEC_PER_SEC / USER_HZ));
- return (long)tmp;
+ return div_u64((u64)x * TICK_NSEC, NSEC_PER_SEC / USER_HZ);
#endif
}
EXPORT_SYMBOL(jiffies_to_clock_t);
@@ -675,16 +673,12 @@ unsigned long clock_t_to_jiffies(unsigne
return ~0UL;
return x * (HZ / USER_HZ);
#else
- u64 jif;
-
/* Don't worry about loss of precision here .. */
if (x = ~0UL / HZ * USER_HZ)
return ~0UL;
/* .. but do try to contain it here */
- jif = x * (u64) HZ;
- do_div(jif, USER_HZ);
- return jif;
+ return div_u64((u64)x * HZ, USER_HZ);
#endif
}
EXPORT_SYMBOL(clock_t_to_jiffies);
@@ -692,17 +686,15 @@ EXPORT_SYMBOL(clock_t_to_jiffies);
u64 jiffies_64_to_clock_t(u64 x)
{
#if (TICK_NSEC % (NSEC_PER_SEC / USER_HZ)) == 0
- do_div(x, HZ / USER_HZ);
+ return div_u64(x, HZ / USER_HZ);
#else
/*
* There are better ways that don't overflow early,
* but even this doesn't
Re: kconfig - scan all Kconfig files
Hi, On Mon, 21 May 2007, Sam Ravnborg wrote: A simple example would be help texts, right now they are per symbol, but they should really be per menu, so archs can provide different help texts for something. This one turned out easy. I assume what you had in mind was something like the attached. Yes, but if we change it, we should also add wrapper functions like menu_get_help()/menu_has_help() (where menu_get_help() could also return some generated text). 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 the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc2 built on ppc (2)
Hi,
On Mon, 21 May 2007, Thomas Gleixner wrote:
> diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
> index cb25649..bb1bf86 100644
> --- a/kernel/time/ntp.c
> +++ b/kernel/time/ntp.c
> @@ -304,10 +304,12 @@ int do_adjtimex(struct timex *txc)
> temp64 = time_offset << (SHIFT_NSEC - SHIFT_FLL);
> if (time_offset < 0) {
> temp64 = -temp64;
> - do_div(temp64, mtemp);
> + temp64 = div_long_long_rem_signed(temp64, mtemp,
> + );
> freq_adj -= temp64;
> } else {
> - do_div(temp64, mtemp);
> + temp64 = div_long_long_rem_signed(temp64, mtemp,
> + );
> freq_adj += temp64;
> }
> }
This only returns a long.
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 the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc2 built on ppc (2)
Hi,
On Mon, 21 May 2007, Thomas Gleixner wrote:
diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index cb25649..bb1bf86 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -304,10 +304,12 @@ int do_adjtimex(struct timex *txc)
temp64 = time_offset (SHIFT_NSEC - SHIFT_FLL);
if (time_offset 0) {
temp64 = -temp64;
- do_div(temp64, mtemp);
+ temp64 = div_long_long_rem_signed(temp64, mtemp,
+ rem);
freq_adj -= temp64;
} else {
- do_div(temp64, mtemp);
+ temp64 = div_long_long_rem_signed(temp64, mtemp,
+ rem);
freq_adj += temp64;
}
}
This only returns a long.
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 the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc2 built on ppc (2)
Hi, On Sun, 20 May 2007, Andrew Morton wrote: > On Sun, 20 May 2007 13:08:15 +0200 Elimar Riesebieter <[EMAIL PROTECTED]> > wrote: > > > FYI, building 2.6.22-rc2 with > > gcc (GCC) 4.1.3 20070514 (prerelease) (Debian 4.1.2-7) > > on my powerbook (PPC) gives: > > > > ... > > kernel/time/ntp.c: In function 'do_adjtimex': > > kernel/time/ntp.c:307: warning: comparison of distinct pointer types lacks > > a cast > > kernel/time/ntp.c:310: warning: comparison of distinct pointer types lacks > > a cast > > hm, do_div() is defined as operating on a u64, but ntp is passing it an s64 > and the asm-generic implementation of do_div() is warning about that. > > Fixing that would be simple but a bit ugly. The correct fix would be to clean up that API and provide a signed do_div(), so ntp doesn't have to work around for the lack of it. It's on my todo list for ages, but I haven't gotten to it yet. 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 the FAQ at http://www.tux.org/lkml/
Re: kconfig - scan all Kconfig files
Hi, On Sun, 20 May 2007, Sam Ravnborg wrote: > I did a quick hack so kconfig could scan all Kconfig files > in the kernel tree. > By scanning all Kconfig files we gain the following: > > -> kconfig can report when a depends on refer to an undefined symbol > -> kconfig can report when a select refer to an undefined symbol > > Later we can push a lot of common stuff to the top-level Kconfig file. > And that may in the end result in a better structure overall for > Kconfig files. Well, some of that stuff should already happen earlier (and included from the arch Kconfig files), but that doesn't work for everything. I don't think that simply allowing to parse a file multiple times is the right answer, as it duplicates a lot of data. 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. "source" should become a bit more intelligent and parse a file only once and link the data into the menu structure. > All the "choice values currently only support a single prompt" are caused > by using the same config symbol in a choice list for several architectures. > That will be the biggest challenge to fix before we can introduce this patch. > Maybe we can extend kconfig to accept it??? Define "accept". The basic rule for choice values must not be violated - none of them may depend on another value in the same group. The dependency tree allows for no loops, these choice groups allow for the only exception, but it has to stay within that group. One option I'm thinking about is to extend that group by naming the choice option, so kconfig knows they are related. This won't work for everything, so quite some renaming may be needed. 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 the FAQ at http://www.tux.org/lkml/
Re: RFC: kconfig select warnings bogus?
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_SUPPORTS_APM_EMULATION' > drivers/net/Kconfig:2283:warning: 'select' used by config symbol 'UCC_GETH' > refers to undefined symbol 'UCC_FAST' > drivers/input/keyboard/Kconfig:170:warning: 'select' used by config symbol > 'KEYBOARD_ATARI' refers to undefined symbol 'ATARI_KBD_CORE' > drivers/input/mouse/Kconfig:182:warning: 'select' used by config symbol > 'MOUSE_ATARI' refers to undefined symbol 'ATARI_KBD_CORE' > > > Do this warning really add any value or should we just ignore them like this? The problem is that a select operation on a non bool/tristate symbol is undefined. A runtime error would probably be even more ignored than this. "Proving" that this select can't be activated is theoretically possible, but not really practical. An alternative might be to reverse the dependency again and let it act like a "depends on". Just removing the warning is definitely not the right answer. 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 the FAQ at http://www.tux.org/lkml/
Re: RFC: kconfig select warnings bogus?
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_SUPPORTS_APM_EMULATION' drivers/net/Kconfig:2283:warning: 'select' used by config symbol 'UCC_GETH' refers to undefined symbol 'UCC_FAST' drivers/input/keyboard/Kconfig:170:warning: 'select' used by config symbol 'KEYBOARD_ATARI' refers to undefined symbol 'ATARI_KBD_CORE' drivers/input/mouse/Kconfig:182:warning: 'select' used by config symbol 'MOUSE_ATARI' refers to undefined symbol 'ATARI_KBD_CORE' Do this warning really add any value or should we just ignore them like this? The problem is that a select operation on a non bool/tristate symbol is undefined. A runtime error would probably be even more ignored than this. Proving that this select can't be activated is theoretically possible, but not really practical. An alternative might be to reverse the dependency again and let it act like a depends on. Just removing the warning is definitely not the right answer. 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 the FAQ at http://www.tux.org/lkml/
Re: kconfig - scan all Kconfig files
Hi, On Sun, 20 May 2007, Sam Ravnborg wrote: I did a quick hack so kconfig could scan all Kconfig files in the kernel tree. By scanning all Kconfig files we gain the following: - kconfig can report when a depends on refer to an undefined symbol - kconfig can report when a select refer to an undefined symbol Later we can push a lot of common stuff to the top-level Kconfig file. And that may in the end result in a better structure overall for Kconfig files. Well, some of that stuff should already happen earlier (and included from the arch Kconfig files), but that doesn't work for everything. I don't think that simply allowing to parse a file multiple times is the right answer, as it duplicates a lot of data. 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. source should become a bit more intelligent and parse a file only once and link the data into the menu structure. All the choice values currently only support a single prompt are caused by using the same config symbol in a choice list for several architectures. That will be the biggest challenge to fix before we can introduce this patch. Maybe we can extend kconfig to accept it??? Define accept. The basic rule for choice values must not be violated - none of them may depend on another value in the same group. The dependency tree allows for no loops, these choice groups allow for the only exception, but it has to stay within that group. One option I'm thinking about is to extend that group by naming the choice option, so kconfig knows they are related. This won't work for everything, so quite some renaming may be needed. 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 the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc2 built on ppc (2)
Hi, On Sun, 20 May 2007, Andrew Morton wrote: On Sun, 20 May 2007 13:08:15 +0200 Elimar Riesebieter [EMAIL PROTECTED] wrote: FYI, building 2.6.22-rc2 with gcc (GCC) 4.1.3 20070514 (prerelease) (Debian 4.1.2-7) on my powerbook (PPC) gives: ... kernel/time/ntp.c: In function 'do_adjtimex': kernel/time/ntp.c:307: warning: comparison of distinct pointer types lacks a cast kernel/time/ntp.c:310: warning: comparison of distinct pointer types lacks a cast hm, do_div() is defined as operating on a u64, but ntp is passing it an s64 and the asm-generic implementation of do_div() is warning about that. Fixing that would be simple but a bit ugly. The correct fix would be to clean up that API and provide a signed do_div(), so ntp doesn't have to work around for the lack of it. It's on my todo list for ages, but I haven't gotten to it yet. 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 the FAQ at http://www.tux.org/lkml/
Re: [RFC] select and dependencies in Kconfig
Hi, On Wed, 16 May 2007, Al Viro wrote: > On Tue, May 15, 2007 at 08:36:20PM +0100, Al Viro wrote: > > > > stuff that does select USB should depend on USB_ARCH_HAS_HCD, or we'll > > end up with unbuildable configs. > > BTW, this kind of situation happens often enough, so how about doing > the following: teach kconfig that if FOO selects BAR and BAR depends > on , we should act as if FOO had explicit depends on . select was really intended to override the dependencies (Russell gave a few examples), the other usage is what is abusing select (I can understand why people are doing it, but it still is). So I'd really like to get the focus away from select and rather see it as a new syntax. One problem with your idea is that a symbol itself has no normal dependencies. A symbol has properties and these have the dependencies, so it's not that easy. What could be used is the visibility value of a symbol of a symbol, but that can't be used in expressions yet. The problem is now being able to select visible and nonvisible symbols. One way is to introduce a new syntax for the behaviour you suggest or we change the current select syntax and mark nonvisible symbols as being selectable. Considering the current problems I sort of like the latter. 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 the FAQ at http://www.tux.org/lkml/
Re: [RFC] select and dependencies in Kconfig
Hi, On Wed, 16 May 2007, Al Viro wrote: On Tue, May 15, 2007 at 08:36:20PM +0100, Al Viro wrote: stuff that does select USB should depend on USB_ARCH_HAS_HCD, or we'll end up with unbuildable configs. BTW, this kind of situation happens often enough, so how about doing the following: teach kconfig that if FOO selects BAR and BAR depends on expr, we should act as if FOO had explicit depends on expr. select was really intended to override the dependencies (Russell gave a few examples), the other usage is what is abusing select (I can understand why people are doing it, but it still is). So I'd really like to get the focus away from select and rather see it as a new syntax. One problem with your idea is that a symbol itself has no normal dependencies. A symbol has properties and these have the dependencies, so it's not that easy. What could be used is the visibility value of a symbol of a symbol, but that can't be used in expressions yet. The problem is now being able to select visible and nonvisible symbols. One way is to introduce a new syntax for the behaviour you suggest or we change the current select syntax and mark nonvisible symbols as being selectable. Considering the current problems I sort of like the latter. 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 the FAQ at http://www.tux.org/lkml/
Re: kconfig: error out if recursive dependencies are found
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 changes, which might be useful to improve the select handling. > But I see that kconfig records file:line for properties and menu entries > but not for symbols. > Any special reason why file:line is omitted for symbols (except size of > allocated > memory)? > > Without looking into details it looks more relevant to have file:line for > symbols > rather than for prompts / properties.. A symbol can have multiple entries. The "config" line is just the start marker for the symbol information, which is the actual relevant part. 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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] WAN Kconfig: change "depends on HDLC" to "select"
Hi, On Mon, 7 May 2007, Jeff Garzik wrote: > Tough, the kernel community has voted against you. > > It makes far more sense to include a driver during kernel configuration, and > have that driver pull in its libraries via 'select'. The lame alternative > requires developers to know which libraries they need BEFORE picking their > drivers, which is backwards and requires legwork on the part of the kernel > developer. Jeff, there was never anything to "vote" about! There is no autoconfiguration, kernel configuration isn't ready for Aunt Tilly and select is no substitute for it... 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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] WAN Kconfig: change "depends on HDLC" to "select"
Hi, On Mon, 7 May 2007, Krzysztof Halasa wrote: > Roman Zippel <[EMAIL PROTECTED]> writes: > > > HDLC doesn't really look like simple library code, what's up with all the > > HDLC_* options? > > Sub-modules. So it's not simple library code, or is it? > Anyway, what does the patch "screw" exactly? Normal dependencies, you basically have to manually make sure they are correct (and it seems with your patch they aren't). Again, _please_ (with sugar on top) don't use select unless you have a good reason for it. 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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] WAN Kconfig: change "depends on HDLC" to "select"
Hi, On Mon, 7 May 2007, Jeff Garzik wrote: > > select seriously screws with the dependencies, it's especially problematic > > if the selected symbol has other dependencies as HDLC in this case, it makes > > it only more complicated to get the dependencies correct again. > > Please use it only if it solves a real problem. > > What he's doing is the standard way to deal with library-style code. Nothing > wrong with the patch, it's continuing established methods. select was never meant as autoconfiguration tool. It can't be said often enough: select seriously screws with the dependencies, _please_ don't use it as a simple depends replacement. HDLC doesn't really look like simple library code, what's up with all the HDLC_* options? 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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] WAN Kconfig: change "depends on HDLC" to "select"
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, it makes it only more complicated to get the dependencies correct again. Please use it only if it solves a real problem. 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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] WAN Kconfig: change "depends on HDLC" to "select"
Hi, On Mon, 7 May 2007, Krzysztof Halasa wrote: > Roman Zippel <[EMAIL PROTECTED]> writes: > > > What's the advantage? The HDLC option is directly before this? > > You don't have to know it's required, you can just select a driver > for your hardware, without enabling HDLC first. Is this a real problem? Using select you should also consider removing HDLC as visible option and use only select. Mixing depends and selects is generally a bad idea. 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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] WAN Kconfig: change depends on HDLC to select
Hi, On Mon, 7 May 2007, Krzysztof Halasa wrote: Roman Zippel [EMAIL PROTECTED] writes: HDLC doesn't really look like simple library code, what's up with all the HDLC_* options? Sub-modules. So it's not simple library code, or is it? Anyway, what does the patch screw exactly? Normal dependencies, you basically have to manually make sure they are correct (and it seems with your patch they aren't). Again, _please_ (with sugar on top) don't use select unless you have a good reason for it. 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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] WAN Kconfig: change depends on HDLC to select
Hi, On Mon, 7 May 2007, Jeff Garzik wrote: Tough, the kernel community has voted against you. It makes far more sense to include a driver during kernel configuration, and have that driver pull in its libraries via 'select'. The lame alternative requires developers to know which libraries they need BEFORE picking their drivers, which is backwards and requires legwork on the part of the kernel developer. Jeff, there was never anything to vote about! There is no autoconfiguration, kernel configuration isn't ready for Aunt Tilly and select is no substitute for it... 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 the FAQ at http://www.tux.org/lkml/
Re: kconfig: error out if recursive dependencies are found
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 changes, which might be useful to improve the select handling. But I see that kconfig records file:line for properties and menu entries but not for symbols. Any special reason why file:line is omitted for symbols (except size of allocated memory)? Without looking into details it looks more relevant to have file:line for symbols rather than for prompts / properties.. A symbol can have multiple entries. The config line is just the start marker for the symbol information, which is the actual relevant part. 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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] WAN Kconfig: change depends on HDLC to select
Hi, On Mon, 7 May 2007, Krzysztof Halasa wrote: Roman Zippel [EMAIL PROTECTED] writes: What's the advantage? The HDLC option is directly before this? You don't have to know it's required, you can just select a driver for your hardware, without enabling HDLC first. Is this a real problem? Using select you should also consider removing HDLC as visible option and use only select. Mixing depends and selects is generally a bad idea. 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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] WAN Kconfig: change depends on HDLC to select
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, it makes it only more complicated to get the dependencies correct again. Please use it only if it solves a real problem. 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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] WAN Kconfig: change depends on HDLC to select
Hi, On Mon, 7 May 2007, Jeff Garzik wrote: select seriously screws with the dependencies, it's especially problematic if the selected symbol has other dependencies as HDLC in this case, it makes it only more complicated to get the dependencies correct again. Please use it only if it solves a real problem. What he's doing is the standard way to deal with library-style code. Nothing wrong with the patch, it's continuing established methods. select was never meant as autoconfiguration tool. It can't be said often enough: select seriously screws with the dependencies, _please_ don't use it as a simple depends replacement. HDLC doesn't really look like simple library code, what's up with all the HDLC_* options? 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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] WAN Kconfig: change "depends on HDLC" to "select"
Hi, On Mon, 7 May 2007, Krzysztof Halasa wrote: > Allow enabling WAN drivers without selecting generic HDLC first, > HDLC will be selected automatically. > > Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]> > > diff --git a/drivers/net/wan/Kconfig b/drivers/net/wan/Kconfig > index 8897f53..3a2fe82 100644 > --- a/drivers/net/wan/Kconfig > +++ b/drivers/net/wan/Kconfig > @@ -171,7 +171,8 @@ comment "X.25/LAPB support is disabled" > > config PCI200SYN > tristate "Goramo PCI200SYN support" > - depends on HDLC && PCI > + depends on PCI > + select HDLC > help > Driver for PCI200SYN cards by Goramo sp. j. > What's the advantage? The HDLC option is directly before this? 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 the FAQ at http://www.tux.org/lkml/
Re: kconfig: error out if recursive dependencies are found
Hi,
On Sun, 6 May 2007, Sam Ravnborg wrote:
> if (sym->flags & SYMBOL_CHECK) {
> - printf("Warning! Found recursive dependency: %s", sym->name);
> + fprintf(stderr, "%s:%d:error: found recursive dependency: %s",
> + sym->prop->file->name, sym->prop->lineno, sym->name);
> return sym;
> }
If it were that simple to print the location, I had done it already. :)
Try this:
config FOO
bool
select BAR
depends on BAR
config BAR
bool
I looked into this before, for simple properties one could just remember
the last checked property via a static variable. The problem are the
selects which are checked before that loop, here the information from
where they were selected is not available anymore (at least not easily).
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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH] m68k: needs
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-m68k-2.6.21.orig/include/asm-m68k/scatterlist.h > +++ linux-m68k-2.6.21/include/asm-m68k/scatterlist.h > @@ -1,6 +1,8 @@ > #ifndef _M68K_SCATTERLIST_H > #define _M68K_SCATTERLIST_H > > +#include > + Unless required otherwise please use 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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH] m68k: asm/scatterlist.h needs asm/types.h
Hi, On Sun, 6 May 2007, Geert Uytterhoeven wrote: The recent linux/pci.h cleanup uncovered that include/asm-m68k/scatterlist.h needs to include asm/types.h Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED] --- include/asm-m68k/scatterlist.h |2 ++ 1 file changed, 2 insertions(+) --- linux-m68k-2.6.21.orig/include/asm-m68k/scatterlist.h +++ linux-m68k-2.6.21/include/asm-m68k/scatterlist.h @@ -1,6 +1,8 @@ #ifndef _M68K_SCATTERLIST_H #define _M68K_SCATTERLIST_H +#include asm/types.h + Unless required otherwise please use linux/types.h 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 the FAQ at http://www.tux.org/lkml/
Re: kconfig: error out if recursive dependencies are found
Hi,
On Sun, 6 May 2007, Sam Ravnborg wrote:
if (sym-flags SYMBOL_CHECK) {
- printf(Warning! Found recursive dependency: %s, sym-name);
+ fprintf(stderr, %s:%d:error: found recursive dependency: %s,
+ sym-prop-file-name, sym-prop-lineno, sym-name);
return sym;
}
If it were that simple to print the location, I had done it already. :)
Try this:
config FOO
bool
select BAR
depends on BAR
config BAR
bool
I looked into this before, for simple properties one could just remember
the last checked property via a static variable. The problem are the
selects which are checked before that loop, here the information from
where they were selected is not available anymore (at least not easily).
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 the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] WAN Kconfig: change depends on HDLC to select
Hi, On Mon, 7 May 2007, Krzysztof Halasa wrote: Allow enabling WAN drivers without selecting generic HDLC first, HDLC will be selected automatically. Signed-off-by: Krzysztof Halasa [EMAIL PROTECTED] diff --git a/drivers/net/wan/Kconfig b/drivers/net/wan/Kconfig index 8897f53..3a2fe82 100644 --- a/drivers/net/wan/Kconfig +++ b/drivers/net/wan/Kconfig @@ -171,7 +171,8 @@ comment X.25/LAPB support is disabled config PCI200SYN tristate Goramo PCI200SYN support - depends on HDLC PCI + depends on PCI + select HDLC help Driver for PCI200SYN cards by Goramo sp. j. What's the advantage? The HDLC option is directly before this? 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 the FAQ at http://www.tux.org/lkml/
Re: [v4l-dvb-maintainer] [PATCH 35/36] Use menuconfig objects II - DVB
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 layout of the menu tree and jump directly to any menu (even one > > multiple levels deep). All the menuconfigs that used to be menus don't show > > up here anymore. > > > > To turn a menuconfig off, you must go to the top level menu containing the > > menuconfig you want (and you must know which one that is!). Then you have > > to > > drill down through each menu level one by one, by finding that menu in the > > top > > panel (which also has all the config options listed) and clicking on it to > > get > > to the next one. When you get to the menuconfig you want, you must enter it > > and then you finally get the box to turn that menuconfig off. > > > > It looks like your changes are going in, so I suppose the solution is to > > improve the way xconfig handles "menuconfig". I don't quite understand. With the menuconfig changes more menu entries should appear on the left side, so I don't understand why you have to "drill down" to reach it. The rule for menu to appear on the left side is relatively simple - all its parents must be of menu type as well. So if a menuconfig is on the right side it must have a normal config entry as parent. > > I wonder, would it be possible to change the kconfig language so that: > > menuconfig > > boolean "name of menu" > > > > Did the same thing as: > > config > > boolean "name of menu" > > menu "name of menu" > > depends on > > > > This way you could change this: > > > > menuconfig > > if > > [all the other options] > > endif > > > > Into this: > > > > menuconfig > > [all the other options] > > endmenu > > > > The reason is that a frontend would easily be able to understand the > > coupling > > between the "menuconfig " and the "if ". It will make it easier for > > the frontend to see that all the options are inside and controlled by the > > enclosing menuconfig. If the frontend wants to change the behaviour of a menuconfig, it can already do that, so this doesn't require a syntax change. 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 the FAQ at http://www.tux.org/lkml/
