SPARC{,64}: kernel_termios_to_user_termios_1 missing
git-describe says this is v2.6.23-rc6-168-g53a3f30 I'm getting: drivers/char/tty_ioctl.c: In function 'n_tty_ioctl': drivers/char/tty_ioctl.c:799: error: implicit declaration of function 'kernel_termios_to_user_termios_1' This is a macro at the very end of include/asm-/termios.h for i686, on SPARC and SPARC64 it is missing. Sorry, I've got no clue on how to define this correctly here. It is also missing on alpha, blackfin, parisc, sh64, sh, xtensa -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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/
SPARC{,64}: kernel_termios_to_user_termios_1 missing
git-describe says this is v2.6.23-rc6-168-g53a3f30 I'm getting: drivers/char/tty_ioctl.c: In function 'n_tty_ioctl': drivers/char/tty_ioctl.c:799: error: implicit declaration of function 'kernel_termios_to_user_termios_1' This is a macro at the very end of include/asm-foo/termios.h for i686, on SPARC and SPARC64 it is missing. Sorry, I've got no clue on how to define this correctly here. It is also missing on alpha, blackfin, parisc, sh64, sh, xtensa -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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/
sparc64: ERROR: "sys_ioctl" [arch/sparc64/solaris/solaris.ko] undefined!
# CONFIG_DEBUG_INFO is not set # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_LIST is not set CONFIG_FRAME_POINTER=y CONFIG_FORCED_INLINING=y # CONFIG_RCU_TORTURE_TEST is not set # CONFIG_FAULT_INJECTION is not set CONFIG_DEBUG_STACK_USAGE=y # CONFIG_DEBUG_DCFLUSH is not set # CONFIG_STACK_DEBUG is not set # CONFIG_DEBUG_BOOTMEM is not set # CONFIG_DEBUG_PAGEALLOC is not set # # Security options # # CONFIG_KEYS is not set CONFIG_SECURITY=y CONFIG_SECURITY_NETWORK=y CONFIG_SECURITY_NETWORK_XFRM=y CONFIG_SECURITY_CAPABILITIES=y CONFIG_SECURITY_SELINUX=y CONFIG_SECURITY_SELINUX_BOOTPARAM=y CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1 CONFIG_SECURITY_SELINUX_DISABLE=y CONFIG_SECURITY_SELINUX_DEVELOP=y CONFIG_SECURITY_SELINUX_AVC_STATS=y CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1 CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT=y # CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set CONFIG_XOR_BLOCKS=m CONFIG_ASYNC_CORE=m CONFIG_ASYNC_MEMCPY=m CONFIG_ASYNC_XOR=m CONFIG_CRYPTO=y CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_ABLKCIPHER=m CONFIG_CRYPTO_BLKCIPHER=m CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_XCBC=m CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_WP512=m CONFIG_CRYPTO_TGR192=m CONFIG_CRYPTO_GF128MUL=m CONFIG_CRYPTO_ECB=m CONFIG_CRYPTO_CBC=m CONFIG_CRYPTO_PCBC=m CONFIG_CRYPTO_LRW=m CONFIG_CRYPTO_CRYPTD=m CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_FCRYPT=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_TWOFISH_COMMON=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_TEA=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_KHAZAD=m CONFIG_CRYPTO_ANUBIS=m CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_MICHAEL_MIC=m CONFIG_CRYPTO_CRC32C=m CONFIG_CRYPTO_CAMELLIA=m CONFIG_CRYPTO_TEST=m CONFIG_CRYPTO_HW=y # # Library routines # CONFIG_BITREVERSE=y CONFIG_CRC_CCITT=m CONFIG_CRC16=m CONFIG_CRC_ITU_T=m CONFIG_CRC32=y CONFIG_CRC7=m CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=m CONFIG_ZLIB_DEFLATE=m CONFIG_TEXTSEARCH=y CONFIG_TEXTSEARCH_KMP=m CONFIG_TEXTSEARCH_BM=m CONFIG_TEXTSEARCH_FSM=m CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
sparc64: ERROR: sys_ioctl [arch/sparc64/solaris/solaris.ko] undefined!
CONFIG_FRAME_POINTER=y CONFIG_FORCED_INLINING=y # CONFIG_RCU_TORTURE_TEST is not set # CONFIG_FAULT_INJECTION is not set CONFIG_DEBUG_STACK_USAGE=y # CONFIG_DEBUG_DCFLUSH is not set # CONFIG_STACK_DEBUG is not set # CONFIG_DEBUG_BOOTMEM is not set # CONFIG_DEBUG_PAGEALLOC is not set # # Security options # # CONFIG_KEYS is not set CONFIG_SECURITY=y CONFIG_SECURITY_NETWORK=y CONFIG_SECURITY_NETWORK_XFRM=y CONFIG_SECURITY_CAPABILITIES=y CONFIG_SECURITY_SELINUX=y CONFIG_SECURITY_SELINUX_BOOTPARAM=y CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1 CONFIG_SECURITY_SELINUX_DISABLE=y CONFIG_SECURITY_SELINUX_DEVELOP=y CONFIG_SECURITY_SELINUX_AVC_STATS=y CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1 CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT=y # CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set CONFIG_XOR_BLOCKS=m CONFIG_ASYNC_CORE=m CONFIG_ASYNC_MEMCPY=m CONFIG_ASYNC_XOR=m CONFIG_CRYPTO=y CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_ABLKCIPHER=m CONFIG_CRYPTO_BLKCIPHER=m CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_XCBC=m CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_WP512=m CONFIG_CRYPTO_TGR192=m CONFIG_CRYPTO_GF128MUL=m CONFIG_CRYPTO_ECB=m CONFIG_CRYPTO_CBC=m CONFIG_CRYPTO_PCBC=m CONFIG_CRYPTO_LRW=m CONFIG_CRYPTO_CRYPTD=m CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_FCRYPT=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_TWOFISH_COMMON=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_TEA=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_KHAZAD=m CONFIG_CRYPTO_ANUBIS=m CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_MICHAEL_MIC=m CONFIG_CRYPTO_CRC32C=m CONFIG_CRYPTO_CAMELLIA=m CONFIG_CRYPTO_TEST=m CONFIG_CRYPTO_HW=y # # Library routines # CONFIG_BITREVERSE=y CONFIG_CRC_CCITT=m CONFIG_CRC16=m CONFIG_CRC_ITU_T=m CONFIG_CRC32=y CONFIG_CRC7=m CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=m CONFIG_ZLIB_DEFLATE=m CONFIG_TEXTSEARCH=y CONFIG_TEXTSEARCH_KMP=m CONFIG_TEXTSEARCH_BM=m CONFIG_TEXTSEARCH_FSM=m CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
Compile failure with v9fs
The following patch deletes an assignment to the variable p9_debug_level, which is never defined and isn't used anywhere else I can see. - 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/
[PATCH] fs/9p/v9fs.c: Delete unused p9_debug_level setting
From: Horst H. von Brand <[EMAIL PROTECTED]>
Signed-off-by: Horst H. von Brand <[EMAIL PROTECTED]>
---
fs/9p/v9fs.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/fs/9p/v9fs.c b/fs/9p/v9fs.c
index 45c3598..72ad365 100644
--- a/fs/9p/v9fs.c
+++ b/fs/9p/v9fs.c
@@ -131,7 +131,6 @@ static void v9fs_parse_options(char *options, struct
v9fs_session_info *v9ses)
switch (token) {
case Opt_debug:
v9ses->debug = option;
- p9_debug_level = option;
break;
case Opt_port:
v9ses->port = option;
--
1.5.2.3
-
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/
[PATCH] fs/9p/v9fs.c: Delete unused p9_debug_level setting
From: Horst H. von Brand [EMAIL PROTECTED]
Signed-off-by: Horst H. von Brand [EMAIL PROTECTED]
---
fs/9p/v9fs.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/fs/9p/v9fs.c b/fs/9p/v9fs.c
index 45c3598..72ad365 100644
--- a/fs/9p/v9fs.c
+++ b/fs/9p/v9fs.c
@@ -131,7 +131,6 @@ static void v9fs_parse_options(char *options, struct
v9fs_session_info *v9ses)
switch (token) {
case Opt_debug:
v9ses-debug = option;
- p9_debug_level = option;
break;
case Opt_port:
v9ses-port = option;
--
1.5.2.3
-
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/
Compile failure with v9fs
The following patch deletes an assignment to the variable p9_debug_level, which is never defined and isn't used anywhere else I can see. - 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: [Announce] GIT v1.5.0-rc2
Junio C Hamano <[EMAIL PROTECTED]> wrote: > BTW, as the upcoming v1.5.0 release will introduce quite a bit of > surface changes (although at the really core it still is the old > git and old ways should continue to work), I am wondering if it > would help people to try out and find wrinkles before the real > thing for me to cut a tarball and a set of RPM packages. > > Comments? > > Also, in the same spirit of giving the release an early > exposure, here is the current draft of 1.5.0 release notes. > > -- >8 -- cut here -- >8 -- > > GIT v1.5.0 Release Notes (draft) > > > Old news > [...] > - There is a configuration variable core.legacyheaders that >changes the format of loose objects so that they are more >efficient to pack and to send out of the repository over git >native protocol, since v1.4.2. However, loose objects >written in the new format cannot be read by git older than >that version; people fetching from your repository using >older clients over dumb transports (e.g. http) using older >versions of git will also be affected. Huh? What are possible values of that variable? What happens if it is set/unset? I'd suppose that if it is set, you get the old format, but that isn't clear. > - Since v1.4.3, configuration repack.usedeltabaseoffset allows >packfile to be created in more space efficient format, which >cannot be read by git older than that version. Same as above. > The above two are not enabled by default and you explicitly have > to ask for them, because these two features make repositories > unreadable by older versions of git, and in v1.5.0 we still do > not enable them by default for the same reason. We will change > this default probably 1 year after 1.4.2's release, when it is > reasonable to expect everybody to have new enough version of > git. I don't see an upgrade path here that doesn't involve keeping cruft "new feature is on" variables around indefinitely... Why not just a repository version? [...] > Updates in v1.5.0 since v1.4.4 series > - > > * Index manipulation [...] > - git-add without any argument does not add everything >anymore. Use 'git-add .' instead. Also you can add >otherwise ignored files with an -f option. I suppose "git add ." works for 'adding everything' only at the top? > - git-add tries to be more friendly to users by offering an >interactive mode. Why not tell about "git add -i"? [...] > * Detached HEAD [...] > - After detaching your HEAD, you can go back to an existing >branch with usual "git checkout $branch". Also you can >start a new branch using "git checkout -b $newbranch". Where is such a branch rooted? > - You can even pull from other repositories, make merges and >commits while your HEAD is detached. Also you can use "git >reset" to jump to arbitrary commit. Does this leave you on that branch, or still in limbo? >Going back to undetached state by "git checkout $branch" can s/undetached/attached/ >lose the current stat you arrived in these ways, and "git >checkout" refuses when the detached HEAD is not pointed by >any existing ref (an existing branch, a remote tracking >branch or a tag). This safety can be overriden with "git >checkout -f $branch". What happens if there are changes in the tracked files? [...] > * Shallow clones > > - There is a partial support for 'shallow' repositories that >keeps only recent history. A 'shallow clone' is created by >specifying how deep that truncated history should be. A bit of detail on how to specify shallowness would be nice here... Very nice work, thanks! -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: [Announce] GIT v1.5.0-rc2
Junio C Hamano <[EMAIL PROTECTED]> wrote: > Willy Tarreau <[EMAIL PROTECTED]> writes: > > Anything you can do to make tester's life easier will always slightly > > increase the number of testers. > > ... > > Pre-release tar.gz and rpms coupled with a freshmeat announcement should > > get you a bunch of testers and newcomers. This will give the new doc a > > real trial, and will help discover traps in which beginners often fall. > > One worry I had about releasing git-1.5.0-rc2-1.rpm and friends > just like the "official" ones was that people might have scripts > to automate downloading & updating of packages, and they may not > like to get "beta" installed for them. Then put them into a "testing" or "pre-release" directory... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: [Announce] GIT v1.5.0-rc2
Junio C Hamano [EMAIL PROTECTED] wrote: Willy Tarreau [EMAIL PROTECTED] writes: Anything you can do to make tester's life easier will always slightly increase the number of testers. ... Pre-release tar.gz and rpms coupled with a freshmeat announcement should get you a bunch of testers and newcomers. This will give the new doc a real trial, and will help discover traps in which beginners often fall. One worry I had about releasing git-1.5.0-rc2-1.rpm and friends just like the official ones was that people might have scripts to automate downloading updating of packages, and they may not like to get beta installed for them. Then put them into a testing or pre-release directory... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: [Announce] GIT v1.5.0-rc2
Junio C Hamano [EMAIL PROTECTED] wrote: BTW, as the upcoming v1.5.0 release will introduce quite a bit of surface changes (although at the really core it still is the old git and old ways should continue to work), I am wondering if it would help people to try out and find wrinkles before the real thing for me to cut a tarball and a set of RPM packages. Comments? Also, in the same spirit of giving the release an early exposure, here is the current draft of 1.5.0 release notes. -- 8 -- cut here -- 8 -- GIT v1.5.0 Release Notes (draft) Old news [...] - There is a configuration variable core.legacyheaders that changes the format of loose objects so that they are more efficient to pack and to send out of the repository over git native protocol, since v1.4.2. However, loose objects written in the new format cannot be read by git older than that version; people fetching from your repository using older clients over dumb transports (e.g. http) using older versions of git will also be affected. Huh? What are possible values of that variable? What happens if it is set/unset? I'd suppose that if it is set, you get the old format, but that isn't clear. - Since v1.4.3, configuration repack.usedeltabaseoffset allows packfile to be created in more space efficient format, which cannot be read by git older than that version. Same as above. The above two are not enabled by default and you explicitly have to ask for them, because these two features make repositories unreadable by older versions of git, and in v1.5.0 we still do not enable them by default for the same reason. We will change this default probably 1 year after 1.4.2's release, when it is reasonable to expect everybody to have new enough version of git. I don't see an upgrade path here that doesn't involve keeping cruft new feature is on variables around indefinitely... Why not just a repository version? [...] Updates in v1.5.0 since v1.4.4 series - * Index manipulation [...] - git-add without any argument does not add everything anymore. Use 'git-add .' instead. Also you can add otherwise ignored files with an -f option. I suppose git add . works for 'adding everything' only at the top? - git-add tries to be more friendly to users by offering an interactive mode. Why not tell about git add -i? [...] * Detached HEAD [...] - After detaching your HEAD, you can go back to an existing branch with usual git checkout $branch. Also you can start a new branch using git checkout -b $newbranch. Where is such a branch rooted? - You can even pull from other repositories, make merges and commits while your HEAD is detached. Also you can use git reset to jump to arbitrary commit. Does this leave you on that branch, or still in limbo? Going back to undetached state by git checkout $branch can s/undetached/attached/ lose the current stat you arrived in these ways, and git checkout refuses when the detached HEAD is not pointed by any existing ref (an existing branch, a remote tracking branch or a tag). This safety can be overriden with git checkout -f $branch. What happens if there are changes in the tracked files? [...] * Shallow clones - There is a partial support for 'shallow' repositories that keeps only recent history. A 'shallow clone' is created by specifying how deep that truncated history should be. A bit of detail on how to specify shallowness would be nice here... Very nice work, thanks! -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: heavy nfs[4]] causes fs badness Was: 2.6.20-rc4: known unfixed regressions (v2)
Florin Iucha <[EMAIL PROTECTED]> wrote: [...] > Based on this info, I think we can rule out any USB. I will try > testing with NFS3 to see if the problem persists. Unfortunately there > is no oops or anything in "dmesg". Take a look at bz #7796, a NFS bug + fix. But my feelin is that this is older. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: heavy nfs[4]] causes fs badness Was: 2.6.20-rc4: known unfixed regressions (v2)
Florin Iucha [EMAIL PROTECTED] wrote: [...] Based on this info, I think we can rule out any USB. I will try testing with NFS3 to see if the problem persists. Unfortunately there is no oops or anything in dmesg. Take a look at bz #7796, a NFS bug + fix. But my feelin is that this is older. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: Jumping into Kernel development: About -rc kernels...
Akula2 <[EMAIL PROTECTED]> wrote: > This question might sound dumb for many, and to some annoying too ;-) It's OK if you don't do it too often ;-) [...] > I did understand till here. Should I start compile/test/debug > one-after-one in this fashion:- > > 2.6.19 source + patch-2.6.20-rc1 > 2.6.19 source + patch-2.6.20-rc2 > 2.6.19 source + patch-2.6.20-rc3 > 2.6.19 source + patch-2.6.20-rc4 > > OR > > Pick the latest release number? Pick the latest, it has bugs in earlier ones fixed. But it might have its own ;-) BTW, you can track the day-to-day development of the kernel (and other stuff) using git, which has other nifty features (like being able to go back to an earlier version, and even automate the finding of the broken patch by narrowing down from a known good and a known bad version). git is probably in your distribution, or you can get it (as source, or prebuilt) from <http://kernel.org/pub/software/scm/git>, a bunch of documentation is in the package itself or at <http://www.git.or.cz>. <http://www.kernel.org> gives pointers to several git kernel repositories. Good luck! -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: Jumping into Kernel development: About -rc kernels...
Akula2 [EMAIL PROTECTED] wrote: This question might sound dumb for many, and to some annoying too ;-) It's OK if you don't do it too often ;-) [...] I did understand till here. Should I start compile/test/debug one-after-one in this fashion:- 2.6.19 source + patch-2.6.20-rc1 2.6.19 source + patch-2.6.20-rc2 2.6.19 source + patch-2.6.20-rc3 2.6.19 source + patch-2.6.20-rc4 OR Pick the latest release number? Pick the latest, it has bugs in earlier ones fixed. But it might have its own ;-) BTW, you can track the day-to-day development of the kernel (and other stuff) using git, which has other nifty features (like being able to go back to an earlier version, and even automate the finding of the broken patch by narrowing down from a known good and a known bad version). git is probably in your distribution, or you can get it (as source, or prebuilt) from http://kernel.org/pub/software/scm/git, a bunch of documentation is in the package itself or at http://www.git.or.cz. http://www.kernel.org gives pointers to several git kernel repositories. Good luck! -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: [ANNOUNCE] GIT 1.4.4.4
Junio C Hamano <[EMAIL PROTECTED]> wrote:
> The latest maintenance release GIT 1.4.4.4 is available at the
> usual places:
>
> http://www.kernel.org/pub/software/scm/git/
>
> git-1.4.4.4.tar.{gz,bz2}(tarball)
> git-htmldocs-1.4.4.4.tar.{gz,bz2} (preformatted docs)
> git-manpages-1.4.4.4.tar.{gz,bz2} (preformatted docs)
> RPMS/$arch/git-*-1.4.4.4-1.$arch.rpm(RPM)
>
> This is to push out a handful bugfixes since 1.4.4.3.
>
> On the 'master' development front, the stabilization for v1.5.0
> will start soonish.
I get git version 1.4.4.4.g9a5e4 (used to be 1.5.0.rc0.gXXXX) on the msater
branch now?
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de InformaticaFono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
-
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: [ANNOUNCE] GIT 1.4.4.4
Junio C Hamano [EMAIL PROTECTED] wrote:
The latest maintenance release GIT 1.4.4.4 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.4.4.4.tar.{gz,bz2}(tarball)
git-htmldocs-1.4.4.4.tar.{gz,bz2} (preformatted docs)
git-manpages-1.4.4.4.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.4.4.4-1.$arch.rpm(RPM)
This is to push out a handful bugfixes since 1.4.4.3.
On the 'master' development front, the stabilization for v1.5.0
will start soonish.
I get git version 1.4.4.4.g9a5e4 (used to be 1.5.0.rc0.g) on the msater
branch now?
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de InformaticaFono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
-
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: OT: character encodings (was: Linux 2.6.20-rc4)
Russell King <[EMAIL PROTECTED]> wrote: [...] > All that UTF-8 has done is added to the "which charset is this data" > problem rather than actually solving any proper real life problem. It solves real-world problems, the pain is that it is not (yet) universally used. The charset problems today are much more visible today than, say, 15 years back, that is all. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: OT: character encodings (was: Linux 2.6.20-rc4)
Russell King [EMAIL PROTECTED] wrote: [...] All that UTF-8 has done is added to the which charset is this data problem rather than actually solving any proper real life problem. It solves real-world problems, the pain is that it is not (yet) universally used. The charset problems today are much more visible today than, say, 15 years back, that is all. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: [ANNOUNCE] Guilt 0.16
Josef Sipek <[EMAIL PROTECTED]> wrote: > Guilt (Git Quilt) is a series of bash scripts which add a Mercurial > queues-like [1] functionality and interface to git. The one distinguishing > feature from other quilt-like porcelains, is the format of the patches > directory. _All_ the information is stored as plain text - a series file and > the patches (one per file). This easily lends itself to versioning the > patches using any number of of SCMs. A installation script/Makefile (or at least instructions) is missing... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: [ANNOUNCE] Guilt 0.16
Josef Sipek [EMAIL PROTECTED] wrote: Guilt (Git Quilt) is a series of bash scripts which add a Mercurial queues-like [1] functionality and interface to git. The one distinguishing feature from other quilt-like porcelains, is the format of the patches directory. _All_ the information is stored as plain text - a series file and the patches (one per file). This easily lends itself to versioning the patches using any number of of SCMs. A installation script/Makefile (or at least instructions) is missing... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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.20-rc3: known unfixed regressions (v3)
Adrian Bunk <[EMAIL PROTECTED]> wrote: > This email lists some known regressions in 2.6.20-rc3 compared to 2.6.19 > that are not yet fixed in Linus' tree. > > If you find your name in the Cc header, you are either submitter of one > of the bugs, maintainer of an affectected subsystem or driver, a patch > of you caused a breakage or I'm considering you in any other way possibly > involved with one or more of these issues. > > Due to the huge amount of recipients, please trim the Cc when answering. [...] > Subject: SPARC64: Can't mount / (CONFIG_SCSI_SCAN_ASYNC=y ?) > References : http://lkml.org/lkml/2006/12/13/181 > http://lkml.org/lkml/2007/01/04/75 > Submitter : Horst H. von Brand <[EMAIL PROTECTED]> > Status : unknown Fixed in 2.6.20-rc3 (perhaps was due to SCSI_SCAN_ASYNC) -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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.20-rc3: known unfixed regressions (v2)
Adrian Bunk <[EMAIL PROTECTED]> wrote: > This email lists some known regressions in 2.6.20-rc3 compared to 2.6.19 > that are not yet fixed in Linus' tree. > > If you find your name in the Cc header, you are either submitter of one > of the bugs, maintainer of an affectected subsystem or driver, a patch > of you caused a breakage or I'm considering you in any other way possibly > involved with one or more of these issues. > > Due to the huge amount of recipients, please trim the Cc when answering. I hope I cut it down sensibly... [...] > Subject: SPARC64: Can't mount / > References : http://lkml.org/lkml/2006/12/13/181 > Submitter : Horst H. von Brand <[EMAIL PROTECTED]> > Status : unknown Works for me now with 2.6.20-rc3. Might have been some form of pilot error (perhaps setting SCSI_TGT=m and/or SCSI_SCAN_ASYNC=y, I unset them for the current trial run). I see CONFIG_SCSI_SCAN_ASYNC introduced in 21db1882f79a1ad5977cae6766376a63f60ec414 ([SCSI] Add Kconfig option for asynchronous SCSI scanning). If this is the cause, the override provided: scsi_mod.scan="sync" seems not to work. Are the '"' necessary? How do you give them via silo, which in its configuration file for strings with spaces uses: append="some string here" How do you say '"'? The silo documentation is silent on this. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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.20-rc3: known unfixed regressions (v2)
Adrian Bunk [EMAIL PROTECTED] wrote: This email lists some known regressions in 2.6.20-rc3 compared to 2.6.19 that are not yet fixed in Linus' tree. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. I hope I cut it down sensibly... [...] Subject: SPARC64: Can't mount / References : http://lkml.org/lkml/2006/12/13/181 Submitter : Horst H. von Brand [EMAIL PROTECTED] Status : unknown Works for me now with 2.6.20-rc3. Might have been some form of pilot error (perhaps setting SCSI_TGT=m and/or SCSI_SCAN_ASYNC=y, I unset them for the current trial run). I see CONFIG_SCSI_SCAN_ASYNC introduced in 21db1882f79a1ad5977cae6766376a63f60ec414 ([SCSI] Add Kconfig option for asynchronous SCSI scanning). If this is the cause, the override provided: scsi_mod.scan=sync seems not to work. Are the '' necessary? How do you give them via silo, which in its configuration file for strings with spaces uses: append=some string here How do you say ''? The silo documentation is silent on this. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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.20-rc3: known unfixed regressions (v3)
Adrian Bunk [EMAIL PROTECTED] wrote: This email lists some known regressions in 2.6.20-rc3 compared to 2.6.19 that are not yet fixed in Linus' tree. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. [...] Subject: SPARC64: Can't mount / (CONFIG_SCSI_SCAN_ASYNC=y ?) References : http://lkml.org/lkml/2006/12/13/181 http://lkml.org/lkml/2007/01/04/75 Submitter : Horst H. von Brand [EMAIL PROTECTED] Status : unknown Fixed in 2.6.20-rc3 (perhaps was due to SCSI_SCAN_ASYNC) -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: kernel + gcc 4.1 = several problems
D. Hazelton <[EMAIL PROTECTED]> wrote: [...] > None. I didn't file a report on this because I didn't find the big, just > noted a problem that appears to occur. In this case the call's generated > seem to wrap loops - something I've never heard of anyone doing. Example code showing this weirdness? > These > *might* be causing the off-by-one that is causing the function to > re-enter in the middle of an instruction. If something like this happened, programs would be crashing left and right. > Seeing this I'd guess that this follows for all system-level code > generated by 4.1.1 Define "system-level code". What makes it different from, say, bog-of-the-mill compiler code (yes, gcc compiles itself as part of its sanity checking)? >and this is exactly what I was reporting. If you'd > like I'll go dig up the dumps he posted and post the two related segments > side-by-side to give you a better example what I'm referring to. If the related segments show code that is somehow wrong, by all means report it /with your detailed analysis/ to the compiler people. Just a warning, gcc is pretty smart in what it does, its code is often surprising to the unwashed. Also, the C standard is subtle, the error might be in a unwarranted assumption in the source code. - 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: Open letter to Linux kernel developers (was Re: Binary Drivers)
Bernd Petrovitsch <[EMAIL PROTECTED]> wrote: [...] > I don't know about others but I wouldn't write an offer with a fixed > price for "look into assembler dumps, reverse engineer it and find an > infringement on a list of given patents" so the patent holder has to > list the patents and the amount of my time to invest (and then he will > get a price for it and no guarantees of success). And them you'd have to testify (as an expert witness, AFAIU). Having legally demostrable expertise in the area isn't easy, I suppose. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: Open letter to Linux kernel developers (was Re: Binary Drivers)
Bernd Petrovitsch [EMAIL PROTECTED] wrote: [...] I don't know about others but I wouldn't write an offer with a fixed price for look into assembler dumps, reverse engineer it and find an infringement on a list of given patents so the patent holder has to list the patents and the amount of my time to invest (and then he will get a price for it and no guarantees of success). And them you'd have to testify (as an expert witness, AFAIU). Having legally demostrable expertise in the area isn't easy, I suppose. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: kernel + gcc 4.1 = several problems
D. Hazelton [EMAIL PROTECTED] wrote: [...] None. I didn't file a report on this because I didn't find the big, just noted a problem that appears to occur. In this case the call's generated seem to wrap loops - something I've never heard of anyone doing. Example code showing this weirdness? These *might* be causing the off-by-one that is causing the function to re-enter in the middle of an instruction. If something like this happened, programs would be crashing left and right. Seeing this I'd guess that this follows for all system-level code generated by 4.1.1 Define system-level code. What makes it different from, say, bog-of-the-mill compiler code (yes, gcc compiles itself as part of its sanity checking)? and this is exactly what I was reporting. If you'd like I'll go dig up the dumps he posted and post the two related segments side-by-side to give you a better example what I'm referring to. If the related segments show code that is somehow wrong, by all means report it /with your detailed analysis/ to the compiler people. Just a warning, gcc is pretty smart in what it does, its code is often surprising to the unwashed. Also, the C standard is subtle, the error might be in a unwarranted assumption in the source code. - 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.20-rc2: known unfixed regressions
Adrian Bunk <[EMAIL PROTECTED]> wrote: [...] > Subject: BUG at fs/buffer.c:1235 when using gdb > References : http://lkml.org/lkml/2006/12/17/134 > Submitter : Andrew J. Barr <[EMAIL PROTECTED]> > Fixed-By : Jeremy Fitzhardinge <[EMAIL PROTECTED]> > Commit : 8701ea957dd2a7c309e17c8dcde3a64b92d8aec0 > Status : fixed in -rc2 This I see in Fedora rawhide i686 2.6.19-1.2891.fc7 (BZ'd at <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220855> -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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.20-rc2: known unfixed regressions
Adrian Bunk [EMAIL PROTECTED] wrote: [...] Subject: BUG at fs/buffer.c:1235 when using gdb References : http://lkml.org/lkml/2006/12/17/134 Submitter : Andrew J. Barr [EMAIL PROTECTED] Fixed-By : Jeremy Fitzhardinge [EMAIL PROTECTED] Commit : 8701ea957dd2a7c309e17c8dcde3a64b92d8aec0 Status : fixed in -rc2 This I see in Fedora rawhide i686 2.6.19-1.2891.fc7 (BZ'd at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220855 -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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.20-rc2: known unfixed regressions
Adrian Bunk <[EMAIL PROTECTED]> wrote: > This email lists some known regressions in 2.6.20-rc2 compared to 2.6.19. Add that on SPARC64 boot fails due to missing /dev/root. Vanilla 2.6.19 and 2.6.19.1 work fine, before 2.6.20-rc1 it broke. I checked the initrds for both versions, the only difference "diff -Nur" finds between the unpacked initrds are the modules themselves (obviously). -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: Want comments regarding patch
Daniel Marjamäki <[EMAIL PROTECTED]> wrote: > I sent a patch with this content: > > - for (i = 0; i < MAX_PIRQS; i++) > - pirq_entries[i] = -1; > + memset(pirq_entries, -1, sizeof(pirq_entries)); > > I'd like to know if you have any comments to this change. It was of > course my intention to make the code shorter, simpler and faster. - Is this code in some fast path? If so, I'd set up a constant array that is memcpy()'d over the variable (or used to initialize it) as needed. - If not, what is the point? Shaving off a few bytes/cycles and paying for that with massive developer confusion? What if the constant changes and is -2, or 1, tomorrow? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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.20-rc2: known unfixed regressions
Adrian Bunk [EMAIL PROTECTED] wrote: This email lists some known regressions in 2.6.20-rc2 compared to 2.6.19. Add that on SPARC64 boot fails due to missing /dev/root. Vanilla 2.6.19 and 2.6.19.1 work fine, before 2.6.20-rc1 it broke. I checked the initrds for both versions, the only difference diff -Nur finds between the unpacked initrds are the modules themselves (obviously). -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: Want comments regarding patch
Daniel Marjamäki [EMAIL PROTECTED] wrote: I sent a patch with this content: - for (i = 0; i MAX_PIRQS; i++) - pirq_entries[i] = -1; + memset(pirq_entries, -1, sizeof(pirq_entries)); I'd like to know if you have any comments to this change. It was of course my intention to make the code shorter, simpler and faster. - Is this code in some fast path? If so, I'd set up a constant array that is memcpy()'d over the variable (or used to initialize it) as needed. - If not, what is the point? Shaving off a few bytes/cycles and paying for that with massive developer confusion? What if the constant changes and is -2, or 1, tomorrow? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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.19 (current from git) on SPARC64: Can't mount /
Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Wed, Dec 13, 2006 at 03:56:46PM -0300, Horst H. von Brand wrote: > > I've been running kernel du jour straight from git on my SPARC Ultra 1 for > > some time now on Aurora Corona (Fedora relative, development branch). For a > > few days now 2.6.19 panics on boot, it can't mount /. 2.6.19 worked fine, > > as does 2.6.19.1 (Aurora changed gcc, mkinitrd, ... in between, so I had to > > rebuild a kernel to check if the problem lay elsewhere). Unpacking the > > initrds for 2.6.19 and 2.6.19.1 shows the same (nash script) /init and the > > same modules in both (ext3 + jbd, scsi_mod, sd_mod, esp, others). > > I'm stumped. Any clue? > Is this issue still present in the latest -git? Sorry, got sidetracked by other stuff. Still no boot with 2.9.20-rc1 and -rc2, and none of the kernels I tried in between. initrd is sane (the only differences between the one built for working 2.6.19.1 and broken 2.6.20-rc2 are among the modules themselves). What I did was: cd /tmp mkdir ird-$version cd ird-$version zcat /boot/initrd-$version.img | cpio -i and then "diff -Nur ird-$1 ird-$2". Now to teach diff(1) to compare devices reasonably... Tried latest from Fedora rawhide (mkinitrd-6.0.6-1), no boot. initrd is huge, so I went back to mkinitrd-5.1.19-1. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: util-linux: orphan
Fedora rawhide (i686): $ rpm -qf /bin/mount util-linux-2.13-0.48.fc7 $ ldd /bin/mount linux-gate.so.1 => (0x00f9b000) libblkid.so.1 => /lib/libblkid.so.1 (0x45dbc000) libuuid.so.1 => /lib/libuuid.so.1 (0x45db6000) libselinux.so.1 => /lib/libselinux.so.1 (0x43c5c000) libc.so.6 => /lib/libc.so.6 (0x430d9000) libdevmapper.so.1.02 => /lib/libdevmapper.so.1.02 (0x4329c000) libdl.so.2 => /lib/libdl.so.2 (0x43255000) libsepol.so.1 => /lib/libsepol.so.1 (0x43c8b000) /lib/ld-linux.so.2 (0x5e3f7000) Aurora Corona (SPARC64): $ rpm -qf /bin/mount util-linux-2.13-0.44.sparc.al3 $ ldd /bin/mount libblkid.so.1 => /lib/libblkid.so.1 (0xf7fbc000) libuuid.so.1 => /lib/libuuid.so.1 (0xf7fa8000) libselinux.so.1 => /lib/libselinux.so.1 (0xf7f8) libc.so.6 => /lib/libc.so.6 (0xf7e1) libdevmapper.so.1.02 => /lib/libdevmapper.so.1.02 (0xf7dfc000) libdl.so.2 => /lib/libdl.so.2 (0xf7de4000) libsepol.so.1 => /lib/libsepol.so.1 (0xf7d88000) /lib/ld-linux.so.2 (0x7000) CentOS 4.4 (x86_64): $ rpm -qf /bin/mount util-linux-2.12a-16.EL4.20 $ ldd /bin/mount libc.so.6 => /lib64/tls/libc.so.6 (0x0031d6c0) /lib64/ld-linux-x86-64.so.2 (0x00552aaaa000) All look fine to me. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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] Remove logically superfluous comparisons from Kconfig files.
Robert P. J. Day <[EMAIL PROTECTED]> wrote: > Remove Kconfig comparisons of the form FUBAR || FUBAR=n, since they > appear to be superfluous. > > Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]> > > --- > > based on what i read in kconfig-language.txt, it would *appear* that > those comparisons are redundant, but i'm willing to be convinced > otherwise. (unless the developer specifically wanted the case of > "!=m", which i'm fairly sure is not the same thing, yes?) Would be clearer written that way if so. > drivers/char/drm/Kconfig |2 +- > fs/dlm/Kconfig |1 - > net/ipv4/netfilter/Kconfig |1 - > net/sctp/Kconfig |1 - > 4 files changed, 1 insertion(+), 4 deletions(-) > > diff --git a/drivers/char/drm/Kconfig b/drivers/char/drm/Kconfig > index ef833a1..d681e68 100644 > --- a/drivers/char/drm/Kconfig > +++ b/drivers/char/drm/Kconfig > @@ -6,7 +6,7 @@ > # > config DRM > tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI > support)" > - depends on (AGP || AGP=n) && PCI > + depends on && PCI ^^ ??? > help -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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] Remove logically superfluous comparisons from Kconfig files.
Robert P. J. Day [EMAIL PROTECTED] wrote: Remove Kconfig comparisons of the form FUBAR || FUBAR=n, since they appear to be superfluous. Signed-off-by: Robert P. J. Day [EMAIL PROTECTED] --- based on what i read in kconfig-language.txt, it would *appear* that those comparisons are redundant, but i'm willing to be convinced otherwise. (unless the developer specifically wanted the case of !=m, which i'm fairly sure is not the same thing, yes?) Would be clearer written that way if so. drivers/char/drm/Kconfig |2 +- fs/dlm/Kconfig |1 - net/ipv4/netfilter/Kconfig |1 - net/sctp/Kconfig |1 - 4 files changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/char/drm/Kconfig b/drivers/char/drm/Kconfig index ef833a1..d681e68 100644 --- a/drivers/char/drm/Kconfig +++ b/drivers/char/drm/Kconfig @@ -6,7 +6,7 @@ # config DRM tristate Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) - depends on (AGP || AGP=n) PCI + depends on PCI ^^ ??? help -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: util-linux: orphan
Fedora rawhide (i686): $ rpm -qf /bin/mount util-linux-2.13-0.48.fc7 $ ldd /bin/mount linux-gate.so.1 = (0x00f9b000) libblkid.so.1 = /lib/libblkid.so.1 (0x45dbc000) libuuid.so.1 = /lib/libuuid.so.1 (0x45db6000) libselinux.so.1 = /lib/libselinux.so.1 (0x43c5c000) libc.so.6 = /lib/libc.so.6 (0x430d9000) libdevmapper.so.1.02 = /lib/libdevmapper.so.1.02 (0x4329c000) libdl.so.2 = /lib/libdl.so.2 (0x43255000) libsepol.so.1 = /lib/libsepol.so.1 (0x43c8b000) /lib/ld-linux.so.2 (0x5e3f7000) Aurora Corona (SPARC64): $ rpm -qf /bin/mount util-linux-2.13-0.44.sparc.al3 $ ldd /bin/mount libblkid.so.1 = /lib/libblkid.so.1 (0xf7fbc000) libuuid.so.1 = /lib/libuuid.so.1 (0xf7fa8000) libselinux.so.1 = /lib/libselinux.so.1 (0xf7f8) libc.so.6 = /lib/libc.so.6 (0xf7e1) libdevmapper.so.1.02 = /lib/libdevmapper.so.1.02 (0xf7dfc000) libdl.so.2 = /lib/libdl.so.2 (0xf7de4000) libsepol.so.1 = /lib/libsepol.so.1 (0xf7d88000) /lib/ld-linux.so.2 (0x7000) CentOS 4.4 (x86_64): $ rpm -qf /bin/mount util-linux-2.12a-16.EL4.20 $ ldd /bin/mount libc.so.6 = /lib64/tls/libc.so.6 (0x0031d6c0) /lib64/ld-linux-x86-64.so.2 (0x00552000) All look fine to me. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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.19 (current from git) on SPARC64: Can't mount /
Adrian Bunk [EMAIL PROTECTED] wrote: On Wed, Dec 13, 2006 at 03:56:46PM -0300, Horst H. von Brand wrote: I've been running kernel du jour straight from git on my SPARC Ultra 1 for some time now on Aurora Corona (Fedora relative, development branch). For a few days now 2.6.19 panics on boot, it can't mount /. 2.6.19 worked fine, as does 2.6.19.1 (Aurora changed gcc, mkinitrd, ... in between, so I had to rebuild a kernel to check if the problem lay elsewhere). Unpacking the initrds for 2.6.19 and 2.6.19.1 shows the same (nash script) /init and the same modules in both (ext3 + jbd, scsi_mod, sd_mod, esp, others). I'm stumped. Any clue? Is this issue still present in the latest -git? Sorry, got sidetracked by other stuff. Still no boot with 2.9.20-rc1 and -rc2, and none of the kernels I tried in between. initrd is sane (the only differences between the one built for working 2.6.19.1 and broken 2.6.20-rc2 are among the modules themselves). What I did was: cd /tmp mkdir ird-$version cd ird-$version zcat /boot/initrd-$version.img | cpio -i and then diff -Nur ird-$1 ird-$2. Now to teach diff(1) to compare devices reasonably... Tried latest from Fedora rawhide (mkinitrd-6.0.6-1), no boot. initrd is huge, so I went back to mkinitrd-5.1.19-1. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: Binary Drivers
David Schwartz <[EMAIL PROTECTED]> wrote: [..] . > The point is that any rights the manufacturer may have had to the car should > have been sold along with the car, otherwise it's not a normal free and > clear sale. A normal free and clear sale includes all rights to the item > sold, except those specific laws allows the manufacturer to retain. This is complete nonsense. The car manufacturer can very well agree with you to sell you the right to only drive the car on weekdays, and rent it off on weekends. Nothing forces them to sell "all rights they have on the car". [...] > I simply do not accept the argument that it is lawful for a manufacturer to > sell a physical object in a normal free and clear sale and then refuse to > disclose the knowledge necessary to use it. Ask a lawyer about this, don't impose your wacky legal theories on us. > (And by that I mean necessary to > use it any reasonable way, not just the way the manufacturer intended it to > be used.) Define "reasonable way". The manufacturer could very well define it as "use the XYZ graphics card on Windows XP service pack 2", as it was designed specifically for that environment. Everything else (use on Linux, for example) is then "unreasonable use", and need not be supported at all. > This same issue has been pressed in other areas Examples? > and I think it's time it be > pressed with graphics cards. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: Binary Drivers
James C Georgas <[EMAIL PROTECTED]> wrote: [...] > Let's summarize the current situation: > 1) Hardware vendors don't have to tell us how to program their products, > as long as they provide some way to use it (i.e. binary blob driver). No. They have absolutely no obligation to tell you anything. If they sell you a card with a binary driver that /only/ works with, say, Minix, it is up to you to buy it or not. > 2) Hardware vendors don't want to tell us how to program their products, > because they think this information is their secret sauce (or maybe > their competitor's secret sauce). And lots of other reasons, including that with detailed specs you might be able to continue using the same card for 3 or 5 years, when they'd love to sell you a replacement next year... Creating, vetting and maintaining specs is /hard/ work, and costs money. If it won't bring a measurable increase in income, why do it? > 3) Hardware vendors don't tell us how to program their products, because > they know about (1) and they believe (2). The law says (1), and they know (2) for a fact. > 4) We need products with datasheets because of our development model. Yep. > 5) We want products with capabilities that these vendors advertise. Yep. > 6) Products that satisfy both (4) and (5) are often scarce or > non-existent. Just too bad. > So far, the suggestions I've seen to resolve the above conflict fall > into three categories: > a) Force vendors to provide datasheets. How? > b) Entice vendors to provide datasheets. How? > c) Reverse engineer the hardware and write our own datasheets. Not always legal... > Solution (a) involves denial of point (1), mostly through the use of > analogy and allegory. These are big companies, who deal in hard realities and cold cash. Poetry won't get you anywhere. > Alternatively, one can try to change the law > through government channels. Won't happen before open source is so prevalent that the point has long become moot. > Solution (b) requires market pressure, Will happen once open source has a large enough slice of a lucrative pie. I.e., it is happening today with "server class" machines. >charity, A company is bound /by law/ to make as much profit as possible. Whoever wants to go this route might spend some time as a neighbor to the Enron et al folks. > or visionary management. This cuts both ways... visionary management made small companies big, and huge companies dissappear from the face of the earth. > We can't exert enough market pressure currently to make much difference. OK. > Charity sometimes gives us datasheets for old hardware. OK. > Visionary > management is the future. Don't they tell that all aspiring MBAs... > Solution (c) is what we do now, with varying degrees of success. A good > example is the R300 support in the radeon DRM module. And others. And this is not the only avenue persued, not by far. Some developers are chummy with the engineers behind the devices they support, and get some help that way. There are people who convinced their companies to let them work on Linux drivers on their own time (with access to the people in the know and datasheets, one would presume), others have gone so far as to be able to work part-time on Linux drivers. Some companies have hired developers under NDA to develop drivers, others have given out datasheets (and access to sample hardware) under NDA (or just "don't give this out too freely") to interested developers. Then there are others (IBM comes to mind) where the company itself is officially developing drivers for their hardware. Sure, most of the more backstage deals you won't ever hear about, and for some of the other cases you might have absolutely no interest. Fact is, Linux has /by far/ the best hardware support of all operating systems out there. You only notice the (small) minority of devices that don't work (yet). Sure, it is mostly in the latest glitter where support is currently lacking, and this distorts the perspective quite a bit. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: Binary Drivers
James C Georgas [EMAIL PROTECTED] wrote: [...] Let's summarize the current situation: 1) Hardware vendors don't have to tell us how to program their products, as long as they provide some way to use it (i.e. binary blob driver). No. They have absolutely no obligation to tell you anything. If they sell you a card with a binary driver that /only/ works with, say, Minix, it is up to you to buy it or not. 2) Hardware vendors don't want to tell us how to program their products, because they think this information is their secret sauce (or maybe their competitor's secret sauce). And lots of other reasons, including that with detailed specs you might be able to continue using the same card for 3 or 5 years, when they'd love to sell you a replacement next year... Creating, vetting and maintaining specs is /hard/ work, and costs money. If it won't bring a measurable increase in income, why do it? 3) Hardware vendors don't tell us how to program their products, because they know about (1) and they believe (2). The law says (1), and they know (2) for a fact. 4) We need products with datasheets because of our development model. Yep. 5) We want products with capabilities that these vendors advertise. Yep. 6) Products that satisfy both (4) and (5) are often scarce or non-existent. Just too bad. So far, the suggestions I've seen to resolve the above conflict fall into three categories: a) Force vendors to provide datasheets. How? b) Entice vendors to provide datasheets. How? c) Reverse engineer the hardware and write our own datasheets. Not always legal... Solution (a) involves denial of point (1), mostly through the use of analogy and allegory. These are big companies, who deal in hard realities and cold cash. Poetry won't get you anywhere. Alternatively, one can try to change the law through government channels. Won't happen before open source is so prevalent that the point has long become moot. Solution (b) requires market pressure, Will happen once open source has a large enough slice of a lucrative pie. I.e., it is happening today with server class machines. charity, A company is bound /by law/ to make as much profit as possible. Whoever wants to go this route might spend some time as a neighbor to the Enron et al folks. or visionary management. This cuts both ways... visionary management made small companies big, and huge companies dissappear from the face of the earth. We can't exert enough market pressure currently to make much difference. OK. Charity sometimes gives us datasheets for old hardware. OK. Visionary management is the future. Don't they tell that all aspiring MBAs... Solution (c) is what we do now, with varying degrees of success. A good example is the R300 support in the radeon DRM module. And others. And this is not the only avenue persued, not by far. Some developers are chummy with the engineers behind the devices they support, and get some help that way. There are people who convinced their companies to let them work on Linux drivers on their own time (with access to the people in the know and datasheets, one would presume), others have gone so far as to be able to work part-time on Linux drivers. Some companies have hired developers under NDA to develop drivers, others have given out datasheets (and access to sample hardware) under NDA (or just don't give this out too freely) to interested developers. Then there are others (IBM comes to mind) where the company itself is officially developing drivers for their hardware. Sure, most of the more backstage deals you won't ever hear about, and for some of the other cases you might have absolutely no interest. Fact is, Linux has /by far/ the best hardware support of all operating systems out there. You only notice the (small) minority of devices that don't work (yet). Sure, it is mostly in the latest glitter where support is currently lacking, and this distorts the perspective quite a bit. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: Binary Drivers
David Schwartz [EMAIL PROTECTED] wrote: [..] . The point is that any rights the manufacturer may have had to the car should have been sold along with the car, otherwise it's not a normal free and clear sale. A normal free and clear sale includes all rights to the item sold, except those specific laws allows the manufacturer to retain. This is complete nonsense. The car manufacturer can very well agree with you to sell you the right to only drive the car on weekdays, and rent it off on weekends. Nothing forces them to sell all rights they have on the car. [...] I simply do not accept the argument that it is lawful for a manufacturer to sell a physical object in a normal free and clear sale and then refuse to disclose the knowledge necessary to use it. Ask a lawyer about this, don't impose your wacky legal theories on us. (And by that I mean necessary to use it any reasonable way, not just the way the manufacturer intended it to be used.) Define reasonable way. The manufacturer could very well define it as use the XYZ graphics card on Windows XP service pack 2, as it was designed specifically for that environment. Everything else (use on Linux, for example) is then unreasonable use, and need not be supported at all. This same issue has been pressed in other areas Examples? and I think it's time it be pressed with graphics cards. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: Binary Drivers
Rok Markovic <[EMAIL PROTECTED]> wrote: > It seems that debate around cars and drivers has gone too far (IMHO). Ditto. > I > do not think that there is a question if we have any right to demand > details about hardware from manufactorers -> we are NOT. OK. > But I think that > we have right to know how to use it. The card is designed for use with /Windows/, you get a /Windows/ driver. That your PC is able to also run, say, Plan 9, is not the manufacturer's business at all, it is /your/ choice, and /your/ problem if what the manufacturer provides doesn't help you there. The manufacturer is keeping his part of the deal. You don't like the deal, tough luck. > I will translate this to CAR > language - We have to know how to drive the car but not all the details > how is this done, so we can drive a car without the "driver". We do not > need an exact knowledge about engine, ECU, suspension,... Exactly. > Now the real question: > > Why are manufatorers afraid to give us this information? Not "afraid". It is more expensive to them: - Because they would have to pick developer's brains and write it down, make sure it is complete, check it for publishing, etc. That costs money (and ties up key developers, and...) for /very/ little gain (open source systems is something like a 5 to 10% of all systems, mostly servers where highest performance isn't asked for, so the market for current high-end cards (where the brains are there at all for picking) is /extremely/ small). - Because they would have to get permission to do so from third parties, that means paying real money for little gain - Because sometimes it is just "we tried several combinations, this one(s) happen to work, dunno why". How do you write something like that down? - Because wrong settings might break the hardware, people fiddling around would then want a replacement, a very real cost - Because you can't write any software at all without violating some patent. In this area, it is probable that everybody is violating everybody else's patents, and making that easy to find out (via source code or specs) opens you up to lawsuits. Lawyers (and common sense) will tell yo not to go there unless it is very worthwhile. And it isn't (see above) - See the bletcherous workarounds for many device bugs (or downright design braindamage) in the in-kernel drivers. They might be just embarrased by the junk they shove out the door (We all know it happens with software, right? Hardware is much the same...). And they can't just work a year or so longer to get them ironed out, by then they could be right out of business. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: Binary Drivers
David Schwartz <[EMAIL PROTECTED]> wrote: [...] > Now, let's try it another way: Are they allowed to sell a car that > incorporates a computer that uses a trade-secret algorithm for controlling > the fuel injection to get 20 more horsepower and 5% better mileage if it's > impossible to *start* the car without knowing that algorithm? It is done regularly. Current cars control the fuel injection etc via an onboard computer, without this control the engine just won't start. Did you get the specs for the exact fuel control algorithm with your car? Should you be able to fool around with that, thus violating emission control measures (this would damage not only you, but everybody)? Almost everything around you is controlled by a uP nowadays (it is much cheaper/preciser to control e.g. the washing machine that way than via the customary rotating wheels with notches). Did you get the specs for that? Can you get them? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: Updated Kernel Hacker's guide to git
Jeff Garzik <[EMAIL PROTECTED]> wrote: > I refreshed my git intro/cookbook for kernel hackers, at > http://linux.yyz.us/git-howto.html Looks nice, starting to look it over. Notes: Getting started: There are RPM packages available (I think they are for latest Fedora; in case of doubt get the latest SRPM and build yourself, sometimes the distros lag /way/ behind). There are also Debian packages there, dunno about those. Basic tasks: 'git pull' should be enough, no need to give the URL each time. It is useful to tell people how to get "nonofficial" branches (via URL + branches) too. Miscellaneous debris: 'git pull' has gotten tags each time for me? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: Updated Kernel Hacker's guide to git
Jeff Garzik [EMAIL PROTECTED] wrote: I refreshed my git intro/cookbook for kernel hackers, at http://linux.yyz.us/git-howto.html Looks nice, starting to look it over. Notes: Getting started: There are RPM packages available (I think they are for latest Fedora; in case of doubt get the latest SRPM and build yourself, sometimes the distros lag /way/ behind). There are also Debian packages there, dunno about those. Basic tasks: 'git pull' should be enough, no need to give the URL each time. It is useful to tell people how to get nonofficial branches (via URL + branches) too. Miscellaneous debris: 'git pull' has gotten tags each time for me? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: Binary Drivers
David Schwartz [EMAIL PROTECTED] wrote: [...] Now, let's try it another way: Are they allowed to sell a car that incorporates a computer that uses a trade-secret algorithm for controlling the fuel injection to get 20 more horsepower and 5% better mileage if it's impossible to *start* the car without knowing that algorithm? It is done regularly. Current cars control the fuel injection etc via an onboard computer, without this control the engine just won't start. Did you get the specs for the exact fuel control algorithm with your car? Should you be able to fool around with that, thus violating emission control measures (this would damage not only you, but everybody)? Almost everything around you is controlled by a uP nowadays (it is much cheaper/preciser to control e.g. the washing machine that way than via the customary rotating wheels with notches). Did you get the specs for that? Can you get them? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: Binary Drivers
Rok Markovic [EMAIL PROTECTED] wrote: It seems that debate around cars and drivers has gone too far (IMHO). Ditto. I do not think that there is a question if we have any right to demand details about hardware from manufactorers - we are NOT. OK. But I think that we have right to know how to use it. The card is designed for use with /Windows/, you get a /Windows/ driver. That your PC is able to also run, say, Plan 9, is not the manufacturer's business at all, it is /your/ choice, and /your/ problem if what the manufacturer provides doesn't help you there. The manufacturer is keeping his part of the deal. You don't like the deal, tough luck. I will translate this to CAR language - We have to know how to drive the car but not all the details how is this done, so we can drive a car without the driver. We do not need an exact knowledge about engine, ECU, suspension,... Exactly. Now the real question: Why are manufatorers afraid to give us this information? Not afraid. It is more expensive to them: - Because they would have to pick developer's brains and write it down, make sure it is complete, check it for publishing, etc. That costs money (and ties up key developers, and...) for /very/ little gain (open source systems is something like a 5 to 10% of all systems, mostly servers where highest performance isn't asked for, so the market for current high-end cards (where the brains are there at all for picking) is /extremely/ small). - Because they would have to get permission to do so from third parties, that means paying real money for little gain - Because sometimes it is just we tried several combinations, this one(s) happen to work, dunno why. How do you write something like that down? - Because wrong settings might break the hardware, people fiddling around would then want a replacement, a very real cost - Because you can't write any software at all without violating some patent. In this area, it is probable that everybody is violating everybody else's patents, and making that easy to find out (via source code or specs) opens you up to lawsuits. Lawyers (and common sense) will tell yo not to go there unless it is very worthwhile. And it isn't (see above) - See the bletcherous workarounds for many device bugs (or downright design braindamage) in the in-kernel drivers. They might be just embarrased by the junk they shove out the door (We all know it happens with software, right? Hardware is much the same...). And they can't just work a year or so longer to get them ironed out, by then they could be right out of business. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
[EMAIL PROTECTED] wrote: > On Fri, 22 Dec 2006 02:34:54 +1100, Marek Wawrzyczny said: [...] > > Perhaps we just report on the individual devices then... forget the system > > rating. > OK, *that* I see as potentially useful - I frequently get handed older > boxen with strange gear == gear for which there is probably no documentation at all > in them, and need a way to figure out if I want to > install software, LiveCD of your choice... > or cannibalize it for parts. Also helpful if a buddy has > a Frankintel box they build, and they want to know if they can install > something other than Windows Same as above. > Bonus points if it sees a card that has a known out-of-tree driver and > tells you where to find it and what its license status is (I just went > down that road with an Intel 3945)... If in-tree driver is already a challange, out-of-tree is hopeless. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: Binary Drivers
David Schwartz <[EMAIL PROTECTED]> wrote: > > Two of the specific arguments I've heard are (a) that the board (and > > its hardware interfaces that the documentation would describe) involve > > IP licensed from a third party, which the board manufacturer does not > > have a legal right to disclose, > If they can't disclose it, they can't sell it. If they can't sell it, it's > fraud to tell someone that they can buy it. If a contract with a third party > limits your ability to sell something to someone, you have to *tell* *them* > that they do not get all of the rights of ownership because you don't own > some of them and hence can't transfer them. They aren't /selling/ you the rights to the driver, just charging you for its /use/. [...] > > or (b) that there is, in fact, no > > suitable documentation, because the boards are developed somewhat > > fluidly and the driver is developed directly from low-level knowledge > > that simply isn't written down in a form suitable for passing on. > You can't sell something that doesn't exist. If you sell a car even though > you can't explain how anyone could drive it, that's fraud. Nonsense. [...] > > If you're building products with no expectation of supporting outside > > driver developers, both of those are quite possible. > And they're both quite fraudulent. You cannot both sell something and keep > its construction a secret. It is quite regularly done, so this argument won't fly. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: Binary Drivers
David Schwartz <[EMAIL PROTECTED]> wrote: [...] > Honestly, I think it *is* wrong to sell someone a physical product and then > not tell them how to make it work. Right. And the driver *is* the "information to make it work", in a convenient package. [...] > How would you feel if you bought a car and then discovered that the > manufacturer had welded the hood shut? How many people still do their own > oil changes anyway? If people don't do this, what sense does it make to tell them how to do it anyway? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: Binary Drivers
David Schwartz [EMAIL PROTECTED] wrote: [...] Honestly, I think it *is* wrong to sell someone a physical product and then not tell them how to make it work. Right. And the driver *is* the information to make it work, in a convenient package. [...] How would you feel if you bought a car and then discovered that the manufacturer had welded the hood shut? How many people still do their own oil changes anyway? If people don't do this, what sense does it make to tell them how to do it anyway? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: Binary Drivers
David Schwartz [EMAIL PROTECTED] wrote: Two of the specific arguments I've heard are (a) that the board (and its hardware interfaces that the documentation would describe) involve IP licensed from a third party, which the board manufacturer does not have a legal right to disclose, If they can't disclose it, they can't sell it. If they can't sell it, it's fraud to tell someone that they can buy it. If a contract with a third party limits your ability to sell something to someone, you have to *tell* *them* that they do not get all of the rights of ownership because you don't own some of them and hence can't transfer them. They aren't /selling/ you the rights to the driver, just charging you for its /use/. [...] or (b) that there is, in fact, no suitable documentation, because the boards are developed somewhat fluidly and the driver is developed directly from low-level knowledge that simply isn't written down in a form suitable for passing on. You can't sell something that doesn't exist. If you sell a car even though you can't explain how anyone could drive it, that's fraud. Nonsense. [...] If you're building products with no expectation of supporting outside driver developers, both of those are quite possible. And they're both quite fraudulent. You cannot both sell something and keep its construction a secret. It is quite regularly done, so this argument won't fly. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
[EMAIL PROTECTED] wrote: On Fri, 22 Dec 2006 02:34:54 +1100, Marek Wawrzyczny said: [...] Perhaps we just report on the individual devices then... forget the system rating. OK, *that* I see as potentially useful - I frequently get handed older boxen with strange gear == gear for which there is probably no documentation at all in them, and need a way to figure out if I want to install software, LiveCD of your choice... or cannibalize it for parts. Also helpful if a buddy has a Frankintel box they build, and they want to know if they can install something other than Windows Same as above. Bonus points if it sees a card that has a known out-of-tree driver and tells you where to find it and what its license status is (I just went down that road with an Intel 3945)... If in-tree driver is already a challange, out-of-tree is hopeless. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
Marek Wawrzyczny <[EMAIL PROTECTED]> wrote: [...] > No, no, no... I was never proposing that. I was thinking of something more > along the lines of reporting back on open-source friendliness of > manufacturers of devices, and perhaps on the availability of open source > drivers for the devices. I am talking only about "detected" devices. The > database would never try and guess the vendor, model and variation of the > system. This is a /massive/ ammount of effort, and the data required is hard to come by before buying, so it is rather useless. What chip is in NetworkCard 675? In 675a? (yes, I've seen dLink cards called and + which were /radically/ different!). Yes, here you go to the computer store and ask them to build you a machine from parts you specify. But it is far from the common way to get a PC (those stores mostly cater to heavy-weight gamers, many pieces have to be special ordered), and building a machine that works OK with Linux is a two or three day exercise in hunting down specifications for compatible pieces. Most folks wander into the next department store and buy a PC. Mostly terrible crap, BTW. Where this makes sense (printers!) the data is there, mostly up to date, and accurate. [...] > I actually find that trying to obtain information about what hardware > is/isn't supported in Linux is actually quite difficult to obtain. The > information that's on the internet is either outdated or has not yet been > written. I was hoping to analyze the system's device information > together with driver/device information obtained from the kernel source > itself to give users a better (but not perhaps not as authoritative as > I'd like to) picture of what to expect. There is just way too much hardware out there, and new pieces come out every day. Then there are lots of integrators that buy chips and build PCI cards. Sometimes cards with supported chips just don't work at all. Etc. It is all over the map. Besides, many times you don't find information on some piece of hardware it is because it is dirt cheap stuff that has no chance of working, so nobody even tried. [...] > > Bonus points for figuring out what to do with systems that have some chip > > that's a supported XYZ driver, but wired up behind a squirrely bridge with > > some totally bizarre IRQ allocation, so you end up with something that's > > visible on lspci but not actually *usable* in any real sense of the term... > Hmmm... does this happen often? False results are definedly a show > stopper. Not just for systems, even for individual cards. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
Marek Wawrzyczny [EMAIL PROTECTED] wrote: [...] No, no, no... I was never proposing that. I was thinking of something more along the lines of reporting back on open-source friendliness of manufacturers of devices, and perhaps on the availability of open source drivers for the devices. I am talking only about detected devices. The database would never try and guess the vendor, model and variation of the system. This is a /massive/ ammount of effort, and the data required is hard to come by before buying, so it is rather useless. What chip is in NetworkCard 675? In 675a? (yes, I've seen dLink cards called foo and foo+ which were /radically/ different!). Yes, here you go to the computer store and ask them to build you a machine from parts you specify. But it is far from the common way to get a PC (those stores mostly cater to heavy-weight gamers, many pieces have to be special ordered), and building a machine that works OK with Linux is a two or three day exercise in hunting down specifications for compatible pieces. Most folks wander into the next department store and buy a PC. Mostly terrible crap, BTW. Where this makes sense (printers!) the data is there, mostly up to date, and accurate. [...] I actually find that trying to obtain information about what hardware is/isn't supported in Linux is actually quite difficult to obtain. The information that's on the internet is either outdated or has not yet been written. I was hoping to analyze the system's device information together with driver/device information obtained from the kernel source itself to give users a better (but not perhaps not as authoritative as I'd like to) picture of what to expect. There is just way too much hardware out there, and new pieces come out every day. Then there are lots of integrators that buy chips and build PCI cards. Sometimes cards with supported chips just don't work at all. Etc. It is all over the map. Besides, many times you don't find information on some piece of hardware it is because it is dirt cheap stuff that has no chance of working, so nobody even tried. [...] Bonus points for figuring out what to do with systems that have some chip that's a supported XYZ driver, but wired up behind a squirrely bridge with some totally bizarre IRQ allocation, so you end up with something that's visible on lspci but not actually *usable* in any real sense of the term... Hmmm... does this happen often? False results are definedly a show stopper. Not just for systems, even for individual cards. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: GPL only modules
Sanjoy Mahajan <[EMAIL PROTECTED]> wrote: > Linus Torvalds wrote: > > That said, I think they are still pushing the "you don't have any > > rights unless we give you additional rights explicitly" angle a bit > > too hard. > > From section 2 (GPLv3, draft 2): > > This License acknowledges your rights of "fair use" or other > equivalent, as provided by copyright law. > > By choosing 'acknowledges' as the verb, the licensee says explicitly > that fair-use rights are already yours, not that they are being given > to you. Pure noise, a license can't take them away in any case. [That is my pet pevee with GPL: It has a bit of legally binding text, and lots of "explanation" and "philosophy" that don't add anything but confusion. A clear-cut license plus an explanation/comment would have been better. IMHO, IANAL. HAND.] -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: GPL only modules
D. Hazelton <[EMAIL PROTECTED]> wrote: [...] > The GPL is a License that covers how the code may be used, modified and > distributed. This is the reason that the FSF people had to make the big > exception for Bison, because the parser skeleton is such an integral part of > Bison (Bison itself, IIRC, uses the same skeleton, modified, as part of the > program) that truthfully, any parser built using Bison is a derivative work > of code released under the GPL. They didn't "have to make the big exception", if Linus' view is correct: The parser is built mechanically from the skeleton and the user's input, so it is just an aggregation. Sure, it is best to make this clear (by the exception), even if not needed. > That said, since there is a distribution, use and modification license on > the Linux Kernel - the GPLv2 - there are those extra restrictions on the > code *OUTSIDE* the copyright rules. A license like GPL works /inside/ copyright law, by allowing you to do things the law prohibits unless the owner of the right agrees. What the law allows explicitly, regardless of the owner's wishes, can't be taken away. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: GPL only modules
D. Hazelton [EMAIL PROTECTED] wrote: [...] The GPL is a License that covers how the code may be used, modified and distributed. This is the reason that the FSF people had to make the big exception for Bison, because the parser skeleton is such an integral part of Bison (Bison itself, IIRC, uses the same skeleton, modified, as part of the program) that truthfully, any parser built using Bison is a derivative work of code released under the GPL. They didn't have to make the big exception, if Linus' view is correct: The parser is built mechanically from the skeleton and the user's input, so it is just an aggregation. Sure, it is best to make this clear (by the exception), even if not needed. That said, since there is a distribution, use and modification license on the Linux Kernel - the GPLv2 - there are those extra restrictions on the code *OUTSIDE* the copyright rules. A license like GPL works /inside/ copyright law, by allowing you to do things the law prohibits unless the owner of the right agrees. What the law allows explicitly, regardless of the owner's wishes, can't be taken away. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: GPL only modules
Sanjoy Mahajan [EMAIL PROTECTED] wrote: Linus Torvalds wrote: That said, I think they are still pushing the you don't have any rights unless we give you additional rights explicitly angle a bit too hard. From section 2 (GPLv3, draft 2): This License acknowledges your rights of fair use or other equivalent, as provided by copyright law. By choosing 'acknowledges' as the verb, the licensee says explicitly that fair-use rights are already yours, not that they are being given to you. Pure noise, a license can't take them away in any case. [That is my pet pevee with GPL: It has a bit of legally binding text, and lots of explanation and philosophy that don't add anything but confusion. A clear-cut license plus an explanation/comment would have been better. IMHO, IANAL. HAND.] -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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/
2.6.19 (current from git) on SPARC64: Can't mount /
I've been running kernel du jour straight from git on my SPARC Ultra 1 for some time now on Aurora Corona (Fedora relative, development branch). For a few days now 2.6.19 panics on boot, it can't mount /. 2.6.19 worked fine, as does 2.6.19.1 (Aurora changed gcc, mkinitrd, ... in between, so I had to rebuild a kernel to check if the problem lay elsewhere). Unpacking the initrds for 2.6.19 and 2.6.19.1 shows the same (nash script) /init and the same modules in both (ext3 + jbd, scsi_mod, sd_mod, esp, others). I'm stumped. Any clue? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: Postgrey experiment at VGER
Giacomo A. Catenazzi <[EMAIL PROTECTED]> wrote: [...] > So a challange to the kernel hackers: build a mail filtering/proxy > system, a' la BSD. Has no reason to be in-kernel. Email is a complex subject in and by itself, don't mix it in here. > I don't remember the specification and features, but IIRC the > netfilter is not enough to do the graylisting Nodz. > (but pf was). Mind boggles... [Hint: Think a bit what greylisting involves!] > Someone has some hints what kernel can do in the fight against > spam? Nothing whatsoever, directly? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: Postgrey experiment at VGER
Giacomo A. Catenazzi [EMAIL PROTECTED] wrote: [...] So a challange to the kernel hackers: build a mail filtering/proxy system, a' la BSD. Has no reason to be in-kernel. Email is a complex subject in and by itself, don't mix it in here. I don't remember the specification and features, but IIRC the netfilter is not enough to do the graylisting Nodz. (but pf was). Mind boggles... [Hint: Think a bit what greylisting involves!] Someone has some hints what kernel can do in the fight against spam? Nothing whatsoever, directly? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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/
2.6.19 (current from git) on SPARC64: Can't mount /
I've been running kernel du jour straight from git on my SPARC Ultra 1 for some time now on Aurora Corona (Fedora relative, development branch). For a few days now 2.6.19 panics on boot, it can't mount /. 2.6.19 worked fine, as does 2.6.19.1 (Aurora changed gcc, mkinitrd, ... in between, so I had to rebuild a kernel to check if the problem lay elsewhere). Unpacking the initrds for 2.6.19 and 2.6.19.1 shows the same (nash script) /init and the same modules in both (ext3 + jbd, scsi_mod, sd_mod, esp, others). I'm stumped. Any clue? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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] let WARN_ON() output the condition
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Wed, 6 Dec 2006 01:51:01 +0100 (CET)
> Jiri Kosina <[EMAIL PROTECTED]> wrote:
>
> > [PATCH] let WARN_ON() output the condition
> >
> > It is possible, in some cases, that the output of WARN_ON() is ambiguous
> > and can't be properly used to identify the exact condition which caused
> > the warning to trigger. This happens whenever there is a macro that
> > contains multiple WARN_ONs inside. Notable example is spin_lock_mutex().
> > If any of the two WARN_ONs trigger, we are not able to say which one was
> > the cause (as we get only line number, which however belongs to the place
> > where the macro was expanded).
> >
> > This patch lets WARN_ON() to output also the condition and fixes the
> > DEBUG_LOCKS_WARN_ON() macro to pass the condition properly to WARN_ON. The
> > possible drawback could be when someone passes a condition which has
> > sideeffects. Then it would be evaluated twice, instead of current one
> > evaluation. On the other hand, when anyone passes expression with
> > sideeffects to WARN_ON(), he is asking for problems anyway.
> >
> > Patch against 2.6.19-rc6-mm2.
> >
> > Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]>
> >
> > ---
> >
> > include/asm-generic/bug.h |4 ++--
> > include/linux/debug_locks.h |2 +-
> > 2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
> > index a06eecd..af7574e 100644
> > --- a/include/asm-generic/bug.h
> > +++ b/include/asm-generic/bug.h
> > @@ -35,8 +35,8 @@ #ifndef HAVE_ARCH_WARN_ON
> > #define WARN_ON(condition) ({
> > \
> > typeof(condition) __ret_warn_on = (condition); \
> > if (unlikely(__ret_warn_on)) { \
> > - printk("WARNING at %s:%d %s()\n", __FILE__, \
> > - __LINE__, __FUNCTION__);\
> > + printk("WARNING (%s) at %s:%d %s()\n", #condition, \
> > + __FILE__,__LINE__, __FUNCTION__); \
__FILE__, __LINE__, __FUNCTION__);
(missing space after "__FILE__,")
> > dump_stack(); \
> > } \
> > unlikely(__ret_warn_on);\
> > diff --git a/include/linux/debug_locks.h b/include/linux/debug_locks.h
> > index 952bee7..1c2b682 100644
> > --- a/include/linux/debug_locks.h
> > +++ b/include/linux/debug_locks.h
> > @@ -25,7 +25,7 @@ ({
> > \
> > \
> > if (unlikely(c)) { \
> > if (debug_locks_off()) \
> > - WARN_ON(1); \
> > + WARN_ON(c); \
> > __ret = 1; \
> > } \
> > __ret; \
Why not just:
WARN_ON(debug_locks_off())
here? Would give a more readable message too, IMHO.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de InformaticaFono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
-
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] let WARN_ON() output the condition
Andrew Morton [EMAIL PROTECTED] wrote:
On Wed, 6 Dec 2006 01:51:01 +0100 (CET)
Jiri Kosina [EMAIL PROTECTED] wrote:
[PATCH] let WARN_ON() output the condition
It is possible, in some cases, that the output of WARN_ON() is ambiguous
and can't be properly used to identify the exact condition which caused
the warning to trigger. This happens whenever there is a macro that
contains multiple WARN_ONs inside. Notable example is spin_lock_mutex().
If any of the two WARN_ONs trigger, we are not able to say which one was
the cause (as we get only line number, which however belongs to the place
where the macro was expanded).
This patch lets WARN_ON() to output also the condition and fixes the
DEBUG_LOCKS_WARN_ON() macro to pass the condition properly to WARN_ON. The
possible drawback could be when someone passes a condition which has
sideeffects. Then it would be evaluated twice, instead of current one
evaluation. On the other hand, when anyone passes expression with
sideeffects to WARN_ON(), he is asking for problems anyway.
Patch against 2.6.19-rc6-mm2.
Signed-off-by: Jiri Kosina [EMAIL PROTECTED]
---
include/asm-generic/bug.h |4 ++--
include/linux/debug_locks.h |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index a06eecd..af7574e 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -35,8 +35,8 @@ #ifndef HAVE_ARCH_WARN_ON
#define WARN_ON(condition) ({
\
typeof(condition) __ret_warn_on = (condition); \
if (unlikely(__ret_warn_on)) { \
- printk(WARNING at %s:%d %s()\n, __FILE__, \
- __LINE__, __FUNCTION__);\
+ printk(WARNING (%s) at %s:%d %s()\n, #condition, \
+ __FILE__,__LINE__, __FUNCTION__); \
__FILE__, __LINE__, __FUNCTION__);
(missing space after __FILE__,)
dump_stack(); \
} \
unlikely(__ret_warn_on);\
diff --git a/include/linux/debug_locks.h b/include/linux/debug_locks.h
index 952bee7..1c2b682 100644
--- a/include/linux/debug_locks.h
+++ b/include/linux/debug_locks.h
@@ -25,7 +25,7 @@ ({
\
\
if (unlikely(c)) { \
if (debug_locks_off()) \
- WARN_ON(1); \
+ WARN_ON(c); \
__ret = 1; \
} \
__ret; \
Why not just:
WARN_ON(debug_locks_off())
here? Would give a more readable message too, IMHO.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de InformaticaFono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
-
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: ownership/permissions of cpio initrd
Jeffrey Hundstad <[EMAIL PROTECTED]> wrote: > You can also use fakeroot(1). I think that is a debianism... not here on Fedora. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: ownership/permissions of cpio initrd
Marty Leisner <[EMAIL PROTECTED]> wrote: > I'm working on an embedded system with the 2.6 kernel -- cpio > initrd was a new feature I'm looking at (and very welcome). > > The major advantage I see is you don't have MAKE a filesystem > on the build host (doing cross development). So you don't have > to be root. > But its "useful" to change permissions/ownership of the initrd > files at times... > Since a cpio is just a userspace created string of bits, I suppose > you can apply a set of ownership/permissions to files IN the archive > by playing with the bits... The easy way out is to unpack the initrd, fix permissions, and repack. That requires root, though (it creates devices). > Does such a tool exist? Comments? Seems very useful in order to > avoid being root... I'd use sudo(1) + specially cooked commands to unpack/pack an initrd. It is a bit more work, but gives you extra flexibility (i.e., not just futzing around with permissions, can also add/replace/edit/rename/delete files, ... using bog standard tools). -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: ownership/permissions of cpio initrd
Marty Leisner [EMAIL PROTECTED] wrote: I'm working on an embedded system with the 2.6 kernel -- cpio initrd was a new feature I'm looking at (and very welcome). The major advantage I see is you don't have MAKE a filesystem on the build host (doing cross development). So you don't have to be root. But its useful to change permissions/ownership of the initrd files at times... Since a cpio is just a userspace created string of bits, I suppose you can apply a set of ownership/permissions to files IN the archive by playing with the bits... The easy way out is to unpack the initrd, fix permissions, and repack. That requires root, though (it creates devices). Does such a tool exist? Comments? Seems very useful in order to avoid being root... I'd use sudo(1) + specially cooked commands to unpack/pack an initrd. It is a bit more work, but gives you extra flexibility (i.e., not just futzing around with permissions, can also add/replace/edit/rename/delete files, ... using bog standard tools). -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: ownership/permissions of cpio initrd
Jeffrey Hundstad [EMAIL PROTECTED] wrote: You can also use fakeroot(1). I think that is a debianism... not here on Fedora. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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.19 git compile error - "current_is_keventd" [drivers/net/phy/libphy.ko] undefined
[EMAIL PROTECTED] wrote: > 2006/12/04/18:00 CST > > Building modules, stage 2. > Kernel: arch/x86_64/boot/bzImage is ready (#2) > MODPOST 1256 modules > WARNING: "current_is_keventd" [drivers/net/phy/libphy.ko] undefined! > make[1]: *** [__modpost] Error 1 > make: *** [modules] Error 2 Also i686, sparc64. At drivers/net/phy/phy.c:590 is the lone reference to current_is_keventd in that directory. Still present as of ff51a9... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: la la la la ... swappiness
Aucoin <[EMAIL PROTECTED]> wrote: > From: Horst H. von Brand [mailto:[EMAIL PROTECTED] > > That means that there isn't a need for that memory at all (and so they > In the current isolated non-production, not actually bearing a load test > case yes. But if I can't get it to not swap on an idle system I have no hope > of avoiding OOM on a loaded system. How do you /know/ it won't just be recycled in the production case? > > In any case, how do you know it is the tar data that stays around, and not > > just that the number of pages "in use" stays roughly constant? > > I'm not dumping the contents of memory so I don't. OK. > > - What you are doing, step by step > > Trying to deliver a high availability, linearly scalable, clustered iSCSI > storage solution that can be upgraded with minimum downtime. That is your ultimate goal, not what you are doing, step by step. > > - What are your exact requirements > OOM not to kill anything. Can't ever guarantee that (unless you have the exact memory requirements beforehand, and enough RAM for the worst case). > > - In what exact way is it missbehaving. Please tell /in detail/ how you > OOM kills important stuff. What "important stuff"? How come OOM kills it, when there is plenty of free(able) memory around? Is this in the production setting, or are you just afraid it could happen by what you see in the "current isolated non-production, not actually bearing a load test" case? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: la la la la ... swappiness
Aucoin <[EMAIL PROTECTED]> wrote: [...] > The definition of perfectly good here may be up for debate or > someone can explain it to me. This perfectly good data was > cached under the tar yet hours after the tar has completed the > pages are still cached. That means that there isn't a need for that memory at all (and so they stay around; why actively delete data (using up resources!) needlessly when it would be a win to have them around in the (admittedly remote) case they'll be needed again?), or the whole memory handling in Linux is very broken. I'd vote for the former, i.e., your problems have nothing to do with memory pressure and swapping. That would explain why your maneuvres didn't make a difference... In any case, how do you know it is the tar data that stays around, and not just that the number of pages "in use" stays roughly constant? Please explain again: - What you are doing, step by step - What are your exact requirements - In what exact way is it missbehaving. Please tell /in detail/ how you determine the real behaviour, not your deductions. [Yes, I'm in my "dense" day today.] -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: [Openipmi-developer] [PATCH 9/12] IPMI: add pigeonpoint poweroff
Randy Dunlap <[EMAIL PROTECTED]> wrote: > Bela Lubkin wrote: > > Andrew Morton wrote: > > > >>> Sometime, please go through the IPMI code looking for all these > >>> statically-allocated things which are initialised to 0 or NULL and remove > >>> all those intialisations? They're unneeded, they increase the vmlinux > >>> image size and there are quite a number of them. Thanks. > > Randy Dunlop replied: > > > >> I was just about to send that patch. Here it is, > >> on top of the series-of-12. > > ... > >> -static int bt_debug = BT_DEBUG_OFF; > >> +static int bt_debug; > > Is it wise to significantly degrade code readability to work around > > a minor > > compiler / linker bug? > > Is that the only one that is a problem? > > I don't think it's a problem. We *know* that static data areas > are init to 0. Everything depends on that. If that didn't work > it would all break. Right. And we know NULL == 0. > I could say that it's a nice coincidence that BT_DEBUG_OFF == 0, > but I think that it's more than coincidence. I'd have had to look over the code to find out what it was initialized to. In cases where it is not an explicit 0/NULL, I'd leave it as is. It could also break if somebody later on changes the value of BT_DEBUG_OFF (yes, very unlikely, but...). Bug your friendly GCC guy to loose static initializations to zero (shouldn't be /that/ hard to do...) instead of obfuscating kernel's code. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: [Openipmi-developer] [PATCH 9/12] IPMI: add pigeonpoint poweroff
Randy Dunlap [EMAIL PROTECTED] wrote: Bela Lubkin wrote: Andrew Morton wrote: Sometime, please go through the IPMI code looking for all these statically-allocated things which are initialised to 0 or NULL and remove all those intialisations? They're unneeded, they increase the vmlinux image size and there are quite a number of them. Thanks. Randy Dunlop replied: I was just about to send that patch. Here it is, on top of the series-of-12. ... -static int bt_debug = BT_DEBUG_OFF; +static int bt_debug; Is it wise to significantly degrade code readability to work around a minor compiler / linker bug? Is that the only one that is a problem? I don't think it's a problem. We *know* that static data areas are init to 0. Everything depends on that. If that didn't work it would all break. Right. And we know NULL == 0. I could say that it's a nice coincidence that BT_DEBUG_OFF == 0, but I think that it's more than coincidence. I'd have had to look over the code to find out what it was initialized to. In cases where it is not an explicit 0/NULL, I'd leave it as is. It could also break if somebody later on changes the value of BT_DEBUG_OFF (yes, very unlikely, but...). Bug your friendly GCC guy to loose static initializations to zero (shouldn't be /that/ hard to do...) instead of obfuscating kernel's code. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: la la la la ... swappiness
Aucoin [EMAIL PROTECTED] wrote: [...] The definition of perfectly good here may be up for debate or someone can explain it to me. This perfectly good data was cached under the tar yet hours after the tar has completed the pages are still cached. That means that there isn't a need for that memory at all (and so they stay around; why actively delete data (using up resources!) needlessly when it would be a win to have them around in the (admittedly remote) case they'll be needed again?), or the whole memory handling in Linux is very broken. I'd vote for the former, i.e., your problems have nothing to do with memory pressure and swapping. That would explain why your maneuvres didn't make a difference... In any case, how do you know it is the tar data that stays around, and not just that the number of pages in use stays roughly constant? Please explain again: - What you are doing, step by step - What are your exact requirements - In what exact way is it missbehaving. Please tell /in detail/ how you determine the real behaviour, not your deductions. [Yes, I'm in my dense day today.] -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: la la la la ... swappiness
Aucoin [EMAIL PROTECTED] wrote: From: Horst H. von Brand [mailto:[EMAIL PROTECTED] That means that there isn't a need for that memory at all (and so they In the current isolated non-production, not actually bearing a load test case yes. But if I can't get it to not swap on an idle system I have no hope of avoiding OOM on a loaded system. How do you /know/ it won't just be recycled in the production case? In any case, how do you know it is the tar data that stays around, and not just that the number of pages in use stays roughly constant? I'm not dumping the contents of memory so I don't. OK. - What you are doing, step by step Trying to deliver a high availability, linearly scalable, clustered iSCSI storage solution that can be upgraded with minimum downtime. That is your ultimate goal, not what you are doing, step by step. - What are your exact requirements OOM not to kill anything. Can't ever guarantee that (unless you have the exact memory requirements beforehand, and enough RAM for the worst case). - In what exact way is it missbehaving. Please tell /in detail/ how you OOM kills important stuff. What important stuff? How come OOM kills it, when there is plenty of free(able) memory around? Is this in the production setting, or are you just afraid it could happen by what you see in the current isolated non-production, not actually bearing a load test case? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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.19 git compile error - current_is_keventd [drivers/net/phy/libphy.ko] undefined
[EMAIL PROTECTED] wrote: 2006/12/04/18:00 CST Building modules, stage 2. Kernel: arch/x86_64/boot/bzImage is ready (#2) MODPOST 1256 modules WARNING: current_is_keventd [drivers/net/phy/libphy.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 Also i686, sparc64. At drivers/net/phy/phy.c:590 is the lone reference to current_is_keventd in that directory. Still present as of ff51a9... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: la la la la ... swappiness
Aucoin <[EMAIL PROTECTED]> wrote: > We want it to swap less for this particular operation because it is low > priority compared to the rest of what's going on inside the box. The swapping is not a "operation" thing, it is global for /all/ what is going on in the box. And having it swap less means assigning it more RAM, i.e., giving it higher (not lower) priority than other stuff happening at the same time. I guess I don't understand what your needs are (not what you want to do to get there). -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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/
2.6.19 git 2b5f6dcce...: current_is_keventd() AWOL?
Trying to compile that kernel on i686 the build fails in drivers/net/phy/libphy.ko (drivers/net/phy/phy.c, line 590) due to current_is_keventd() missing. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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/
2.6.19 git 2b5f6dcce...: current_is_keventd() AWOL?
Trying to compile that kernel on i686 the build fails in drivers/net/phy/libphy.ko (drivers/net/phy/phy.c, line 590) due to current_is_keventd() missing. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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: la la la la ... swappiness
Aucoin [EMAIL PROTECTED] wrote: We want it to swap less for this particular operation because it is low priority compared to the rest of what's going on inside the box. The swapping is not a operation thing, it is global for /all/ what is going on in the box. And having it swap less means assigning it more RAM, i.e., giving it higher (not lower) priority than other stuff happening at the same time. I guess I don't understand what your needs are (not what you want to do to get there). -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - 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/
