Re: [PATCH] Allow kconfig to accept overrides
On Oct 18 2007 15:29, Sam Ravnborg wrote:
>> Yeah, I've put in
>> ("override: %s changes choice state", sym->name);
>> this morning.
>Care to send me the updated patch.
>
===
Allow config variables in .config to override earlier ones in the same
file. In other words,
# CONFIG_SECURITY is not defined
CONFIG_SECURITY=y
will activate it. This makes it a bit easier to do
(cat original-config myconfig myconfig2 ... >.config)
and run menuconfig as expected.
Posted at:
http://lkml.org/lkml/2006/10/25/81
http://lkml.org/lkml/2007/4/1/175
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
Cc: Sam Ravnborg <[EMAIL PROTECTED]>
Cc: Roman Zippel <[EMAIL PROTECTED]>
Cc: Randy Dunlap <[EMAIL PROTECTED]>
---
scripts/kconfig/confdata.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
Index: linux-2.6.23.1/scripts/kconfig/confdata.c
===
--- linux-2.6.23.1.orig/scripts/kconfig/confdata.c
+++ linux-2.6.23.1/scripts/kconfig/confdata.c
@@ -170,8 +170,7 @@ load:
sym->type = S_BOOLEAN;
}
if (sym->flags & def_flags) {
- conf_warning("trying to reassign symbol %s",
sym->name);
- break;
+ conf_warning("override: reassigning to symbol
%s", sym->name);
}
switch (sym->type) {
case S_BOOLEAN:
@@ -210,8 +209,7 @@ load:
sym->type = S_OTHER;
}
if (sym->flags & def_flags) {
- conf_warning("trying to reassign symbol %s",
sym->name);
- break;
+ conf_warning("override: reassigning to symbol
%s", sym->name);
}
switch (sym->type) {
case S_TRISTATE:
@@ -288,11 +286,9 @@ load:
}
break;
case yes:
- if (cs->def[def].tri != no) {
- conf_warning("%s creates inconsistent
choice state", sym->name);
- cs->flags &= ~def_flags;
- } else
- cs->def[def].val = sym;
+ if(cs->def[def].tri != no)
+ conf_warning("override: %s changes
choice state", sym->name);
+ cs->def[def].val = sym;
break;
}
cs->def[def].tri = E_OR(cs->def[def].tri,
sym->def[def].tri);
-
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] Allow kconfig to accept overrides
On Oct 18 2007 15:29, Sam Ravnborg wrote:
Yeah, I've put in
(override: %s changes choice state, sym-name);
this morning.
Care to send me the updated patch.
===
Allow config variables in .config to override earlier ones in the same
file. In other words,
# CONFIG_SECURITY is not defined
CONFIG_SECURITY=y
will activate it. This makes it a bit easier to do
(cat original-config myconfig myconfig2 ... .config)
and run menuconfig as expected.
Posted at:
http://lkml.org/lkml/2006/10/25/81
http://lkml.org/lkml/2007/4/1/175
Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]
Cc: Sam Ravnborg [EMAIL PROTECTED]
Cc: Roman Zippel [EMAIL PROTECTED]
Cc: Randy Dunlap [EMAIL PROTECTED]
---
scripts/kconfig/confdata.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
Index: linux-2.6.23.1/scripts/kconfig/confdata.c
===
--- linux-2.6.23.1.orig/scripts/kconfig/confdata.c
+++ linux-2.6.23.1/scripts/kconfig/confdata.c
@@ -170,8 +170,7 @@ load:
sym-type = S_BOOLEAN;
}
if (sym-flags def_flags) {
- conf_warning(trying to reassign symbol %s,
sym-name);
- break;
+ conf_warning(override: reassigning to symbol
%s, sym-name);
}
switch (sym-type) {
case S_BOOLEAN:
@@ -210,8 +209,7 @@ load:
sym-type = S_OTHER;
}
if (sym-flags def_flags) {
- conf_warning(trying to reassign symbol %s,
sym-name);
- break;
+ conf_warning(override: reassigning to symbol
%s, sym-name);
}
switch (sym-type) {
case S_TRISTATE:
@@ -288,11 +286,9 @@ load:
}
break;
case yes:
- if (cs-def[def].tri != no) {
- conf_warning(%s creates inconsistent
choice state, sym-name);
- cs-flags = ~def_flags;
- } else
- cs-def[def].val = sym;
+ if(cs-def[def].tri != no)
+ conf_warning(override: %s changes
choice state, sym-name);
+ cs-def[def].val = sym;
break;
}
cs-def[def].tri = E_OR(cs-def[def].tri,
sym-def[def].tri);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Shadow directories
On Oct 18 2007 17:21, Jaroslav Sykora wrote: Hello, Let's say we have an archive file hello.zip with a hello world program source code. We want to do this: cat hello.zip^/hello.c gcc hello.zip^/hello.c -o hello etc.. The '^' is an escape character and it tells the computer to treat the file as a directory. Too bad, since ^ is a valid character in a *file*name. Everything is, with the exception of '\0' and '/'. At the end of the day, there are no control characters you could use. But what you could do is: write a FUSE fs that mirrors the lower content (lofs/fuseloop/however it was named) and expands .zip files as directories are readdir'ed or the zip files stat'ed. That saves us from cluttering up the Linux VFS with such stuff. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Shadow directories
On Oct 18 2007 19:07, Jaroslav Sykora wrote: On Oct 18 2007 17:21, Jaroslav Sykora wrote: Hello, Let's say we have an archive file hello.zip with a hello world program source code. We want to do this: cat hello.zip^/hello.c gcc hello.zip^/hello.c -o hello etc.. The '^' is an escape character and it tells the computer to treat the file as a directory. But what you could do is: write a FUSE fs that mirrors the lower content (lofs/fuseloop/however it was named) and expands .zip files as directories are readdir'ed or the zip files stat'ed. That saves us from cluttering up the Linux VFS with such stuff. Yes, that's exactly what RheaVFS and AVFS do. Except that they both use an escape character because: 1. without it some programs may break [ http://lwn.net/Articles/100148/ ] 2. it's very useful to pass additional parameters after the escape char to the server. We can start VFS servers (mentioned above) and chroot the whole user session into the mount directory of the server. It works but it's very slow, practically unusable. Sounds like a program bug, since NTFS-3G is proof of concept that FUSE can be fast. If anybody can think of any other solution of the redirector problem, possibly even non-kernel based one, let me know and I'd be glad :-) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Shadow directories
On Oct 18 2007 22:10, Jaroslav Sykora wrote: A minor implementation problem with chrooted environment is that the FUSE VFS server must be run with root privileges to allow setuid programs on the mounted filesystems. But it's certainly doable. You would not want user-supplied filesystems to carry SUID bits... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] Shadow directories
On Oct 19 2007 05:32, David Newall wrote: The claim is wrong. UNIX systems have traditionally allowed the superuser to create hard links to directories. See link(2) for 2.10BSD http://www.freebsd.org/cgi/man.cgi?query=linksektion=2manpath=2.10+BSD. Having got that wrong throws doubt on the argument; perhaps a path can simultaneously be a file and a directory. But hell will break lose if you allow hardlinking directories. mkdir /tmp/a ln /tmp/a /tmp/a/b And you would not be able to rmdir /tmp/a/b because the directory is not empty (it contains b [full path: /tmp/a/b/b]). - 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: your mail
On Oct 17 2007 16:30, [EMAIL PROTECTED] wrote: >Date: Wed, 17 Oct 2007 16:30:24 + >From: <[EMAIL PROTECTED]> >To: ^^ > >subscribe linux-alpha ^ - 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] vc bell config
On Oct 11 2007 18:11, Pavel Machek wrote: > >> It is already possible to deactivate the vc bell on a per-tty basis, >> by using echo -en "\e[11;0]", but this is reset on reset(1). >> >> This adds a sysfs parameter to globally control the vc bell, as well >> as sysfs parameters for default pitch and duration. >> >> Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]> > >There are more parameters that should be set during reset... like >cursor size and color, palette, What about /sys/.../string_to_interpret >_on_reset ? On reset(1), cursor size, palette, and bell parameters _do_ get reset to the defaults. Some defaults may already be changed by the user, like palette or default_utf8. Bell configuration is currently not one of them so, should a program decide to reset the tty, or should it happen that your output is garbled (forcing you to do reset), some settings change back to "unwanted defaults". - 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: Community research
On Oct 17 2007 15:13, Kristoffer Ericson wrote: >> >> 536 total / 472 from Hungary / 4 United States / 1 Ukraine / 1 UK / 1 >> Turkey / 2 Sweden / 4 Slovakia / 1 Singapore / 2 Serbia / 2 Russia / 7 > >sweden only 2? And how did Hungary get so many developers? Supposedly gave the link to all friends and/or forums in the area. Yes, this shows one thing: LKML is largely not interested in surveys. Way too many students decide to take surveys (which are not even LKML-centric!), it is getting boring - that is my impression. - 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: Community research
On Oct 17 2007 15:13, Kristoffer Ericson wrote: 536 total / 472 from Hungary / 4 United States / 1 Ukraine / 1 UK / 1 Turkey / 2 Sweden / 4 Slovakia / 1 Singapore / 2 Serbia / 2 Russia / 7 sweden only 2? And how did Hungary get so many developers? Supposedly gave the link to all friends and/or forums in the area. Yes, this shows one thing: LKML is largely not interested in surveys. Way too many students decide to take surveys (which are not even LKML-centric!), it is getting boring - that is my impression. - 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] vc bell config
On Oct 11 2007 18:11, Pavel Machek wrote: It is already possible to deactivate the vc bell on a per-tty basis, by using echo -en \e[11;0], but this is reset on reset(1). This adds a sysfs parameter to globally control the vc bell, as well as sysfs parameters for default pitch and duration. Signed-off-by: Jan Engelhardt [EMAIL PROTECTED] There are more parameters that should be set during reset... like cursor size and color, palette, What about /sys/.../string_to_interpret _on_reset ? On reset(1), cursor size, palette, and bell parameters _do_ get reset to the defaults. Some defaults may already be changed by the user, like palette or default_utf8. Bell configuration is currently not one of them so, should a program decide to reset the tty, or should it happen that your output is garbled (forcing you to do reset), some settings change back to unwanted defaults. - 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: your mail
On Oct 17 2007 16:30, [EMAIL PROTECTED] wrote: Date: Wed, 17 Oct 2007 16:30:24 + From: [EMAIL PROTECTED] To: linux-kernel@vger.kernel.org ^^ subscribe linux-alpha ^ - 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: WANTED: kernel projects for CS students
On Oct 16 2007 16:23, Rik van Riel wrote: >> >base function: >> >Starting from a stock distro (FC, Ubuntu, OpenSuSE...) and put down a >> >kernel.org tree and automatically create a .config with all the >> >drivers needed for the platform I'm building on. >> >> Too easy. Since opensuse's udev loads most of the modules for your >> hardware, all that would be needed is to transform the lsmod list of >> modules plus the static options in /proc/config.gz (stuff like >> psmouse) back into kconfig options ;-) > >Well, at that point it does not know whether or not you >occasionally plug in an ipod or a digital camera. Which is why building an allmod kernel (or what the distros do) is IMO the better solution. - 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: WANTED: kernel projects for CS students
On Oct 16 2007 13:06, Mark Gross wrote: > >base function: >Starting from a stock distro (FC, Ubuntu, OpenSuSE...) and put down a >kernel.org tree and automatically create a .config with all the drivers >needed for the platform I'm building on. Too easy. Since opensuse's udev loads most of the modules for your hardware, all that would be needed is to transform the lsmod list of modules plus the static options in /proc/config.gz (stuff like psmouse) back into kconfig options ;-) - 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] Allow kconfig to accept overrides
Hi Sam, On Oct 16 2007 06:29, Sam Ravnborg wrote: >On Fri, Oct 12, 2007 at 11:44:08PM +0200, Jan Engelhardt wrote: >> >> Allow config variables in .config to override earlier ones in the same >> file. In other words, >> >> # CONFIG_SECURITY is not defined >> CONFIG_SECURITY=y >> >> will activate it. This makes it a bit easier to do >> >> (cat original-config myconfig myconfig2 ... >.config) >> >> and run menuconfig as expected. > > >How far is this from the miniconfig functionality? >Is it the same or can we achieve the miniconfig support >by extending Jan's patch? > >See: http://lkml.org/lkml/2007/10/12/391 miniconfig actually does something completely different as far as I understand: miniconfig creates a minimal config that does not contain default choices for CONFIG_ files, while the patch that I was trying to submit here allows to override entries in a .config by just appending them to the file. I already have a miniconfig, so to speak, and want to merge it with the previous .config so as to produce a fullconfig. (Something like the exact opposite) thanks, Jan - 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: In response to kernel compression e-mail a few months ago.
On Oct 16 2007 14:19, Denys Vlasenko wrote: >Sizes in Kb again: > >32392 linux-2.6.16.17.tar.7z >33520 linux-2.6.16.17.tar.lzma > >P.S. sorting files by extension in tarball generally helps, but in case >of Linux kernel, they are all C code anyway, so no measurable gain there. Extension is not all so interesting because, as you point out, most of it is C code, and .h files are mostly like .c in that they have structs and function prototype keywords. But sorting by name buys: -rw-r--r-- 1 jengelh users 45477128 Oct 12 18:47 linux-2.6.23.1.orig.tar.bz2 -rw-r--r-- 1 jengelh users 45560647 Oct 16 16:18 linux-2.6.23.1.new.tar.bz2 (actually, `find "$@" -print0 | sort -z | tar -T- --null --no-r --owner=root --group=root -cvjf "$output";` was used) - 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][rfc] rewrite ramdisk
On Oct 16 2007 18:26, Nick Piggin wrote: >> >> It also does not seem needed, since it did not exist before. >> >> It should go, you can set the variable with brd.rd_nr=XXX (same >> >> goes for ramdisk_size). >> > >> >But only if it's a module? >> >> Attributes always work. Try vt.default_red=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 >> and you will see. > >Ah, nice. (I don't use them much!). Still, backward compat I >think is needed if we are to replace rd.c. > Like I said, I did not see rd_nr in Documentation/kernel-parameters.txt so I thought there was no compat. - 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][rfc] rewrite ramdisk
On Oct 16 2007 18:07, Nick Piggin wrote: >Changed. But it will hopefully just completely replace rd.c, >so I will probably just rename it to rd.c at some point (and >change .config options to stay compatible). Unless someone >sees a problem with that? I do not see a problem with keeping brd either. >> It also does not seem needed, since it did not exist before. >> It should go, you can set the variable with brd.rd_nr=XXX (same >> goes for ramdisk_size). > >But only if it's a module? Attributes always work. Try vt.default_red=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 and you will 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: [patch][rfc] rewrite ramdisk
On Oct 16 2007 17:47, Nick Piggin wrote:
>
>Here's a quick first hack...
Inline patches preferred ;-)
>+config BLK_DEV_BRD
>+ tristate "RAM block device support"
>+ ---help---
>+This is a new based block driver that replaces BLK_DEV_RAM.
based on what? -^
>+To compile this driver as a module, choose M here: the
>+module will be called rd.
called brd.ko.
>+/*
>+ * And now the modules code and kernel interface.
>+ */
>+static int rd_nr;
>+static int rd_size = CONFIG_BLK_DEV_RAM_SIZE;
Perhaps unsigned?
Perhaps even long for rd_size?
>+module_param(rd_nr, int, 0);
>+MODULE_PARM_DESC(rd_nr, "Maximum number of brd devices");
>+module_param(rd_size, int, 0);
>+MODULE_PARM_DESC(rd_size, "Size of each RAM disk in kbytes.");
>+MODULE_LICENSE("GPL");
>+MODULE_ALIAS_BLOCKDEV_MAJOR(RAMDISK_MAJOR);
>+
>+/* options - nonmodular */
>+#ifndef MODULE
>+static int __init ramdisk_size(char *str)
>+{
>+ rd_size = simple_strtol(str,NULL,0);
>+ return 1;
>+}
Is this, besides for compatibility, really needed?
>+static int __init ramdisk_size2(char *str)
>+{
>+ return ramdisk_size(str);
>+}
>+static int __init rd_nr(char *str)
Err! Overlapping symbols! The rd_nr() function collides with the rd_nr
variable. It also does not seem needed, since it did not exist before.
It should go, you can set the variable with brd.rd_nr=XXX (same
goes for ramdisk_size). What's the point of ramdisk_size2()?
>+{
>+ rd_nr = simple_strtol(str, NULL, 0);
>+ return 1;
>+}
>+__setup("ramdisk=", ramdisk_size);
>+__setup("ramdisk_size=", ramdisk_size2);
__setup("ramdisk_size=", ramdisk_size); maybe, or does not that work?
>+__setup("rd_nr=", rd_nr);
>+#endif
>+
>+
>+static struct brd_device *brd_alloc(int i)
>+{
>+ struct brd_device *brd;
>+ struct gendisk *disk;
>+
>+ brd = kzalloc(sizeof(*brd), GFP_KERNEL);
>+ if (!brd)
>+ goto out;
>+ brd->brd_number = i;
-
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][rfc] rewrite ramdisk
On Oct 16 2007 17:47, Nick Piggin wrote:
Here's a quick first hack...
Inline patches preferred ;-)
+config BLK_DEV_BRD
+ tristate RAM block device support
+ ---help---
+This is a new based block driver that replaces BLK_DEV_RAM.
based on what? -^
+To compile this driver as a module, choose M here: the
+module will be called rd.
called brd.ko.
+/*
+ * And now the modules code and kernel interface.
+ */
+static int rd_nr;
+static int rd_size = CONFIG_BLK_DEV_RAM_SIZE;
Perhaps unsigned?
Perhaps even long for rd_size?
+module_param(rd_nr, int, 0);
+MODULE_PARM_DESC(rd_nr, Maximum number of brd devices);
+module_param(rd_size, int, 0);
+MODULE_PARM_DESC(rd_size, Size of each RAM disk in kbytes.);
+MODULE_LICENSE(GPL);
+MODULE_ALIAS_BLOCKDEV_MAJOR(RAMDISK_MAJOR);
+
+/* options - nonmodular */
+#ifndef MODULE
+static int __init ramdisk_size(char *str)
+{
+ rd_size = simple_strtol(str,NULL,0);
+ return 1;
+}
Is this, besides for compatibility, really needed?
+static int __init ramdisk_size2(char *str)
+{
+ return ramdisk_size(str);
+}
+static int __init rd_nr(char *str)
Err! Overlapping symbols! The rd_nr() function collides with the rd_nr
variable. It also does not seem needed, since it did not exist before.
It should go, you can set the variable with brd.rd_nr=XXX (same
goes for ramdisk_size). What's the point of ramdisk_size2()?
+{
+ rd_nr = simple_strtol(str, NULL, 0);
+ return 1;
+}
+__setup(ramdisk=, ramdisk_size);
+__setup(ramdisk_size=, ramdisk_size2);
__setup(ramdisk_size=, ramdisk_size); maybe, or does not that work?
+__setup(rd_nr=, rd_nr);
+#endif
+
+
+static struct brd_device *brd_alloc(int i)
+{
+ struct brd_device *brd;
+ struct gendisk *disk;
+
+ brd = kzalloc(sizeof(*brd), GFP_KERNEL);
+ if (!brd)
+ goto out;
+ brd-brd_number = i;
-
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][rfc] rewrite ramdisk
On Oct 16 2007 18:07, Nick Piggin wrote: Changed. But it will hopefully just completely replace rd.c, so I will probably just rename it to rd.c at some point (and change .config options to stay compatible). Unless someone sees a problem with that? I do not see a problem with keeping brd either. It also does not seem needed, since it did not exist before. It should go, you can set the variable with brd.rd_nr=XXX (same goes for ramdisk_size). But only if it's a module? Attributes always work. Try vt.default_red=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 and you will 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: [patch][rfc] rewrite ramdisk
On Oct 16 2007 18:26, Nick Piggin wrote: It also does not seem needed, since it did not exist before. It should go, you can set the variable with brd.rd_nr=XXX (same goes for ramdisk_size). But only if it's a module? Attributes always work. Try vt.default_red=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 and you will see. Ah, nice. (I don't use them much!). Still, backward compat I think is needed if we are to replace rd.c. Like I said, I did not see rd_nr in Documentation/kernel-parameters.txt so I thought there was no compat. - 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: In response to kernel compression e-mail a few months ago.
On Oct 16 2007 14:19, Denys Vlasenko wrote: Sizes in Kb again: 32392 linux-2.6.16.17.tar.7z 33520 linux-2.6.16.17.tar.lzma P.S. sorting files by extension in tarball generally helps, but in case of Linux kernel, they are all C code anyway, so no measurable gain there. Extension is not all so interesting because, as you point out, most of it is C code, and .h files are mostly like .c in that they have structs and function prototype keywords. But sorting by name buys: -rw-r--r-- 1 jengelh users 45477128 Oct 12 18:47 linux-2.6.23.1.orig.tar.bz2 -rw-r--r-- 1 jengelh users 45560647 Oct 16 16:18 linux-2.6.23.1.new.tar.bz2 (actually, `find $@ -print0 | sort -z | tar -T- --null --no-r --owner=root --group=root -cvjf $output;` was used) - 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] Allow kconfig to accept overrides
Hi Sam, On Oct 16 2007 06:29, Sam Ravnborg wrote: On Fri, Oct 12, 2007 at 11:44:08PM +0200, Jan Engelhardt wrote: Allow config variables in .config to override earlier ones in the same file. In other words, # CONFIG_SECURITY is not defined CONFIG_SECURITY=y will activate it. This makes it a bit easier to do (cat original-config myconfig myconfig2 ... .config) and run menuconfig as expected. How far is this from the miniconfig functionality? Is it the same or can we achieve the miniconfig support by extending Jan's patch? See: http://lkml.org/lkml/2007/10/12/391 miniconfig actually does something completely different as far as I understand: miniconfig creates a minimal config that does not contain default choices for CONFIG_ files, while the patch that I was trying to submit here allows to override entries in a .config by just appending them to the file. I already have a miniconfig, so to speak, and want to merge it with the previous .config so as to produce a fullconfig. (Something like the exact opposite) thanks, Jan - 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: WANTED: kernel projects for CS students
On Oct 16 2007 13:06, Mark Gross wrote: base function: Starting from a stock distro (FC, Ubuntu, OpenSuSE...) and put down a kernel.org tree and automatically create a .config with all the drivers needed for the platform I'm building on. Too easy. Since opensuse's udev loads most of the modules for your hardware, all that would be needed is to transform the lsmod list of modules plus the static options in /proc/config.gz (stuff like psmouse) back into kconfig options ;-) - 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: WANTED: kernel projects for CS students
On Oct 16 2007 16:23, Rik van Riel wrote: base function: Starting from a stock distro (FC, Ubuntu, OpenSuSE...) and put down a kernel.org tree and automatically create a .config with all the drivers needed for the platform I'm building on. Too easy. Since opensuse's udev loads most of the modules for your hardware, all that would be needed is to transform the lsmod list of modules plus the static options in /proc/config.gz (stuff like psmouse) back into kconfig options ;-) Well, at that point it does not know whether or not you occasionally plug in an ipod or a digital camera. Which is why building an allmod kernel (or what the distros do) is IMO the better solution. - 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: WANTED: kernel projects for CS students
On Oct 15 2007 18:36, Philippe Elie wrote: >> >> Isn't make -j 2 or more implemented by running multiple make in sub-dirs ? >> Parallel make is more and more used even on cheap hardware. > >Errm, I misread what you said, it can be a single Makefile in each sub-dirs Even now, make -j8 really pays off on bigiron AMD. - 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: WANTED: kernel projects for CS students
On Oct 15 2007 18:36, Philippe Elie wrote: Isn't make -j 2 or more implemented by running multiple make in sub-dirs ? Parallel make is more and more used even on cheap hardware. Errm, I misread what you said, it can be a single Makefile in each sub-dirs Even now, make -j8 really pays off on bigiron AMD. - 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: In response to kernel compression e-mail a few months ago.
On Oct 14 2007 16:58, Justin Piszcz wrote: > > compress: > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > 10544 war 20 0 700m 681m 1632 S 141 20.7 1:41.46 7z Just how you can utilize a CPU to 141% remains a mystery.. [ to be noted this is sqrt(2)*100 ] - 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: In response to kernel compression e-mail a few months ago.
On Oct 14 2007 15:53, Justin Piszcz wrote: >> >> What's with all these odd formats, and where is .zip? :) >> Somehow... have you tried lrzip? > $ apt-cache search lrzip > $ > > I tried most of the main ones in the standard testing distribution within > Debian. Debian is not a solution to everything. http://ck.kolivas.org/apps/lrzip/ - 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: In response to kernel compression e-mail a few months ago.
On Oct 14 2007 15:34, Justin Piszcz wrote: > > It turns out the one I did not test, was actually the best: > > Used: 7z -mx=9 a linux-2.6.16.17.tar.7z linux-2.6.16.17.tar > > $ du -sk * | sort -n > 32392 linux-2.6.16.17.tar.7z > 33520 linux-2.6.16.17.tar.lzma > 33760 linux-2.6.16.17.tar.rar > 38064 linux-2.6.16.17.tar.rz > 39472 linux-2.6.16.17.tar.szip > 39520 linux-2.6.16.17.tar.bz > 39936 linux-2.6.16.17.tar.bz2 > 4 linux-2.6.16.17.tar.bicom > 40656 linux-2.6.16.17.tar.sit > 47664 linux-2.6.16.17.tar.lha > 49968 linux-2.6.16.17.tar.dzip > 5 linux-2.6.16.17.tar.gz > 51344 linux-2.6.16.17.tar.arj > 57552 linux-2.6.16.17.tar.lzo > 57984 linux-2.6.16.17.tar.F > 81136 linux-2.6.16.17.tar.Z > 94544 linux-2.6.16.17.tar.zoo > 101216 linux-2.6.16.17.tar.arc > 228608 linux-2.6.16.17.tar What's with all these odd formats, and where is .zip? :) Somehow... have you tried lrzip? Furthermore, if the files in the .tar archive were actually sorted.. (Obviously we shall pick .7z) - 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: System.map
On Oct 14 2007 19:07, Philip wrote: > >I want to write a script, which shows the name of the relevant >kernel module for each listed pci device shown by 'lspci -m'. It's >easy to find out the name of the corresponding module, if the driver >has been compiled as a loadable kernel module: The file >/lib/modules/$(uname -r)/modules.pcimap lists module names based on >pci device's vendor -and device id (shown by 'lspci -n'). But how >can I find out the name of the corresponding kernel module if the >module has been compiled directly into the kernel ? Well if it is compiled in, it is not a module, so you cannot find it the usual way. >I thought that I >can find them in the kernel's machting System.map based on vendor >-and device id as well. But I can't find those id's there. Where do >I have to look for it ? I want to be informed by my script, if the >driver (module) for a specific pci device is available as a loadable >module, in-kernel module or not available at all. That does not work reliably either. There might be PCI devices which have the same PID:VID, but need a readb() or so for further finding out whether the actual piece of hardware has a driver. And then there is that sort of modules which do not have typical IDs (i.e. udev cannot/won't autoload them) at all, like pcspkr.ko/psmouse.ko - 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: wierd file perms
On Oct 14 2007 09:27, Mark Lord wrote: > Jan-Benedict Glaw wrote: >> On Sat, 2007-10-13 22:40:23 +0530, vignesh babu <[EMAIL PROTECTED]> >> wrote: >> > I was surprised and did an ls -l on the files and guess what I found: >> > >> > total 0 >> > ?- ? ? ? ?? fcntl.c >> > ?- ? ? ? ?? fifo.c >> > ?- ? ? ? ?? filesystems.c >> > ?- ? ? ? ?? file_table.c >> > ?- ? ? ? ?? freevxfs >> > >> > So end result is that, Im not able to delete the files or change perms >> > or ownership even as root. >> >> Most probably, your filesystem is broken and needs a fsck. > > No, this is perfectly normal behaviour, for when a directory > has READ permissions but not EXECUTE permissions. Er, close. 16:02 ichi:/dev/shm > md a 16:02 ichi:/dev/shm > touch a/b 16:02 ichi:/dev/shm > chmod 644 a 16:02 ichi:/dev/shm > ls -l a /bin/ls: cannot access a/b: Permission denied total 0 -? ? ? ? ?? b 16:02 ichi:/dev/shm > ls --version ls (GNU coreutils) 6.9 There is a difference .. "-?" vs "?-". The first looks to me like "filetype known (S_IFREG)", while the latter is "filetype and mode unknown". - 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: wierd file perms
On Oct 14 2007 14:30, Bauke Jan Douma wrote: >> On Sat, 2007-10-13 22:40:23 +0530, vignesh babu <[EMAIL PROTECTED]> >> wrote: >> > I was surprised and did an ls -l on the files and guess what I found: >> > >> > total 0 >> > ?- ? ? ? ?? fcntl.c >> > ?- ? ? ? ?? fifo.c >> > ?- ? ? ? ?? filesystems.c >> > ?- ? ? ? ?? file_table.c >> > ?- ? ? ? ?? freevxfs >> > >> > So end result is that, Im not able to delete the files or change perms >> > or ownership even as root. >> >> Most probably, your filesystem is broken and needs a fsck. > > I don't think this is a bug, but a feature of 'ls', see for instance > the coreutils mailing list: > > http://lists.gnu.org/archive/html/bug-coreutils/2007-05/msg00226.html - broken on-disk fs - you are not allowed to stat() -- which can only reasonably happen with FUSE or remote filesystems - ls also outputs ?- if the file mode does not make sense, though as we can see, UID/GID nlink, etc. are also missing, so I suspect item 2. - 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: wierd file perms
On Oct 14 2007 14:30, Bauke Jan Douma wrote: On Sat, 2007-10-13 22:40:23 +0530, vignesh babu [EMAIL PROTECTED] wrote: I was surprised and did an ls -l on the files and guess what I found: total 0 ?- ? ? ? ?? fcntl.c ?- ? ? ? ?? fifo.c ?- ? ? ? ?? filesystems.c ?- ? ? ? ?? file_table.c ?- ? ? ? ?? freevxfs So end result is that, Im not able to delete the files or change perms or ownership even as root. Most probably, your filesystem is broken and needs a fsck. I don't think this is a bug, but a feature of 'ls', see for instance the coreutils mailing list: http://lists.gnu.org/archive/html/bug-coreutils/2007-05/msg00226.html - broken on-disk fs - you are not allowed to stat() -- which can only reasonably happen with FUSE or remote filesystems - ls also outputs ?- if the file mode does not make sense, though as we can see, UID/GID nlink, etc. are also missing, so I suspect item 2. - 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: wierd file perms
On Oct 14 2007 09:27, Mark Lord wrote: Jan-Benedict Glaw wrote: On Sat, 2007-10-13 22:40:23 +0530, vignesh babu [EMAIL PROTECTED] wrote: I was surprised and did an ls -l on the files and guess what I found: total 0 ?- ? ? ? ?? fcntl.c ?- ? ? ? ?? fifo.c ?- ? ? ? ?? filesystems.c ?- ? ? ? ?? file_table.c ?- ? ? ? ?? freevxfs So end result is that, Im not able to delete the files or change perms or ownership even as root. Most probably, your filesystem is broken and needs a fsck. No, this is perfectly normal behaviour, for when a directory has READ permissions but not EXECUTE permissions. Er, close. 16:02 ichi:/dev/shm md a 16:02 ichi:/dev/shm touch a/b 16:02 ichi:/dev/shm chmod 644 a 16:02 ichi:/dev/shm ls -l a /bin/ls: cannot access a/b: Permission denied total 0 -? ? ? ? ?? b 16:02 ichi:/dev/shm ls --version ls (GNU coreutils) 6.9 There is a difference .. -? vs ?-. The first looks to me like filetype known (S_IFREG), while the latter is filetype and mode unknown. - 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: System.map
On Oct 14 2007 19:07, Philip wrote: I want to write a script, which shows the name of the relevant kernel module for each listed pci device shown by 'lspci -m'. It's easy to find out the name of the corresponding module, if the driver has been compiled as a loadable kernel module: The file /lib/modules/$(uname -r)/modules.pcimap lists module names based on pci device's vendor -and device id (shown by 'lspci -n'). But how can I find out the name of the corresponding kernel module if the module has been compiled directly into the kernel ? Well if it is compiled in, it is not a module, so you cannot find it the usual way. I thought that I can find them in the kernel's machting System.map based on vendor -and device id as well. But I can't find those id's there. Where do I have to look for it ? I want to be informed by my script, if the driver (module) for a specific pci device is available as a loadable module, in-kernel module or not available at all. That does not work reliably either. There might be PCI devices which have the same PID:VID, but need a readb() or so for further finding out whether the actual piece of hardware has a driver. And then there is that sort of modules which do not have typical IDs (i.e. udev cannot/won't autoload them) at all, like pcspkr.ko/psmouse.ko - 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: In response to kernel compression e-mail a few months ago.
On Oct 14 2007 15:34, Justin Piszcz wrote: It turns out the one I did not test, was actually the best: Used: 7z -mx=9 a linux-2.6.16.17.tar.7z linux-2.6.16.17.tar $ du -sk * | sort -n 32392 linux-2.6.16.17.tar.7z 33520 linux-2.6.16.17.tar.lzma 33760 linux-2.6.16.17.tar.rar 38064 linux-2.6.16.17.tar.rz 39472 linux-2.6.16.17.tar.szip 39520 linux-2.6.16.17.tar.bz 39936 linux-2.6.16.17.tar.bz2 4 linux-2.6.16.17.tar.bicom 40656 linux-2.6.16.17.tar.sit 47664 linux-2.6.16.17.tar.lha 49968 linux-2.6.16.17.tar.dzip 5 linux-2.6.16.17.tar.gz 51344 linux-2.6.16.17.tar.arj 57552 linux-2.6.16.17.tar.lzo 57984 linux-2.6.16.17.tar.F 81136 linux-2.6.16.17.tar.Z 94544 linux-2.6.16.17.tar.zoo 101216 linux-2.6.16.17.tar.arc 228608 linux-2.6.16.17.tar What's with all these odd formats, and where is .zip? :) Somehow... have you tried lrzip? Furthermore, if the files in the .tar archive were actually sorted.. (Obviously we shall pick .7z) - 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: In response to kernel compression e-mail a few months ago.
On Oct 14 2007 15:53, Justin Piszcz wrote: What's with all these odd formats, and where is .zip? :) Somehow... have you tried lrzip? $ apt-cache search lrzip $ I tried most of the main ones in the standard testing distribution within Debian. Debian is not a solution to everything. http://ck.kolivas.org/apps/lrzip/ - 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: In response to kernel compression e-mail a few months ago.
On Oct 14 2007 16:58, Justin Piszcz wrote: compress: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 10544 war 20 0 700m 681m 1632 S 141 20.7 1:41.46 7z Just how you can utilize a CPU to 141% remains a mystery.. [ to be noted this is sqrt(2)*100 ] - 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: regression(?): starting with 2.6.21 sending packets became broken.
On Oct 13 2007 19:59, David wrote: >Try > >echo 0 > /proc/sys/net/ipv4/tcp_window_scaling > >I bet you have broken router(s) between your machine and the problem >site(s). There is an xt_TCPOPTSTRIP module in the works that allows you to strip Window Scaling only on the connections you want (rather than globally); seems to be in for 2.6.24 at earliest, though it's there is also the standalone patch. - 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] Allow kconfig to accept overrides
On Oct 13 2007 09:25, Randy Dunlap wrote:
> Jan Engelhardt wrote:
>> On Oct 13 2007 16:01, Stefan Richter wrote:
>> > > .config:176:warning: override: reassigning to symbol PREEMPT_VOLUNTARY
>> > > .config:176:warning: override: PREEMPT_VOLUNTARY turns state choice
>
> .config:176:warning: override: PREEMPT_VOLUNTARY modifies state choice
>
> "turns" is just odd there.
Yeah, I've put in
("override: %s changes choice state", sym->name);
this morning.
-
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] Allow kconfig to accept overrides
On Oct 13 2007 16:01, Stefan Richter wrote: >> >> .config:176:warning: override: reassigning to symbol PREEMPT_VOLUNTARY >> .config:176:warning: override: PREEMPT_VOLUNTARY turns state choice > >Try to make it a single warning. Patches welcome. Even without the patch, i.e. original kconfig behavior, spews two warnings. One for the symbol, and one for the choiec object. I do not see anything wrong with that; adding extra checks would perhaps only increase the code size. - 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: checkpatch: ERROR: Does not appear to be a unified-diff format patch
On Oct 13 2007 14:47, Adrian Bunk wrote: >On Sat, Oct 13, 2007 at 02:28:00PM +0200, Geert Uytterhoeven wrote: >> scripts/checkpatch.pl doesn't seem to like this patch: >> >> $ scripts/checkpatch.pl m68k-export-asm-cachectl-h.diff >> ERROR: Does not appear to be a unified-diff format patch >>... >> --- a/include/asm-m68k/Kbuild >> +++ b/include/asm-m68k/Kbuild >> @@ -1 +1,2 @@ >>... ^^ > >Broken patch, this has to be "-1,1". No, this is actually how diff outputs it. /([-+]\d+)\b/ seems to imply /$1,1/ - 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] Allow kconfig to accept overrides
On Oct 13 2007 10:16, Stefan Richter wrote:
warning("override: %s turns state choice", sym->name);
>>>
>>>What does that warning message mean? I can't decipher it.
>>
>> It is when the value of a "choice" kconfig object is changed, for example
>> this .config excerpt:
>>
>> CONFIG_PREEMPT_NONE=y
>> # CONFIG_PREEMPT_VOLUNTARY is not set
>> # CONFIG_PREEMPT is not set
>> # CONFIG_PREEMPT_BKL is not set
>> # CONFIG_PREEMPT_NONE is not set
>> CONFIG_REEMPT_VOLUNTARY=y
>
>Perhaps say
>
> warning("override: switching to choice %s", sym->name);
>
>if sym->name is [CONFIG_]PREEMPT_VOLUNTARY. Or what is it?
.config:176:warning: override: reassigning to symbol PREEMPT_VOLUNTARY
.config:176:warning: override: PREEMPT_VOLUNTARY turns state choice
Which seems correct, as PREEMPT_VOLUNTARY=y will overturn
the previous decision.
Perhaps it should be "%s overturns state choice" ?
-
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] Allow kconfig to accept overrides
On Oct 13 2007 10:16, Stefan Richter wrote: warning(override: %s turns state choice, sym-name); What does that warning message mean? I can't decipher it. It is when the value of a choice kconfig object is changed, for example this .config excerpt: CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set # CONFIG_PREEMPT_BKL is not set # CONFIG_PREEMPT_NONE is not set CONFIG_REEMPT_VOLUNTARY=y Perhaps say warning(override: switching to choice %s, sym-name); if sym-name is [CONFIG_]PREEMPT_VOLUNTARY. Or what is it? .config:176:warning: override: reassigning to symbol PREEMPT_VOLUNTARY .config:176:warning: override: PREEMPT_VOLUNTARY turns state choice Which seems correct, as PREEMPT_VOLUNTARY=y will overturn the previous decision. Perhaps it should be %s overturns state choice ? - 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: checkpatch: ERROR: Does not appear to be a unified-diff format patch
On Oct 13 2007 14:47, Adrian Bunk wrote: On Sat, Oct 13, 2007 at 02:28:00PM +0200, Geert Uytterhoeven wrote: scripts/checkpatch.pl doesn't seem to like this patch: $ scripts/checkpatch.pl m68k-export-asm-cachectl-h.diff ERROR: Does not appear to be a unified-diff format patch ... --- a/include/asm-m68k/Kbuild +++ b/include/asm-m68k/Kbuild @@ -1 +1,2 @@ ... ^^ Broken patch, this has to be -1,1. No, this is actually how diff outputs it. /([-+]\d+)\b/ seems to imply /$1,1/ - 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] Allow kconfig to accept overrides
On Oct 13 2007 16:01, Stefan Richter wrote: .config:176:warning: override: reassigning to symbol PREEMPT_VOLUNTARY .config:176:warning: override: PREEMPT_VOLUNTARY turns state choice Try to make it a single warning. Patches welcome. Even without the patch, i.e. original kconfig behavior, spews two warnings. One for the symbol, and one for the choiec object. I do not see anything wrong with that; adding extra checks would perhaps only increase the code size. - 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] Allow kconfig to accept overrides
On Oct 13 2007 09:25, Randy Dunlap wrote: Jan Engelhardt wrote: On Oct 13 2007 16:01, Stefan Richter wrote: .config:176:warning: override: reassigning to symbol PREEMPT_VOLUNTARY .config:176:warning: override: PREEMPT_VOLUNTARY turns state choice .config:176:warning: override: PREEMPT_VOLUNTARY modifies state choice turns is just odd there. Yeah, I've put in (override: %s changes choice state, sym-name); this morning. - 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: regression(?): starting with 2.6.21 sending packets became broken.
On Oct 13 2007 19:59, David wrote: Try echo 0 /proc/sys/net/ipv4/tcp_window_scaling I bet you have broken router(s) between your machine and the problem site(s). There is an xt_TCPOPTSTRIP module in the works that allows you to strip Window Scaling only on the connections you want (rather than globally); seems to be in for 2.6.24 at earliest, though it's there is also the standalone patch. - 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] Allow kconfig to accept overrides
On Oct 12 2007 15:57, Randy Dunlap wrote:
>On Fri, 12 Oct 2007 23:44:08 +0200 (CEST) Jan Engelhardt wrote:
>
>> warning("override: %s turns state choice", sym->name);
>
>What does that warning message mean? I can't decipher it.
It is when the value of a "choice" kconfig object is changed, for example
this .config excerpt:
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
# CONFIG_PREEMPT_BKL is not set
# CONFIG_PREEMPT_NONE is not set
CONFIG_REEMPT_VOLUNTARY=y
>Other than that, it works for me. Thanks.
/What/ works, the patch, or the tree without the patch? (Note I was
testing that on 2.6.23.1, not the git head, so if someone silently
merged things behind me, I might have missed it. Then again, that
would have probably caused an offset, fuzz or reject, which was not
the case.)
-
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] Allow kconfig to accept overrides
On Oct 12 2007 14:49, Randy Dunlap wrote: > Jan Engelhardt wrote: >> Allow config variables in .config to override earlier ones in the same >> file. In other words, >> >> # CONFIG_SECURITY is not defined >> CONFIG_SECURITY=y >> >> will activate it. This makes it a bit easier to do >> >> (cat original-config myconfig myconfig2 ... >.config) >> >> and run menuconfig as expected. > > This is a feature that we want IMO, but I already do this without having > a patch for it (although to a lesser degree than full config files; > I just cat a few entries to the end of a config file then run oldconfig)... > so are there some cases where it works and some cases > where it doesn't work? Do you know what those cases are? $ echo "CONFIG_CRC7=m" >>../obj-2.6.23/.config $ make O=/ws/linux/obj-2.6.23 menuconfig GEN /ws/linux/obj-2.6.23/Makefile scripts/kconfig/mconf arch/i386/Kconfig .config:3669:warning: trying to reassign symbol CRC7 (Just save+exit) $ grep CONFIG_CRC7 ../obj-2.6.23/.config # CONFIG_CRC7 is not set - 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] Allow kconfig to accept overrides
Allow config variables in .config to override earlier ones in the same
file. In other words,
# CONFIG_SECURITY is not defined
CONFIG_SECURITY=y
will activate it. This makes it a bit easier to do
(cat original-config myconfig myconfig2 ... >.config)
and run menuconfig as expected.
Previously sent:
http://lkml.org/lkml/2006/10/25/81
http://lkml.org/lkml/2007/4/1/175
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
Cc: Sam Ravnborg <[EMAIL PROTECTED]>
Cc: Roman Zippel <[EMAIL PROTECTED]>
Cc: Randy Dunlap <[EMAIL PROTECTED]>
---
scripts/kconfig/confdata.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
#
# Applies cleanly to 2.6.22/23/git.
#
Index: linux-2.6.22.1/scripts/kconfig/confdata.c
===
--- linux-2.6.22.1.orig/scripts/kconfig/confdata.c
+++ linux-2.6.22.1/scripts/kconfig/confdata.c
@@ -170,8 +170,7 @@ load:
sym->type = S_BOOLEAN;
}
if (sym->flags & def_flags) {
- conf_warning("trying to reassign symbol %s",
sym->name);
- break;
+ conf_warning("override: reassigning to symbol
%s", sym->name);
}
switch (sym->type) {
case S_BOOLEAN:
@@ -210,8 +209,7 @@ load:
sym->type = S_OTHER;
}
if (sym->flags & def_flags) {
- conf_warning("trying to reassign symbol %s",
sym->name);
- break;
+ conf_warning("override: reassigning to symbol
%s", sym->name);
}
switch (sym->type) {
case S_TRISTATE:
@@ -288,11 +286,9 @@ load:
}
break;
case yes:
- if (cs->def[def].tri != no) {
- conf_warning("%s creates inconsistent
choice state", sym->name);
- cs->flags &= ~def_flags;
- } else
- cs->def[def].val = sym;
+ if(cs->def[def].tri != no)
+ conf_warning("override: %s turns state
choice", sym->name);
+ cs->def[def].val = sym;
break;
}
cs->def[def].tri = E_OR(cs->def[def].tri,
sym->def[def].tri);
-
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: Off-Topic: Patent infringement cases filed in U.S.
On Oct 12 2007 18:25, Renato S. Yamane wrote: > > "IP Innovation LLC has just filed a patent infringement claim against Red Hat > and Novell. It was filed October 9, case no. 2:2007cv00447, IP Innovation, LLC > et al v. Red Hat Inc. et al, in Texas": I think the number of news sites like lwn,osnews,slashdot,etc is already high enough that no developer would miss out on that. That is, those who even care for such. - 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: oops on rmmod asus_acpi
Hi, I am wondering about asus_acpi-fix-oops-on-non-asus-machines.patch , which is still neither in mainline git nor in Len's acpi git tree ( http://lkml.org/lkml/2007/6/30/29 ). Any plans? thanks, Jan - 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: [RFD] iptables: mangle table obsoletes filter table
On Oct 12 2007 15:48, Patrick McHardy wrote: > >The netlink based iptables successor I'm currently working on allows to >dynamically create tables with user-specified priorities and "built-in" >chains. The only built-in tables will be those that need extra >processing (mangle/nat). So it should be possible to set up tables >basically any way you desire. Will ebtables move a bit closer to iptables? - 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: [RFD] iptables: mangle table obsoletes filter table
On Oct 12 2007 16:30, Al Boldi wrote: >Jan Engelhardt wrote: >> On Oct 12 2007 00:31, Al Boldi wrote: >> >With the existence of the mangle table, how useful is the filter table? >> >> A similar discussion was back in March 2007. >> http://marc.info/?l=netfilter-devel=117394977210823=2 >> http://marc.info/?l=netfilter-devel=117400063907706=2 >> >> in the end, my proposal was something like >> http://jengelh.hopto.org/GFX0/nf_proposal2.svg > >Any chance you could publish this as something readable like text/html? Like, image/png? http://jengelh.hopto.org/GFX0/nf_proposal2.png - 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: [RFD] iptables: mangle table obsoletes filter table
On Oct 12 2007 00:31, Al Boldi wrote: > >With the existence of the mangle table, how useful is the filter table? A similar discussion was back in March 2007. http://marc.info/?l=netfilter-devel=117394977210823=2 http://marc.info/?l=netfilter-devel=117400063907706=2 in the end, my proposal was something like http://jengelh.hopto.org/GFX0/nf_proposal2.svg - 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: [RFD] iptables: mangle table obsoletes filter table
On Oct 12 2007 16:30, Al Boldi wrote: Jan Engelhardt wrote: On Oct 12 2007 00:31, Al Boldi wrote: With the existence of the mangle table, how useful is the filter table? A similar discussion was back in March 2007. http://marc.info/?l=netfilter-develm=117394977210823w=2 http://marc.info/?l=netfilter-develm=117400063907706w=2 in the end, my proposal was something like http://jengelh.hopto.org/GFX0/nf_proposal2.svg Any chance you could publish this as something readable like text/html? Like, image/png? http://jengelh.hopto.org/GFX0/nf_proposal2.png - 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: [RFD] iptables: mangle table obsoletes filter table
On Oct 12 2007 00:31, Al Boldi wrote: With the existence of the mangle table, how useful is the filter table? A similar discussion was back in March 2007. http://marc.info/?l=netfilter-develm=117394977210823w=2 http://marc.info/?l=netfilter-develm=117400063907706w=2 in the end, my proposal was something like http://jengelh.hopto.org/GFX0/nf_proposal2.svg - 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: [RFD] iptables: mangle table obsoletes filter table
On Oct 12 2007 15:48, Patrick McHardy wrote: The netlink based iptables successor I'm currently working on allows to dynamically create tables with user-specified priorities and built-in chains. The only built-in tables will be those that need extra processing (mangle/nat). So it should be possible to set up tables basically any way you desire. Will ebtables move a bit closer to iptables? - 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: oops on rmmod asus_acpi
Hi, I am wondering about asus_acpi-fix-oops-on-non-asus-machines.patch , which is still neither in mainline git nor in Len's acpi git tree ( http://lkml.org/lkml/2007/6/30/29 ). Any plans? thanks, Jan - 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] Allow kconfig to accept overrides
Allow config variables in .config to override earlier ones in the same
file. In other words,
# CONFIG_SECURITY is not defined
CONFIG_SECURITY=y
will activate it. This makes it a bit easier to do
(cat original-config myconfig myconfig2 ... .config)
and run menuconfig as expected.
Previously sent:
http://lkml.org/lkml/2006/10/25/81
http://lkml.org/lkml/2007/4/1/175
Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]
Cc: Sam Ravnborg [EMAIL PROTECTED]
Cc: Roman Zippel [EMAIL PROTECTED]
Cc: Randy Dunlap [EMAIL PROTECTED]
---
scripts/kconfig/confdata.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
#
# Applies cleanly to 2.6.22/23/git.
#
Index: linux-2.6.22.1/scripts/kconfig/confdata.c
===
--- linux-2.6.22.1.orig/scripts/kconfig/confdata.c
+++ linux-2.6.22.1/scripts/kconfig/confdata.c
@@ -170,8 +170,7 @@ load:
sym-type = S_BOOLEAN;
}
if (sym-flags def_flags) {
- conf_warning(trying to reassign symbol %s,
sym-name);
- break;
+ conf_warning(override: reassigning to symbol
%s, sym-name);
}
switch (sym-type) {
case S_BOOLEAN:
@@ -210,8 +209,7 @@ load:
sym-type = S_OTHER;
}
if (sym-flags def_flags) {
- conf_warning(trying to reassign symbol %s,
sym-name);
- break;
+ conf_warning(override: reassigning to symbol
%s, sym-name);
}
switch (sym-type) {
case S_TRISTATE:
@@ -288,11 +286,9 @@ load:
}
break;
case yes:
- if (cs-def[def].tri != no) {
- conf_warning(%s creates inconsistent
choice state, sym-name);
- cs-flags = ~def_flags;
- } else
- cs-def[def].val = sym;
+ if(cs-def[def].tri != no)
+ conf_warning(override: %s turns state
choice, sym-name);
+ cs-def[def].val = sym;
break;
}
cs-def[def].tri = E_OR(cs-def[def].tri,
sym-def[def].tri);
-
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: Off-Topic: Patent infringement cases filed in U.S.
On Oct 12 2007 18:25, Renato S. Yamane wrote: IP Innovation LLC has just filed a patent infringement claim against Red Hat and Novell. It was filed October 9, case no. 2:2007cv00447, IP Innovation, LLC et al v. Red Hat Inc. et al, in Texas: I think the number of news sites like lwn,osnews,slashdot,etc is already high enough that no developer would miss out on that. That is, those who even care for such. - 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] Allow kconfig to accept overrides
On Oct 12 2007 14:49, Randy Dunlap wrote: Jan Engelhardt wrote: Allow config variables in .config to override earlier ones in the same file. In other words, # CONFIG_SECURITY is not defined CONFIG_SECURITY=y will activate it. This makes it a bit easier to do (cat original-config myconfig myconfig2 ... .config) and run menuconfig as expected. This is a feature that we want IMO, but I already do this without having a patch for it (although to a lesser degree than full config files; I just cat a few entries to the end of a config file then run oldconfig)... so are there some cases where it works and some cases where it doesn't work? Do you know what those cases are? $ echo CONFIG_CRC7=m ../obj-2.6.23/.config $ make O=/ws/linux/obj-2.6.23 menuconfig GEN /ws/linux/obj-2.6.23/Makefile scripts/kconfig/mconf arch/i386/Kconfig .config:3669:warning: trying to reassign symbol CRC7 (Just save+exit) $ grep CONFIG_CRC7 ../obj-2.6.23/.config # CONFIG_CRC7 is not set - 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] Allow kconfig to accept overrides
On Oct 12 2007 15:57, Randy Dunlap wrote: On Fri, 12 Oct 2007 23:44:08 +0200 (CEST) Jan Engelhardt wrote: warning(override: %s turns state choice, sym-name); What does that warning message mean? I can't decipher it. It is when the value of a choice kconfig object is changed, for example this .config excerpt: CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set # CONFIG_PREEMPT_BKL is not set # CONFIG_PREEMPT_NONE is not set CONFIG_REEMPT_VOLUNTARY=y Other than that, it works for me. Thanks. /What/ works, the patch, or the tree without the patch? (Note I was testing that on 2.6.23.1, not the git head, so if someone silently merged things behind me, I might have missed it. Then again, that would have probably caused an offset, fuzz or reject, which was not the case.) - 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: TPM driver changes to support multiple locality
On Oct 11 2007 11:54, Randy Dunlap wrote: >On Thu, 11 Oct 2007 11:33:35 -0700 Agarwal, Lomesh wrote: > >> Below is the patch for TPM driver. >> Comments/suggestions? > >Observe/use kernel coding style. >Run the patch thru scripts/checkpatch.pl and check its suggestions. >Use "diffstat -p1 -w70" and put that summary near the top of the >patch (after the patch description). Or, if using quilt on top of the tree, a simple `quilt diff --diffstat --sort` will do all the nice diffing, including stat and use diff -pu. It also preserves diffstat (if not regenerating that) and patch description, so is suited *perfectly* for the task when you don't want to use stgit. - 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: Getting problem while building kernel module
On Oct 11 2007 15:53, mahamuni ashish wrote: >-- >[EMAIL PROTECTED] device_driver]# make > >gcc -O2 -DMODULE -D__KERNEL__ -isystem >/usr/src/kernels/2.6.18-1.2798.fc6-i686/include -c >-o ins.o ins.c Time to read Documentation/kbuild/. - 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: Help with rtc to hpet conversion of OSGPS driver
On Oct 11 2007 08:51, Rick Niles wrote: > > Maybe I'm way off here, but that seems to be the function to register a RTC > hardware chip with the kernel. I want to use a real-time clock interrupt to > wake up my driver and service the GPS correlator, about every 500ms. Please > let me know if I'm misunderstanding. You register your hardware, and then the userspace program opens /dev/rtc17 or whatever node is assigned to it, and receives periodic interrupts. At least that's the theory for rtc-cmos. And don't top post. - 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: Help with rtc to hpet conversion of OSGPS driver
On Oct 11 2007 08:01, Rick Niles wrote: > > I've been trying to make the driver work with > Fedora 7 and the 2.6.22 kernel, but the rtc_register() and other RTC functions > seems to have been removed. grep -r rtc_device_register drivers/rtc/ Does that help? > I see they've been replaced by the corresponding > HPET functions, which is great. However, hpet_register() always returns -16 > (EBUSY). This could be because I lack the correct hardware (I'm running > 32-bit > Linux on a Athlon64 with an NVIDIA chipset) or some other reason. - 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: Help with rtc to hpet conversion of OSGPS driver
On Oct 11 2007 08:01, Rick Niles wrote: I've been trying to make the driver work with Fedora 7 and the 2.6.22 kernel, but the rtc_register() and other RTC functions seems to have been removed. grep -r rtc_device_register drivers/rtc/ Does that help? I see they've been replaced by the corresponding HPET functions, which is great. However, hpet_register() always returns -16 (EBUSY). This could be because I lack the correct hardware (I'm running 32-bit Linux on a Athlon64 with an NVIDIA chipset) or some other reason. - 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: Help with rtc to hpet conversion of OSGPS driver
On Oct 11 2007 08:51, Rick Niles wrote: Maybe I'm way off here, but that seems to be the function to register a RTC hardware chip with the kernel. I want to use a real-time clock interrupt to wake up my driver and service the GPS correlator, about every 500ms. Please let me know if I'm misunderstanding. You register your hardware, and then the userspace program opens /dev/rtc17 or whatever node is assigned to it, and receives periodic interrupts. At least that's the theory for rtc-cmos. And don't top post. - 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: Getting problem while building kernel module
On Oct 11 2007 15:53, mahamuni ashish wrote: -- [EMAIL PROTECTED] device_driver]# make gcc -O2 -DMODULE -D__KERNEL__ -isystem /usr/src/kernels/2.6.18-1.2798.fc6-i686/include -c -o ins.o ins.c Time to read Documentation/kbuild/. - 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: TPM driver changes to support multiple locality
On Oct 11 2007 11:54, Randy Dunlap wrote: On Thu, 11 Oct 2007 11:33:35 -0700 Agarwal, Lomesh wrote: Below is the patch for TPM driver. Comments/suggestions? Observe/use kernel coding style. Run the patch thru scripts/checkpatch.pl and check its suggestions. Use diffstat -p1 -w70 and put that summary near the top of the patch (after the patch description). Or, if using quilt on top of the tree, a simple `quilt diff --diffstat --sort` will do all the nice diffing, including stat and use diff -pu. It also preserves diffstat (if not regenerating that) and patch description, so is suited *perfectly* for the task when you don't want to use stgit. - 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] Argument with an OS professor over profile=3
On Oct 11 2007 00:13, Russ Dill wrote: > >/* only text is profiled */ >> prof_len = (unsigned *) &_etext - (unsigned *) &_stext; Uh, that's some evil pointer arithmetic :) - 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: Linux 2.6.23
On Oct 10 2007 14:36, Alexey Dobriyan wrote: >> >> --- linux-2.6.23/include/linux/mm.h.vanilla >> >> +++ linux-2.6.23/include/linux/mm.h >> > >> >> +struct super_block; >> >> extern void drop_pagecache_sb(struct super_block *); >> >> void drop_pagecache(void); >> >> void drop_slab(void); >> >> >> >> You probably end up fixing it some other way, but as I do not know this >> >> file inside out I just wanted to drop a note. >> > >> > You have some strange vanilla kernel. 2.6.23 doesn't have this prototype. >> >> The same happens here as well. >> >> -rw-rw-r-- 1 mjt mjt 45488158 Oct 9 20:48 linux-2.6.23.tar.bz2 >> 2cc2fd4d521dc5d7cfce0d8a9d1b3472 linux-2.6.23.tar.bz2 >> >> (timestamp is in UTC) Downloaded yesterday, 3 hours after an announce, >> from http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.23.tar.bz2 . > >Strange. Same size, same md5, no super_block in mm.h, though Does someone still have the broken tarball? There has not been any drop_pagecache_sb anytime between 2.6.23-rc1 and 2.6.23. drop_pagecache_sb reminds me of reiser4, too. - 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] Documentation: Fix typo in SubmitChecklist.
On Oct 8 2007 14:55, James Bowes wrote: > 20: Check that it all passes `make headers_check'. > > 21: Has been checked with injection of at least slab and page-allocation >-fauilures. See Documentation/fault-injection/. >+failures. See Documentation/fault-injection/. It was a fault injection, after all. :) - 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] Documentation: Fix typo in SubmitChecklist.
On Oct 8 2007 14:55, James Bowes wrote: 20: Check that it all passes `make headers_check'. 21: Has been checked with injection of at least slab and page-allocation -fauilures. See Documentation/fault-injection/. +failures. See Documentation/fault-injection/. It was a fault injection, after all. :) - 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: Linux 2.6.23
On Oct 10 2007 14:36, Alexey Dobriyan wrote: --- linux-2.6.23/include/linux/mm.h.vanilla +++ linux-2.6.23/include/linux/mm.h +struct super_block; extern void drop_pagecache_sb(struct super_block *); void drop_pagecache(void); void drop_slab(void); You probably end up fixing it some other way, but as I do not know this file inside out I just wanted to drop a note. You have some strange vanilla kernel. 2.6.23 doesn't have this prototype. The same happens here as well. -rw-rw-r-- 1 mjt mjt 45488158 Oct 9 20:48 linux-2.6.23.tar.bz2 2cc2fd4d521dc5d7cfce0d8a9d1b3472 linux-2.6.23.tar.bz2 (timestamp is in UTC) Downloaded yesterday, 3 hours after an announce, from http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.23.tar.bz2 . Strange. Same size, same md5, no super_block in mm.h, though Does someone still have the broken tarball? There has not been any drop_pagecache_sb anytime between 2.6.23-rc1 and 2.6.23. drop_pagecache_sb reminds me of reiser4, too. - 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] Argument with an OS professor over profile=3
On Oct 11 2007 00:13, Russ Dill wrote: /* only text is profiled */ prof_len = (unsigned *) _etext - (unsigned *) _stext; Uh, that's some evil pointer arithmetic :) - 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: irq0 stops working
On Oct 9 2007 09:26, Vasily Averin wrote: > >On one of our servers timer interrupts (i.e irq0) are stops working. As result >any kernel timers do not triggers and tasks waiting some signals from timers >hangs forever. What kernel.. and tried CONFIG_NO_HZ=n? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Colored kernel output (run3)
On Oct 9 2007 07:12, Antonino A. Daplas wrote:
>>
>> References: http://lkml.org/lkml/2007/4/1/162
>> http://lkml.org/lkml/2007/10/5/199
>
>This is quite a long thread :-)
It was a patch series after all. But as Greg puts it, be persistent.
>> +config VT_PRINTK_COLOR
>> +hex "Colored kernel message output"
>> +range 0x00 0xFF
>> +depends on VT_CKO
>> +default 0x07
>> +---help---
>> +This option defines with which color kernel messages will be
>> +printed to the console.
>> +
>> +The value you need to enter here is the value is composed
>
>The more correct term for "The value" is probably "The attribute".
"The value for this kconfig entry" it should read in the minds.
>> +(Foreground colors 0x08 to 0x0F do not work when a VGA
>> +console font with 512 glyphs is used.)
>
>You might have to include a warning that those values or attributes are
>interpreted differently depending on the driver used, and the above is
>mostly true for 16-color console drivers only.
Are there any other drivers besides vgacon and fbcon that use vt.c?
>For 2-colors [...] With a 4-color fb console (4-level grayscale) [...]
>With an 8-color console, only the first 8 values are considered.
>With a 16-color console, that is also not consistent:[...]
I see. That probably means the explanation of values moves from Kconfig
to Documentation/. Somehow I think we could do without doc and let
interested starts find out for themselves and learn a little about
vgacon/fbcon. ;)
>With vgacon, it supports 16-color foreground (fg), 8-color
>background (bg) at 256 chars. Becomes 8 fg and 8 bg with 512 chars.
>
>With fbcon, it supports 16 fg and 16 bg at 256, 16 fg and 8 bg at
>512 chars.
And then there is fbiterm, which supports at least 16 fg/16 bg with ...
the whole Unicode set of chars. :)
>And for drivers that have their own con_build_attr() hook, they will be
>interpreted differently again.
>> +Background:
>> +0x00 = black, 0x40 = blue,
>> +0x10 = red, 0x50 = magenta,
>> +0x20 = green, 0x60 = cyan,
>> +0x30 = brown, 0x70 = gray,
>> +
>> +For example, 0x1F would yield white on red.
>
>You may need to specify that the values here are the console default,
>ie, the default_blue|grn|red boot options are not filled up.
>> +static inline void vc_set_color(struct vc_data *vc, unsigned char color)
>> +{
>> +vc->vc_color = color_table[color & 0xF] |
>> + (color_table[(color >> 4) & 0x7] << 4) |
>> + (color & 0x80);
>
>You may want to leave out the blink attribute (0x80) from this part.
>Otherwise setterm -blink on|off will produce the opposite effect.
But 0x80 might be interpreted in a different fashion for some othercon,
yielding for example superbold rather than blinking.
I'll have to try this, because usually, setterm operates on TTYs
rather than VCs.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: reviewer's statement of oversight
On Oct 8 2007 19:37, Sam Ravnborg wrote: >snip... > >Or maybe we need something much less formal that explain the purpose of the >four tags we use: At least formal try: >Signed-of-by: * Used by original submitter(s). * Also used by maintainers to track the patch's path (ATM, does not imply "I have look at it in depth") >Acked-by: >Tested-by: * Used by random people to express their (dis)like/experience with the patch. >Reviewed-by: * I am maintaner or an 'important' person and have had a look at it in depth >Cc: * Used by original submitter to denote additional maintainers it goes to * Parties who should be Cced when an a posteriori question comes up My 2¥. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: reviewer's statement of oversight
On Oct 8 2007 19:37, Sam Ravnborg wrote: snip... Or maybe we need something much less formal that explain the purpose of the four tags we use: At least formal try: Signed-of-by: * Used by original submitter(s). * Also used by maintainers to track the patch's path (ATM, does not imply I have look at it in depth) Acked-by: Tested-by: * Used by random people to express their (dis)like/experience with the patch. Reviewed-by: * I am maintaner or an 'important' person and have had a look at it in depth Cc: * Used by original submitter to denote additional maintainers it goes to * Parties who should be Cced when an a posteriori question comes up My 2¥. Jan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Colored kernel output (run3)
On Oct 9 2007 07:12, Antonino A. Daplas wrote:
References: http://lkml.org/lkml/2007/4/1/162
http://lkml.org/lkml/2007/10/5/199
This is quite a long thread :-)
It was a patch series after all. But as Greg puts it, be persistent.
+config VT_PRINTK_COLOR
+hex Colored kernel message output
+range 0x00 0xFF
+depends on VT_CKO
+default 0x07
+---help---
+This option defines with which color kernel messages will be
+printed to the console.
+
+The value you need to enter here is the value is composed
The more correct term for The value is probably The attribute.
The value for this kconfig entry it should read in the minds.
+(Foreground colors 0x08 to 0x0F do not work when a VGA
+console font with 512 glyphs is used.)
You might have to include a warning that those values or attributes are
interpreted differently depending on the driver used, and the above is
mostly true for 16-color console drivers only.
Are there any other drivers besides vgacon and fbcon that use vt.c?
For 2-colors [...] With a 4-color fb console (4-level grayscale) [...]
With an 8-color console, only the first 8 values are considered.
With a 16-color console, that is also not consistent:[...]
I see. That probably means the explanation of values moves from Kconfig
to Documentation/. Somehow I think we could do without doc and let
interested starts find out for themselves and learn a little about
vgacon/fbcon. ;)
With vgacon, it supports 16-color foreground (fg), 8-color
background (bg) at 256 chars. Becomes 8 fg and 8 bg with 512 chars.
With fbcon, it supports 16 fg and 16 bg at 256, 16 fg and 8 bg at
512 chars.
And then there is fbiterm, which supports at least 16 fg/16 bg with ...
the whole Unicode set of chars. :)
And for drivers that have their own con_build_attr() hook, they will be
interpreted differently again.
+Background:
+0x00 = black, 0x40 = blue,
+0x10 = red, 0x50 = magenta,
+0x20 = green, 0x60 = cyan,
+0x30 = brown, 0x70 = gray,
+
+For example, 0x1F would yield white on red.
You may need to specify that the values here are the console default,
ie, the default_blue|grn|red boot options are not filled up.
+static inline void vc_set_color(struct vc_data *vc, unsigned char color)
+{
+vc-vc_color = color_table[color 0xF] |
+ (color_table[(color 4) 0x7] 4) |
+ (color 0x80);
You may want to leave out the blink attribute (0x80) from this part.
Otherwise setterm -blink on|off will produce the opposite effect.
But 0x80 might be interpreted in a different fashion for some othercon,
yielding for example superbold rather than blinking.
I'll have to try this, because usually, setterm operates on TTYs
rather than VCs.
-
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: irq0 stops working
On Oct 9 2007 09:26, Vasily Averin wrote: On one of our servers timer interrupts (i.e irq0) are stops working. As result any kernel timers do not triggers and tasks waiting some signals from timers hangs forever. What kernel.. and tried CONFIG_NO_HZ=n? - 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: NAK nettiquete (was Re: "Re: [PATCH 0/2] Colored kernel output (run2)"
On Oct 7 2007 17:23, Alan Cox wrote: > >>>- If you want to do "pretty" boot up you do it in X or frame buffer >>>(which is going to get easier and easier with the X shift to kernel side >>>video support) >> >> fb is slow. Feels like a 9600bps serial line. > >So fix your fb. There is enough information to cover 2D scrolling for >most modern cards now. > >> Let everyone have his own fun. > >The point isn't to put everyones "fun" into the kernel, or by now it >would have become a steaming heap. We do have a steaming heap of obscure hardware drivers, actually. - 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: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On Oct 8 2007 01:02, Oleg Verych wrote: > >If you are not going to see OOPes of new kernels running old distros, ask >any perl hacker (as they lovely mentioned in lkml) to hack for you >something like: > >sed -u -e ' >/^<1/s_^_'$COLOR1'_ >/^<2/s_^_'$COLOR2'_ >/^<3/s_^_'$COLOR3'_ >/^<4/s_^_'$COLOR4'_ >/^<5/s_^_'$COLOR5'_ >/^<6/s_^_'$COLOR6'_ >/^<7/s_^_'$COLOR7'_ >' < /proc/kmsg >/dev/tty > >place whole that perl shit on initrams of your kernel, run it in >background as early as possible with switched off default console output >(i.e. quiet boot). > >OVER. Speaking of over, this does not fly at all. If you call panic(), for whatever reason you want, then the printk() is the last thing that happens after that, you can declare userspace dead. On oopses, it depends on their severity. Eventually procfs goes whoops and the kmsg transmission mechanism does not work, and oh, userspace can't help it. - 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: syntax highlighting, emacs ([PATCH 0/2] Colored kernel output (run2))
On Oct 8 2007 00:18, Oleg Verych wrote: > >Kind of funny thing with it. One for shell in `mcedit` is much nicer, but >`emacs` is more powerful as editor(R). But both have highlighting >problems with non trivial scripts (quoiting, data here, etc). I don't >know if it will ever be fixed :). No, it will never get fixed. I use two editors on a day-to-day basis, and that is mcedit and joe. No fixed rule on which to use. It goes as far that I have the same syntax highlighting (almost) on both. Because one thing in one editor is cumbersome in the other. Perhaps if there was one editor with the hotkeys of *both* (yes, means duplicates), maybe then I'd be satisfied. >Emacs have black background by default. I changed foreground to green, >and it is much nicer for long runs. Blue (or any bright) background >isn't comfortable, i think. Actually, blue is perceived as one of the darkest colors by the human eye. There is a reason that the RGB -> grayscale transformation uses the following weighting: r=76 g=154 b=26. - 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: tty UI (Re: [PATCH 0/2] Colored kernel output (run2))
On Oct 7 2007 22:50, Oleg Verych wrote: > >In fact mc config (ini) section is a better way. Yes, for the default colors. But /usr/share/mc/syntax/ specifies more of them. >I use default blue (which is very annoying) If blue were annoying, it would not be the default Windows background (since Windows 2000). Then again, it's personal preference, so I suppose you have a red/green desktop wallpaper for X11? >The most exiting event recently was, that `lynx` in debian got updated, so >it displays much more colors for HTML formatting now. I'm happy. lynx. Update. Ha. Get w3m. Seriously. :) - 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: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On Oct 7 2007 21:27, Rene Herman wrote: > > I saw you remark on FB console in a reply to Alan just now and I > quite agree with you. The (current) FB console is slow and I'll add > "dumb" myself. When you have a 1280x1024 screen available, you get > to do cool things like put up nice little windows and exclamation > mark icons on errors, not just pretend you're really 132x50 (or > whatever). CVIDIX, while card-dependent I think, is much better at speed than FB while still providing 720x400 or even higher. - 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: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On Oct 7 2007 22:00, Rene Herman wrote: > On 10/07/2007 09:56 PM, Jan Engelhardt wrote: > >> Some is good, as long as it is not excessive. While I could imagine that >> Knoppix will abuse the feature and use vt.printk_color=9,9,9,9,11,10,12, this >> is not what serious people would do. >> >> [1] http://tinyurl.com/yr9zgq >> [2] http://tinyurl.com/234ba3 > > Given this discussion, I find it really appropriate that you are posting > _graphics_ of your text screens :-) I can give you a VCSA file (as produced by /dev/vcsa1) if you like, complete with VCSA reader. - 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: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On Oct 7 2007 21:13, Willy Tarreau wrote: >There are two distinct populations : > - those [...] >who would never have imagined that pressing Escape >during the boot of windows 3.1/95 provided them with the full text >messages. This is news to me. DOS always showed messages, and under Win95, it was either F8 or removing logo.sys. I did troubleshoot it ;-) > - those who are troubleshooting their system [...] > >I personally fit in the second category. > >I would say that while I'm not particularly fond of flashy colors >everywhere I have to agree so really. Just because there's a color option for everything does not mean one should use it. In fact, I moved away[2] from the default Midnight Commander styling because it's just - as Dave calls it - salad colors[1]. Some is good, as long as it is not excessive. While I could imagine that Knoppix will abuse the feature and use vt.printk_color=9,9,9,9,11,10,12, this is not what serious people would do. [1] http://tinyurl.com/yr9zgq [2] http://tinyurl.com/234ba3 >, I think that being able to use colors to indicate particular >actions in progress or conditions can be a good thing. RAID errors, >devices disabled due to command-line parameters, - 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: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On Oct 7 2007 20:47, Rene Herman wrote: > >> > Coloring isn't useful. If it was, it would be implemented ~16 years >> > ago. >> >> Congratulations, this is the most stupid argument i've ever read on lkml. > > "Ay. World is finished. Everyone can go home and watch Friends reruns now." > > But well, there actually have been worse arguments given that VGA console is > getting less and less important. >[...] > Sure, that in itself needn't necesarily be of concern to anyone who, err, is > not concerned but any such colouring feature appearing when there's only a > smathering of people left that still cares about the VGA console in the first > place really isn't all _that_ far out as an argument... In case you have not noticed, the coloring also applies to FB. As far as I can oversee, it's only "missing" for serial and PROMs. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Colored kernel output (run3)
On Oct 7 2007 18:59, Ingo Molnar wrote: >> > vmlinux: >> > textdata bss dec hex filename >> > 7732358 1157269 401408 9291035 8dc51b vmlinux.before >> > 7732374 1157269 401408 9291051 8dc52b vmlinux.after >> > >> >16 bytes, or 0.0002% of the total text size. So there's in essence no >> >text overhead to talk about. So the text overhead argument is a red >> >herring. >> >> 16 bytes, huh? Can't be. That would be like, perhaps 5, x86 instructions. > >yes, it's that low, and it's with the feature disabled. Ah, with CONFIG_CKO=n, right. But where does that 16 byte increase come from, when vt.o itself remains constant in size? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Colored kernel output (run3)
On Oct 7 2007 18:44, Ingo Molnar wrote: >> This patch makes it possible to give kernel messages a selectable >> color. It can be chosen at compile time, overridden at boot time, and >> changed at run time. > >here's some (good) text footprint data: > >with the feature disabled (which is the default), the text size >difference with patch #1: > > vmlinux: > textdata bss dec hex filename > 7732358 1157269 401408 9291035 8dc51b vmlinux.before > 7732358 1157269 401408 9291035 8dc51b vmlinux.after > I already posted the numbers. But it seems like the archives like lkml.org or marc.info did not archive them (but i've cc'ed plenty so you did not miss it.). See below. >i.e. no overhead. Text size difference with patch #2: > > vmlinux: > textdata bss dec hex filename > 7732358 1157269 401408 9291035 8dc51b vmlinux.before > 7732374 1157269 401408 9291051 8dc52b vmlinux.after > >16 bytes, or 0.0002% of the total text size. So there's in essence no >text overhead to talk about. So the text overhead argument is a red >herring. 16 bytes, huh? Can't be. That would be like, perhaps 5, x86 instructions. ||Date: Sat, 6 Oct 2007 22:09:13 +0200 (CEST) ||Subject: [PATCH 0/2] Colored kernel output (run3) || ||ok, so to make Oleg happy, here is run3 with a bool config option. || ||i386>> || 48679 vt.o w/o anything || 48679 vt.o w/patch1 || 49117 vt.o w/patch1+ CONFIG_VT_CKO=y || 49198 vt.o w/patch1+patch2 + CONFIG_VT_CKO=y || || 519 total cost of CKO || ||x86_64>> || 71892 vt.o w/patch1+patch2 || 72787 vt.o w/patch1+patch2 + CONFIG_VT_CKO=y || || 895 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Colored kernel output (run3)
On Oct 7 2007 18:38, Ingo Molnar wrote: > >minor fix: i had to use the slightly modified patch below instead of the >one you posted, so that the second patch applies fine. What is it that you changed? The printk patches are right at the front, so there should not be any fuzz or offsets (might vary when not at Linus's git top). 18:42 ichi:/ws/linux/linux-2.6.23 > head -n6 patches/series checkpatch1.diff checkpatch2.diff checkfiles.diff xt_TCPOPTSTRIP.diff vt-printk-color.diff vt-printk-color-per-loglevel.diff >Color output is >just fine with this plus your #2 one applied. Adding >vt.printk_color=0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08 to the boot line >worked as expected. Use decimal if feasible. (vt.printk_color=1,2,3,4,5,6,7,8) The maximum command line still seems to be 255 on i386, as I noticed while trying to replace the VGA color table :-( - 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: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On Oct 7 2007 13:10, Oleg Verych wrote: >This `scrollback' is usual late boot / console one. If fact useful, >until first tty switch or if `screen` cannot be used. But for some >reason if scrolling region (DECSTBM) is less than whole screen, nothing >works. Actually, scrolling begins to work once userspace starts, and the scrollback buffer (given enough size) still contains the first screenful when Linux started, which may include the bootloader (if the loader did not zero the screen before handing control over). - 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: NAK nettiquete (was Re: "Re: [PATCH 0/2] Colored kernel output (run2)"
On Oct 7 2007 16:12, Alan Cox wrote: > >- We run on a lot more than VGA PC consoles >- We have serial consoles (which may or may not be VT132/ANSI compliant) Yes, and the serial driver does not usually pass on vc->vc_color to the real hardware. If it did, it would have to transform it back into an unportable ANSI code and send that. So we don't do that. >- The printk paths are run at IRQ time ASAP to get messages to console, >that could mean we split existing colour escape code processing and the >like. Oleg already persuaded me to add options to toally configure it out, so there is no impact for you. >- People redirect the console feed other places via ioctl. Some of them >parse "<%d>" as the start Interestingly enough, the part is not transferred over serial, but that seems another story. >- If you want to do "pretty" boot up you do it in X or frame buffer >(which is going to get easier and easier with the X shift to kernel side >video support) fb is slow. Feels like a 9600bps serial line. Let everyone have his own fun. - 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] Cute feature: colored printk output
On Oct 6 2007 20:50, Bill Davidsen wrote: >> >>> I start my root xterm in white on blue for identification, so color coding >>> sounds like a great idea to me. >> >> This has nothing to do with xterms, this is "VGA color console" only. >> xterm config is in /usr/share/X11/app-defaults/XTerm-color. > > Try reparsing that... I said I use color coding in root xterm, so I am > generally in favor of the color coding concept to make important messages > obvious. Is that clearer? A reparse did it. - 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/
