Hello list,
People collect stamps, etc. and I do patches. It is April 01, but let ye

know that even the patch that would get the most naks is not really

meant as an April joke.

Most of them are independent, but I'll let `quilt graph` judge their

dependencies.
	[01/] vt-sysfs-for-colors.diff

	[02/] vt-pure-colors.diff

	[03/] vt-underline-color.diff

	[04/] vt-printk-color.diff

	[05/] fix-kthread-niceness.diff

	[06/] isofs-add-write-bit.diff

	[07/] kconfig-dynamic-frequency.diff

	[08/] console-printk-level.diff

	[09/] zlib-decompression-status.diff

	[10/] show-partitions-on-mount-error.diff

	[11/] samba-eintr-fix.diff

	[12/] cifs-use-mutex.diff

	[13/] show-pipesize-in-stat.diff

	[14/] kconfig-allow-override.diff

	[15/] use-regular-eth-suffix.diff

	[16/] warn-on-kthread-name-truncation.diff
(`quilt graph` says the order of the vt-* ones is important.)
Jan

--

-

Andrew Morton noted in http://lkml.org/lkml/2006/6/30/247
	"""We do occasionally hit task_struct.comm[] truncation, when people

	use "too-long-a-name%d" for their kernel thread names."""
This patch warns when such a truncation happens.
Already posted on http://lkml.org/lkml/2006/7/3/93
Signed-off-by: Jan Engelhardt <jengelh@gmx.de>

Cc: Andrew Morton <akpm@linux-foundation.org>
 kthread.c |    7 +++++--

 1 file changed, 5 insertions(+), 2 deletions(-)
Index: linux-2.6.21-rc5/kernel/kthread.c

===================================================================

--- linux-2.6.21-rc5.orig/kernel/kthread.c

+++ linux-2.6.21-rc5/kernel/kthread.c

@@ -176,8 +176,11 @@ struct task_struct *kthread_create(int (

 	if (!IS_ERR(create.result)) {

 		va_list args;

 		va_start(args, namefmt);

-		vsnprintf(create.result->comm, sizeof(create.result->comm),

-			  namefmt, args);

+		if(vsnprintf(create.result->comm, sizeof(create.result->comm),

+		  namefmt, args) != strlen(create.result->comm))

+			printk(KERN_WARNING "kthread_create: command name of "

+			  "pid %d truncated to \"%s\"\n", create.result->pid,

+			  create.result->comm);

 		va_end(args);

 	}
#<EOF>

-

I'm not sure that it's a big enough problem to go adding code for, really.

-

No, not really. If there are any kthread spawners that do exceed the limit,

I would have probably gotten a message by now over the last handful of kernel

releases. So everything seems clear.
Jan

--

-

Some radio adapter drivers wrongly(?) name their devices "wlan%d"

instead of "eth%d" (if you ask me, it should be %u - but not today).
Technically, they operate like Ethernet, and in fact, running

`/sbin/ip a` shows "link/ether" instead of "link/ieee80211".

This patch renames them back, but I would appreciate some comment,

explanation or at least link why they actually have wlan%d there.
Signed-off-by: Jan Engelhardt <jengelh@gmx.de>

Cc: Jouni Malinen <jkmaline@cc.hut.fi> (hostap)

Cc: Jeroen Vreeken <pe1rxq@amsat.org> (zd1201)
 hostap/hostap_hw.c |    4 ++--

 zd1201.c           |    2 +-

 2 files changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6.21-rc5/drivers/net/wireless/hostap/hostap_hw.c

===================================================================

--- linux-2.6.21-rc5.orig/drivers/net/wireless/hostap/hostap_hw.c

+++ linux-2.6.21-rc5/drivers/net/wireless/hostap/hostap_hw.c

@@ -81,10 +81,10 @@ static int dtim_period[MAX_PARM_DEVICES]

 module_param_array(dtim_period, int, NULL, 0444);

 MODULE_PARM_DESC(dtim_period, "DTIM period");
-static char dev_template[16] = "wlan%d";

+static char dev_template[16] = "eth%d";

 module_param_string(dev_template, dev_template, sizeof(dev_template), 0444);

 MODULE_PARM_DESC(dev_template, "Prefix for network device name (default: "

-		 "wlan%d)");

+		 "eth%d)");
 #ifdef final_version

 #define EXTRA_EVENTS_WTERR 0

Index: linux-2.6.21-rc5/drivers/net/wireless/zd1201.c

===================================================================

--- linux-2.6.21-rc5.orig/drivers/net/wireless/zd1201.c

+++ linux-2.6.21-rc5/drivers/net/wireless/zd1201.c

@@ -1787,7 +1787,7 @@ static int zd1201_probe(struct usb_inter

 	zd->dev->tx_timeout = zd1201_tx_timeout;

 	zd->dev->set_multicast_list = zd1201_set_multicast;

 	zd->dev->set_mac_address = zd1201_set_mac_address;

-	strcpy(zd->dev->name, "wlan%d");

+	strcpy(zd->dev->name, "eth%d");
 	err = zd1201_getconfig(zd, ZD1201_RID_CNFOWNMACA...
[ message continues ]

NACK.  This has the potential to significantly break backwards-

compatibility for users of those cards who are not using udev to

maintain consistent device naming (because they only have a single

card, for example).  I would recommend against applying it for that

reason.
Cheers,

Kyle Moffett
-

The address may look like wired Ethernet (both are based on IEEE 802

standards), but IEEE 802.11 does not behave like IEEE 802.3. For

example, one cannot send frames with a foreign source address in client

mode when using IEEE 802.11 which is clearly different from wired

Ethernet. IEEE 802.11 interfaces (in client mode) cannot be bridged at
Renames _back_? No it doesn't. Host AP driver has never used eth%d as
NAK. Host AP driver has been using wlan%d for close to seven years and I

see no reason to change it now. This will just cause problems for users.

If someone wants to rename the interface to something else, they can do

it with number of different ways from user space. The kernel default

should not be changed at this point.
--

Jouni Malinen                                            PGP id EFC895FA

-

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.
Already posted at http://lkml.org/lkml/2006/10/25/81

Signed-off-by: Jan Engelhardt <jengelh@gmx.de>

Cc: Sam Ravnborg <sam@ravnborg.org>
 confdata.c |   14 +++++---------

 1 file changed, 5 insertions(+), 9 deletions(-)
Index: linux-2.6.21-rc5/scripts/kconfig/confdata.c

===================================================================

--- linux-2.6.21-rc5.orig/scripts/kconfig/confdata.c

+++ linux-2.6.21-rc5/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);

#<EOF>

-

This part of kconfig is taken care of by Roman Zippel.

Kept the full mail for his reference.
	Sam
-

---

~Randy

*** Remember to use Documentation/SubmitChecklist when testing your code ***

-

Show the fill status of a pipe (in bytes) when stat'ing one.
Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
 fs/stat.c             |   31 ++++++++++++++++++++++++++++++-

 include/linux/un.h    |    2 ++

 include/net/af_unix.h |    3 +++

 net/unix/af_unix.c    |   10 ++++++++++

 4 files changed, 45 insertions(+), 1 deletion(-)
Index: linux-2.6.21-rc5/fs/stat.c

===================================================================

--- linux-2.6.21-rc5.orig/fs/stat.c

+++ linux-2.6.21-rc5/fs/stat.c

@@ -14,6 +14,10 @@

 #include <linux/namei.h>

 #include <linux/security.h>

 #include <linux/syscalls.h>

+#include <linux/blkdev.h>

+#include <linux/genhd.h>

+#include <linux/pipe_fs_i.h>

+#include <net/af_unix.h>

 #include <linux/pagemap.h>
 #include <asm/uaccess.h>

@@ -31,7 +35,32 @@ void generic_fillattr(struct inode *inod

 	stat->atime = inode->i_atime;

 	stat->mtime = inode->i_mtime;

 	stat->ctime = inode->i_ctime;

-	stat->size = i_size_read(inode);

+	stat->size = 0;

+	if (S_ISFIFO(inode->i_mode)) {

+		const struct pipe_inode_info *info = inode->i_pipe;

+		int i;

+		stat->size = 0;

+		if (info != NULL) {

+			for (i = 0; i < PIPE_BUFFERS; ++i) {

+				const struct pipe_buffer *buf = &info->bufs[i];

+				if (buf != NULL && buf->page != NULL)

+					stat->size += buf->len;

+			}

+		}

+	} else if (S_ISSOCK(inode->i_mode)) {

+#ifdef CONFIG_UNIX_MODULE

+		loff_t (*uxsize)(struct inode *) = __symbol_get("unixsock_size");

+		if (uxsize != NULL) {

+			stat->size = uxsize(inode);

+			symbol_put("unixsock_size");

+		}

+#endif

+#if defined(CONFIG_UNIX) && !defined(CONFIG_UNIX_MODULE)

+		stat->size = unixsock_size(inode);

+#endif

+	} else {

+		stat->size = i_size_read(inode);

+	}

 	stat->blocks = inode->i_blocks;

 	stat->blksize = (1 << inode->i_blkbits);

 }

Index: linux-2.6.21-rc5/include/linux/un.h

================...
[ message continues ]

On Sun, 1 Apr 2007 20:17:24 +0200 (MEST)
Please dont do that, adding uggly tests in generic_fillattr()
The following patch does the right thing for pipes, I let you doing the same for sockets...
[PATCH] : fill the size of pipes
Instead of reporting 0 in size when stating() a pipe, we give the number of queued bytes. This might avoid using ioctl(FIONREAD) to get this information.
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>

---

--- linux-2.6.21-rc5-mm3/fs/pipe.c

+++ linux-2.6.21-rc5-mm3/fs/pipe.c

@@ -570,27 +570,34 @@ bad_pipe_w(struct file *filp, const char

 	return -EBADF;

 }
+static int pipe_size(struct inode *inode)

+{

+	struct pipe_inode_info *pipe;

+	int count, buf, nrbufs;

+

+	mutex_lock(&inode->i_mutex);

+	pipe = inode->i_pipe;

+	count = 0;

+	buf = pipe->curbuf;

+	nrbufs = pipe->nrbufs;

+	while (--nrbufs >= 0) {

+		count += pipe->bufs[buf].len;

+		buf = (buf+1) & (PIPE_BUFFERS-1);

+	}

+	mutex_unlock(&inode->i_mutex);

+	return count;

+}

+

 static int

 pipe_ioctl(struct inode *pino, struct file *filp,

 	   unsigned int cmd, unsigned long arg)

 {

 	struct inode *inode = filp->f_path.dentry->d_inode;

-	struct pipe_inode_info *pipe;

-	int count, buf, nrbufs;

+	int count;
 	switch (cmd) {

 		case FIONREAD:

-			mutex_lock(&inode->i_mutex);

-			pipe = inode->i_pipe;

-			count = 0;

-			buf = pipe->curbuf;

-			nrbufs = pipe->nrbufs;

-			while (--nrbufs >= 0) {

-				count += pipe->bufs[buf].len;

-				buf = (buf+1) & (PIPE_BUFFERS-1);

-			}

-			mutex_unlock(&inode->i_mutex);

-

+			count = pipe_size(inode);

 			return put_user(count, (int __user *)arg);

 		default:

 			return -EINVAL;

@@ -908,6 +915,20 @@ static struct dentry_operations pipefs_d

 	.d_dname	= pipefs_dname,

 };
+int pipe_getattr(struct vfsmount *mnt, struct dentry *dentry,

+		   struct kstat *stat)

+{

+	struct inode *inode = dentry->d_inode;

+

+	generic_fillattr(inode, stat);

+	stat->s...
[ message continues ]

Is struct sock->sk_receive_queue->qlen actually the thing I am

looking for? (Previously, I had struct sock->sk_rcvbuf, which was

obviously wrong.)
Thanks,

Jan

--

-

find net | xargs grep -n SIOCINQ
I suspect you will find unix_ioctl() in net/unix/af_unix.c ?
BTW, my patch only worked for pipes, not fifos. Ie pipe(), not

open("/some/fifo.p", ...)
-

Hi,
Thanks for your patch. There is a question however; why don't you do

  stat->size = pipe_size(inode);

in generic_fill_attr (perhaps wrapped into an if(S_ISFIFO))?
Regards,

Jan

--

-

Is this useful?  It seems rather an obscure thing, and we generally need a

good reason to go adding Linux-specific goodies to standard system calls
That's wildly incorrect coding style, and it doesn't use tabs.

-

Other OS seem to always show 0, as Linux does usually. So I do not think

programs actually rely on it having any specific value.

I thought adding pipesize might be helpful in dianosing pipe cases, akin to
Which means I something really went wrong, because I knew I went through it for

cleanup.

-

Verbatim copy of original mail:
The recent change to "allow Windows blocking locks to be cancelled

via a CANCEL_LOCK call" introduced a new semaphore in struct

cifsFileInfo, lock_sem.  However, semaphores used as mutexes are

deprecated these days, and there's no reason to add a new one to the

kernel. Therefore, convert lock_sem to a struct mutex (and also fix

one indentation glitch on one of the lines changed anyway).
Compile tested only, since I don't use CIFS.
Signed-off-by: Roland Dreier <roland@digitalvampire.org>

*<<<
My 2¢:

Compile tested. Runtime tested. Did not break.
From: Roland Dreier <roland@digitalvampire.org>

Signed-off-by: Jan Engelhardt <jengelh@gmx.de>

Cc: Roland Dreier <roland@digitalvampire.org>
 cifsglob.h |    2 +-

 dir.c      |    2 +-

 file.c     |   14 +++++++-------

 3 files changed, 9 insertions(+), 9 deletions(-)
Index: linux-2.6.21-rc5/fs/cifs/cifsglob.h

===================================================================

--- linux-2.6.21-rc5.orig/fs/cifs/cifsglob.h

+++ linux-2.6.21-rc5/fs/cifs/cifsglob.h

@@ -311,7 +311,7 @@ struct cifsFileInfo {

 	/* lock scope id (0 if none) */

 	struct file * pfile; /* needed for writepage */

 	struct inode * pInode; /* needed for oplock break */

-	struct semaphore lock_sem;

+	struct mutex lock_mutex;

 	struct list_head llist; /* list of byte range locks we have. */

 	unsigned closePend:1;	/* file is marked to close */

 	unsigned invalidHandle:1;  /* file closed via session abend */

Index: linux-2.6.21-rc5/fs/cifs/dir.c

===================================================================

--- linux-2.6.21-rc5.orig/fs/cifs/dir.c

+++ linux-2.6.21-rc5/fs/cifs/dir.c

@@ -274,7 +274,7 @@ cifs_create(struct inode *inode, struct

 			pCifsFile->invalidHandle = FALSE;

 			pCifsFile->closePend     = FALSE;

 			init_MUTEX(&pCifsFile->fh_sem);

-			init_MUTEX(&pCifsFile->lock_sem);

+			mutex_init(&pCifsFile->lock_mutex);

 			INIT_LIST_HEAD(&amp...
[ message continues ]

Thanks for resurrecting this.  My original email to the CIFS

maintainer got dropped somewhere, but I think this patch is probably

still a good idea.

--

Roland Dreier  <roland@digitalvampire.org>  GPG Key: 1024D/E0EEFAC0

Fingerprint:     A89F B5E9 C185 F34D BD50  4009 37E2 25CC E0EE FAC0
 Sending >500KB attachments is forbidden by the Geneva Convention.

        Your country may be at risk if you fail to comply.

-

From: Dave Jones

Already posted at http://lkml.org/lkml/2005/7/7/255
Signed-off-by: Jan Engelhardt <jengelh@gmx.de>

Cc: Dave Jones <Dave Jones <davej@redhat.com>
 request.c |    1 +

 1 file changed, 1 insertion(+)
Index: linux-2.6.21-rc5/fs/smbfs/request.c

===================================================================

--- linux-2.6.21-rc5.orig/fs/smbfs/request.c

+++ linux-2.6.21-rc5/fs/smbfs/request.c

@@ -347,6 +347,7 @@ int smb_add_request(struct smb_request *

 			smb_rput(req);

 		}

 		smb_unlock_server(server);

+		return -EINTR;

 	}
 	if (!timeleft) {

#<EOF>

-

This can return -EINTR if timeleft == 0 && !signal_pending(), which seems

wrong.
-

On Sun, Apr 01, 2007 at 08:16:22PM +0200, Jan Engelhardt wrote:

 >

 > From: Dave Jones

 > Already posted at http://lkml.org/lkml/2005/7/7/255
I had to stop and think if this was an April 1st :)

Back in 2005 it seemed I had a strong enough stomach

to wade through smbfs for some unknown reason.

These days like many others, I wish someone would

just put the thing out of its misery.
In Fedora we switched it off (in about 2005 iirc)

in favor of using cifs, which for the most part

is a drop-in replacement.  There still remain 1-2

corner cases where it doesn't work iirc, but

the situation is a lot better than it used to be.
As to whether the patch is worthwhile/correct..

I really don't know.  I posted it back then in the hopes

that someone smbfs-savvy would pop up and review it.

As you can see from the archive, no-one did.
	Dave
--

http://www.codemonkey.org.uk

-

It seems to have been resent once, 7 days after you:

	http://lkml.org/lkml/2005/7/15/231
At that time, I had experienced strange copy failures ("No such file or

directory") while the directory being copied was not modified. With the

patch, I at least got EINTR instead of ENOENT, which I think made cp

think once more to retry.
Jan

--

-

On Sun, Apr 01, 2007 at 09:28:03PM +0200, Jan Engelhardt wrote:

 >

 > On Apr 1 2007 15:09, Dave Jones wrote:

 > >On Sun, Apr 01, 2007 at 08:16:22PM +0200, Jan Engelhardt wrote:

 >

 > > > From: Dave Jones

 > > > Already posted at http://lkml.org/lkml/2005/7/7/255

 > >

 > >I had to stop and think if this was an April 1st :)

 >

 > Read the mail entitled "[PATCH 0/16] Assorted patches".
That's what happens when you read inbox before mailing list folders :)
 > >As to whether the patch is worthwhile/correct..

 > >I really don't know.  I posted it back then in the hopes

 > >that someone smbfs-savvy would pop up and review it.

 > >As you can see from the archive, no-one did.

 >

 > It seems to have been resent once, 7 days after you:

 > 	http://lkml.org/lkml/2005/7/15/231
Hmm, with no changelog. I wonder if JA was hitting that bug

and independantly came up with that patch, or was just

resubmitting on my behalf.
 > At that time, I had experienced strange copy failures ("No such file or

 > directory") while the directory being copied was not modified. With the

 > patch, I at least got EINTR instead of ENOENT, which I think made cp

 > think once more to retry.
I suppose we could throw it in -mm and see if anyone screams. Andrew?
	Dave
--

http://www.codemonkey.org.uk

-

Display all possible partitions when the root filesystem is not mounted.

This helps to track spell'o's and missing drivers.
From: David Alan Gilbert, http://lkml.org/lkml/2005/2/26/92
Updated to work with newer kernels.
Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
 block/genhd.c         |   54 ++++++++++++++++++++++++++++++++++++++++++++++++++

 include/linux/genhd.h |    1

 init/do_mounts.c      |    7 +++++-

 3 files changed, 61 insertions(+), 1 deletion(-)
Index: linux-2.6.21-rc5/block/genhd.c

===================================================================

--- linux-2.6.21-rc5.orig/block/genhd.c

+++ linux-2.6.21-rc5/block/genhd.c

@@ -215,6 +215,60 @@ struct gendisk *get_gendisk(dev_t dev, i

 	return  kobj ? to_disk(kobj) : NULL;

 }
+/*

+ * printk a full list of all partitions - intended for

+ * places where the root filesystem can't be mounted and thus

+ * to give the victim some idea of what went wrong

+ */

+void printk_all_partitions(void)

+{

+	int n;

+        struct gendisk* sgp;

+	mutex_lock(&block_subsys_lock);

+

+        /* For each block device... */

+	list_for_each_entry(sgp, &block_subsys.kset.list, kobj.entry) {

+		char buf[BDEVNAME_SIZE];

+	  	/*

+	  	 * Don't show empty devices or things that have been surpressed

+	  	 */

+		if (get_capacity(sgp) &&

+		  !(sgp->flags & GENHD_FL_SUPPRESS_PARTITION_INFO)) {

+			/*

+			 * Note, unlike /proc/partitions I am showing the

+			 * numbers in hex in the same format as the root=

+			 * option

+			 */

+			printk("%02x%02x %10llu %s",

+			       sgp->major, sgp->first_minor,

+			       (unsigned long long)get_capacity(sgp) >> 1,

+			       disk_name(sgp, 0, buf));

+			if ((sgp->driverfs_dev) &&

+			  (sgp->driverfs_dev->driver)) {

+				printk(" driver: %s\n",

+				       sgp->driverfs_dev->driver->name);

+			} else {

+				printk(" (driver?)\n");

+			}

+

+			/* now show the partitions */

+			for (n = 0; n < sgp->minor...
[ message continues ]

tabs-vs-spaces problem.
--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-

Already fixed and sent out in http://lkml.org/lkml/2007/4/2/75
Jan

--

-

It would be nice to include a sample of the resulting output for people

to review.

-

Hi,
Seems reasonable.
Loaded with PXELINUX...
	LABEL l

		KERNEL bzImage

		APPEND root=/dev/foobar
or root=/dev/sdb both produce:
[...]

VFS: Cannot open root device "foobar" or unknown-block(0,0)

Please append a correct "root=" boot option; here are the available partitions:

0800    8388608 sda driver: sd

  0801     192748 sda1

  0802    8193150 sda2

0810    4194304 sdb driver: sd

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
With root=/dev/sdb, the list of possible filesystems is also displayed

(a patch that was merged a (long)while back).
---
Integrated __init annotation, and deindented the loop by one level.

Replaces original patch.
Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
Index: linux-2.6.21-rc5/block/genhd.c

===================================================================

--- linux-2.6.21-rc5.orig/block/genhd.c

+++ linux-2.6.21-rc5/block/genhd.c

@@ -215,6 +215,59 @@ struct gendisk *get_gendisk(dev_t dev, i

 	return  kobj ? to_disk(kobj) : NULL;

 }
+/*

+ * printk a full list of all partitions - intended for

+ * places where the root filesystem can't be mounted and thus

+ * to give the victim some idea of what went wrong

+ */

+void __init printk_all_partitions(void)

+{

+	int n;

+	struct gendisk *sgp;

+	mutex_lock(&block_subsys_lock);

+

+	/* For each block device... */

+	list_for_each_entry(sgp, &block_subsys.kset.list, kobj.entry) {

+		char buf[BDEVNAME_SIZE];

+		/*

+		 * Don't show empty devices or things that have been surpressed

+		 */

+		if (get_capacity(sgp) == 0 ||

+		  (sgp->flags & GENHD_FL_SUPPRESS_PARTITION_INFO))

+			continue;

+

+		/*

+		 * Note, unlike /proc/partitions, I am showing the numbers in

+		 * hex - the same format as the root= option takes.

+		 */

+		printk("%02x%02x %10llu %s",

+		       sgp->major, sgp->first_minor,

+		       (unsigned long long)get_capacity(sgp) >> 1,

+		       disk_name(sgp, 0, buf));

+		if (sgp->driverfs_d...
[ message continues ]

I made this __init.
-

Shows some stars during decompression. This is particularly useful on

old 386s where one asterisk is probably printed every second - making

the long linux and initramfs uncompress progress more evident.
Not compile tested outside {i386, x86_64} - don't have other machines.
Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
 arch/alpha/boot/misc.c                    |    2 +-

 arch/arm/boot/compressed/misc.c           |    4 ++--

 arch/arm26/boot/compressed/misc.c         |    4 ++--

 arch/cris/arch-v10/boot/compressed/misc.c |    2 +-

 arch/cris/arch-v32/boot/compressed/misc.c |    2 +-

 arch/i386/boot/compressed/misc.c          |    2 +-

 arch/m32r/boot/compressed/misc.c          |    2 +-

 arch/sh/boot/compressed/misc.c            |    2 +-

 arch/sh64/boot/compressed/misc.c          |    2 +-

 arch/x86_64/boot/compressed/misc.c        |    2 +-

 init/do_mounts_rd.c                       |    7 ++++++-

 init/initramfs.c                          |    7 ++++++-

 lib/inflate.c                             |    9 +++++----

 13 files changed, 29 insertions(+), 18 deletions(-)
Index: linux-2.6.21-rc5/arch/alpha/boot/misc.c

===================================================================

--- linux-2.6.21-rc5.orig/arch/alpha/boot/misc.c

+++ linux-2.6.21-rc5/arch/alpha/boot/misc.c

@@ -201,7 +201,7 @@ decompress_kernel(void *output_start,
 	makecrc();

 /*	puts("Uncompressing Linux..."); */

-	gunzip();

+	gunzip(NULL);

 /*	puts(" done, booting the kernel.\n"); */

 	return output_ptr;

 }

Index: linux-2.6.21-rc5/arch/arm/boot/compressed/misc.c

===================================================================

--- linux-2.6.21-rc5.orig/arch/arm/boot/compressed/misc.c

+++ linux-2.6.21-rc5/arch/arm/boot/compressed/misc.c

@@ -355,7 +355,7 @@ decompress_kernel(ulg output_start, ulg 
 	makecrc();

 	putstr("Uncompressing Linux...");

-	gunzip();

+	gunzip(putstr);

 	putstr(" done, booting the kernel.\n");

 	return output_ptr;

 }

@@ -369,7 +369,7 @@ int main()
 	make...
[ message continues ]

You are sure this wasn't meant as an April fools joke?  Passing the

address of an inline function certainly has a humorous aspect. ;)
Also, you can remove the "return;" in the void function and possibly
The patch alternately uses puts() and putstr(), which looks rather odd.

Not sure whether that makes sense or not.
Jörn
--

My second remark is that our intellectual powers are rather geared to

master static relations and that our powers to visualize processes

evolving in time are relatively poorly developed.

-- Edsger W. Dijkstra

-

Hi,
You bet. Well, "inline" is, as far as I hear the voices of the C standard, just

a "hint" to the compiler that this function should be inlined. If it cannot do

that, well, then do not inline it. But you have a point, it gets interesting

when "inline" expands to __attribute__((always_inline)). Well, let's hope that
It is because some arches seem to have a arch-specific "output function"

called puts() try the following:
$ grep -r 'puts(' arch/arm26/

(results)

$ grep -r 'puts(' arch/i386/

(no results)
So yes, I would need some advice what people were thinking here. If it

was not for this arch specific stuff, the putstr() function I added in

lib/ would also be gone and the "*" could be directly printed in

gunzip(), making the extra argument to gunzip superfluous.
The extra putstr() in init/initramfs.c [cf. putstr() in lib/inflate.c]

is also something I did not know how to really do better.
Thoughts are appreciated and stylofixed patch below.

(lib/inflate.c does not even use tabs, what could I possibly do more wrong than

already? :p)
---
Shows some stars during decompression. This is particularly useful on old 386s

where one asterisk is probably printed every second - making the long linux and

initramfs uncompress progress more evident.

Not compile tested outside {i386, x86_64} - don't have other machines.
Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
 arch/alpha/boot/misc.c                    |    2 +-

 arch/arm/boot/compressed/misc.c           |    4 ++--

 arch/arm26/boot/compressed/misc.c         |    4 ++--

 arch/cris/arch-v10/boot/compressed/misc.c |    2 +-

 arch/cris/arch-v32/boot/compressed/misc.c |    2 +-

 arch/i386/boot/compressed/misc.c          |    2 +-

 arch/m32r/boot/compressed/misc.c          |    2 +-

 arch/sh/boot/compressed/misc.c            |    2 +-

 arch/sh64/boot/compressed/misc.c          |    2 +-

 arch/x86_64/boot/compressed/misc.c        |    2 +-

 init/do_mounts_rd.c                       |    7 ++++++-

 init/init...
[ message continues ]

Allow the printk level to be set using a "conlevel=" parameter.

(Or is there already a different bootoption that does the same thing?)
Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
 printk.c |    9 +++++++++

 1 file changed, 9 insertions(+)
Index: linux-2.6.21-rc5/kernel/printk.c

===================================================================

--- linux-2.6.21-rc5.orig/kernel/printk.c

+++ linux-2.6.21-rc5/kernel/printk.c

@@ -747,6 +747,15 @@ void resume_console(void)

 }

 #endif /* CONFIG_DISABLE_CONSOLE_SUSPEND */
+static __init int set_conlevel(char *str)

+{

+	if(*str >= '0' && *str <= '9')

+		*console_printk = *str - '0';

+	return 1;

+}

+

+__setup("conlevel=", set_conlevel);

+

 /**

  * acquire_console_sem - lock the console system for exclusive use.

  *

#<EOF>

-

Yes, there's "loglevel", as well as
---

~Randy

*** Remember to use Documentation/SubmitChecklist when testing your code ***

-

Make HZ fully configurable through menuconfig.
Already posted at http://lkml.org/lkml/2006/6/18/111
Signed-off-by: Jan Engelhardt

Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> (http://lkml.org/lkml/2006/11/8/307)

Cc: Sam Ravnborg <sam@ravnborg.org>
 Kconfig.hz |   70 +++++++++++++++++++++++--------------------------------------

 1 file changed, 27 insertions(+), 43 deletions(-)
Index: linux-2.6.21-rc5/kernel/Kconfig.hz

===================================================================

--- linux-2.6.21-rc5.orig/kernel/Kconfig.hz

+++ linux-2.6.21-rc5/kernel/Kconfig.hz

@@ -2,50 +2,34 @@

 # Timer Interrupt Frequency Configuration

 #
-choice

-	prompt "Timer frequency"

-	default HZ_250

-	help

-	 Allows the configuration of the timer frequency. It is customary

-	 to have the timer interrupt run at 1000 Hz but 100 Hz may be more

-	 beneficial for servers and NUMA systems that do not need to have

-	 a fast response for user interaction and that may experience bus

-	 contention and cacheline bounces as a result of timer interrupts.

-	 Note that the timer interrupt occurs on each processor in an SMP

-	 environment leading to NR_CPUS * HZ number of timer interrupts

-	 per second.

-

-

-	config HZ_100

-		bool "100 HZ"

-	help

-	  100 Hz is a typical choice for servers, SMP and NUMA systems

-	  with lots of processors that may show reduced performance if

-	  too many timer interrupts are occurring.

-

-	config HZ_250

-		bool "250 HZ"

-	help

-	 250 Hz is a good compromise choice allowing server performance

-	 while also showing good interactive responsiveness even

-	 on SMP and NUMA systems. If you are going to be using NTSC video

-	 or multimedia, selected 300Hz instead.

-

-	config HZ_300

-		bool "300 HZ"

-	help

-	 300 Hz is a good compromise choice allowing server performance

-	 while also showing good interactive responsiveness even

-	 on SMP and NUMA systems and exactly dividing by both PAL and

-	 NTSC frame rates for video and multimedia work.

-

-	config H...
[ message continues ]

Instead of that, what about something like this instead:  NOTE: I

know my mailer mangles diffs and this one was hand-edited based on

Jan's diff from within my mailer so it probably doesn't apply, but

it's enough to point out the idea:
diff --fast -Ndpru linux-2.6.17-rc6~/kernel/Kconfig.hz linux-2.6.17-

rc6+/kernel/Kconfig.hz

--- linux-2.6.17-rc6~/kernel/Kconfig.hz	2006-06-06 02:57:02.000000000

+0200

+++ linux-2.6.17-rc6+/kernel/Kconfig.hz	2006-06-16 17:15:46.884794000

+0200

@@ -36,10 +36,17 @@

  	 1000 HZ is the preferred choice for desktop systems and other

  	 systems requiring fast interactive responses to events.
+	config HZ_CUSTOM

+		bool "Custom HZ"

+	help

+	 This allows you to specify your own custom timer frequency, if

+	 the default options are not satisfactory for your use.

+

  endchoice
  config HZ

-	int

+	int if !HZ_CUSTOM

+	int "Customized HZ value" if HZ_CUSTOM

  	default 100 if HZ_100

  	default 250 if HZ_250

  	default 1000 if HZ_1000
-

People always come up with new complexities I never thought kconfig

would be able to do. Nice stuff. I'll take up on your idea and

incorporate it right away.
But I would have to ask: Why do we need 100/250/300/1000 if there is

anyway an input field for the user to enter - s/he should read the

help text for Known Good values, should not s/he?
Jan

--

-

Actually, probably what should be done is make the "HZ_CUSTOM" option

depend on EXPERIMENTAL/

EMBEDDED/"EXPERT"/"I_KNOW_WHAT_THE_HELL_IM_DOING" or some other

equivalent option, because a wrong choice for HZ has the potential to

really screw up a system.  For example, 10000+ would make most

systems spend a significant portion of their time processing timer

interrupts and context switches, and less than 100 or so would make

the system seem jerky.  The point is to encourage the average kernel

builder not to change from one of the default options unless they

really know what they're doing.
Cheers,

Kyle Moffett
-

conversely, if someone truly wants to set a kernel config option to

some outrageous value, they should have that freedom.  it's called

"playing."
rday

--

========================================================================

Robert P. J. Day

Linux Consulting, Training and Annoying Kernel Pedantry

Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page

========================================================================

-

EXPERIMENTAL is most often enabled by distributors.
Point taken. Ehm, I already once tried making a 10000-Hz kernel

around 2.6.13-15 or so. It did not compile because some header files had

#error directives for HZ >= 1536. (jiffies.h:33 if you want

to know.) IIRC there also was another place somewhere in networking

code that #errors out at >8192.
Jan

--

-

Add a CONFIG_I_KNOW_WHAT_THE_HELL_I_AM_DOING variable with a really

strong

warning attached to it (and a shorter CONFIG_EXPERT variable for use in

Kconfig files where it's a PITA to type out the full name)
Signed-off-by: Kyle Moffett <mrmacman_g4@mac.com>
---
Since my mailer tends to mangle patches I've attached this one

Do it like Linus Torvalds and Marissa Mayer and get a better mailer :-D
Index: linux-2.6.20.1/init/Kconfig

===================================================================

--- linux-2.6.20.1.orig/init/Kconfig

+++ linux-2.6.20.1/init/Kconfig

@@ -40,6 +40,35 @@

 	you say Y here, you will be offered the choice of using features or

 	drivers that are currently considered to be in the alpha-test phase.
+config I_KNOW_WHAT_THE_HELL_I_AM_DOING
Let's just hope kconfig does not bust the stack.

Perhaps we could shorten that: I_KNOW_WTF_I_AM_DOING
+	bool "Prompt for config options which will break your computer"
s/will break (.*)/could break $1 if done wrong/;
+	---help---

+	  Some kernel developers sometimes need to tune kernel parameters

+	  outside of their normal limits.  Without complete knowledge of

+	  exactly what you are doing you are likely to corrupt the laws of

+	  physics and destroy the universe (well, not quite, but you'll

+	  certainly corrupt your data and crash your box).  If you really

+	  know what you're doing and accept that if it breaks you get to

+	  keep the pieces, then go ahead and enable this option.

+

+	  NOTICE:  Bug reports where this option is turned on in the kernel

+	  config will be: (not necessarily in this order)

+	    1)  Laughed at hysterically

+	    2)  Made much fun of

+	    3)  Ridiculed until we're red in the face

+	    4)  Ignored

+

+	  WARNING:  If you are building a kernel for a distribution, DO NOT

+	  TURN THIS OPTION ON!!!  Instead you should submit a patch which

+	  adds a new safe value to the list of possibilities for the config

+	  option you're interested in.  Otherwise your users might have a

+	  hard time getting kernel support on the LKML.

+

+config EXPERT

+	bool

+	depends on I_KNOW_WHAT_THE_HELL_I_AM_DOING

+	default y

+

 config BROKEN

 	bool
Given that, I hope the number of options dependent on CONFIG_EXPERT will

outnumber those depending on CONFIG_I_KNOW_WTF_I_AM_DOING.
If you want my answer:...
[ message continues ]

Well, we've had problems in the past where people turn on options

under CONFIG_EXPERIMENTAL or CONFIG_EMBEDDED and it breaks in exactly

the specified fashion and they complain on LKML.  The point of this

is to expose kconfig tunables which a "normal" kconfig user would get

wrong 99% of the time and would break in obscure ways.  For example,

the "CONFIG_MULTITHREAD_PCI_PROBE" option, if it was re-added for  
Ah, see, due to the magic of kconfig language this does not show up

as a separate option (no text for the "bool") identifier.  It's just

an alias for I_KNOW_WHAT_THE_HELL_I_AM_DOING to make it easier to use

in other Kconfig files ("depends EXPERT && SOME_OPTION!=n &&  
Cheers,

Kyle Moffett
-

When you know what you're doing you can just patch then Kconfig files.

IMHO that's better than this.
-Andi

-

Gah, I complain about my mailer mangling patches and then it's me

that mangles the patch.  Sorry for forgetting a subject line.
Cheers,

Kyle Moffett

-

Add %S_IWUGO bit for isofs. Makes it easier to poke on files after

they have been copied from an ISO-9660 filesystem because they are

ofte copied in `cp -p` or perhaps `rsync -p` mode.

They are still not writable though, and isofs will continue to

correctly return -EROFS for writes.
Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
 inode.c |    4 ++--

 1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.21-rc5/fs/isofs/inode.c

===================================================================

--- linux-2.6.21-rc5.orig/fs/isofs/inode.c

+++ linux-2.6.21-rc5/fs/isofs/inode.c

@@ -362,7 +362,7 @@ static int parse_options(char *options,

 	popt->check = 'u';		/* unset */

 	popt->nocompress = 0;

 	popt->blocksize = 1024;

-	popt->mode = S_IRUGO | S_IXUGO; /* r-x for all.  The disc could

+	popt->mode = S_IRUGO | S_IWUSR | S_IXUGO; /* rwx for all.  The disc could

 					   be shared with DOS machines so

 					   virtually anything could be

 					   a valid executable. */

@@ -1221,7 +1221,7 @@ static void isofs_read_inode(struct inod

 	ei->i_file_format = isofs_file_normal;
 	if (de->flags[-high_sierra] & 2) {

-		inode->i_mode = S_IRUGO | S_IXUGO | S_IFDIR;

+		inode->i_mode = S_IRUGO | S_IWUSR | S_IXUGO | S_IFDIR;

 		inode->i_nlink = 1; /* Set to 1.  We know there are 2, but

 				       the find utility tries to optimize

 				       if it is 2, and it screws up.  It is

#<EOF>
-

Fix kevent's childs priority greedy-ness. Such tasks were always scheduled

at nice level -5 and, at that time, udev stole us the CPU time with -5.
Already posted at http://lkml.org/lkml/2005/1/10/85
Signed-off-by: Jan Engelhardt <jengelh@gmx.de>

Cc: Chris Wright <chrisw@sous-sol.org>
 kmod.c |    1 +

 1 file changed, 1 insertion(+)
Index: linux-2.6.21-rc5/kernel/kmod.c

===================================================================

--- linux-2.6.21-rc5.orig/kernel/kmod.c

+++ linux-2.6.21-rc5/kernel/kmod.c

@@ -165,6 +165,7 @@ static int ____call_usermodehelper(void 
 	/* We can run anywhere, unlike our parent keventd(). */

 	set_cpus_allowed(current, CPU_MASK_ALL);

+	set_user_nice(current, 0);
 	retval = -EPERM;

 	if (current->fs->root)

#<EOF>

-

-ETOOOBSCURE.
--- a/kernel/kmod.c~fix-kthread-nicenessdiff-fix

+++ a/kernel/kmod.c

@@ -163,6 +163,11 @@ static int ____call_usermodehelper(void 
 	/* We can run anywhere, unlike our parent keventd(). */

 	set_cpus_allowed(current, CPU_MASK_ALL);

+

+	/*

+	 * Our parent is keventd, which runs with elevated scheduling priority.

+	 * Avoid propagating that into the userspace child.

+	 */

 	set_user_nice(current, 0);
 	retval = -EPERM;

_
-

Colored kernel message output
Gives kernel messages on the console an OpenBSD-esque color to distinguish

them from regular tty (as long as that's not colored too) text.
Inspired by cko (iirc http://freshmeat.net/p/cko/), but better

implementation done by myself (handles newlines correctly).
Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
 Kconfig |   28 ++++++++++++++++++++++++++++

 vt.c    |   22 ++++++++++++++++++++++

 2 files changed, 50 insertions(+)
Index: linux-2.6.21-rc5/drivers/char/Kconfig

===================================================================

--- linux-2.6.21-rc5.orig/drivers/char/Kconfig

+++ linux-2.6.21-rc5/drivers/char/Kconfig

@@ -57,6 +57,34 @@ config VT_CONSOLE
 	  If unsure, say Y.
+config VT_CKO

+	hex "Colored kernel message output"

+	range 0x00 0xFF

+	depends on VT_CONSOLE

+	default 0x17

+	---help---

+	This option will give you ability to change the color of

+	kernel messages.

+

+	The value you need to enter here is the ASCII color value

+	composed (OR'ed) by one foreground color, one background

+	color and any number of attributes as follows:

+

+	Foreground:     Background:    Attributes:

+	0x01 blue       0x10 blue      0x08 highlight foreground

+	0x02 green      0x20 green     0x80 blinking foreground

+	0x03 cyan       0x30 cyan

+	0x04 red        0x40 red

+	0x05 magenta    0x50 red

+	0x06 brown      0x60 brown

+	0x07 gray       0x70 gray

+

+	Thus, 0x17 will yield gray-on-blue like you can see in

+	OpenBSD, 0x02 the green-on-black like on NetBSD.

+	Using "highlight foreground" does not work when you use

+	VGA Console and fonts with 512 glyphs.

+	VGA Framebuffer is not affected.

+

 config HW_CONSOLE

 	bool

 	depends on VT && !S390 && !UML

Index: linux-2.6.21-rc5/drivers/char/vt.c

===================================================================

--- linux-2.6.21-rc5.orig/drivers/char/vt.c

+++ linux-2.6.21-rc5/drivers/char/vt.c

@@ -73,6 +73,7 @@

  */
 #include <linux/module.h>

+#inc...
[ message continues ]

Add color support to the "underline" and "italic" attributes as in

OpenBSD/NetBSD-style (vt220) and xterm.
Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
 drivers/char/vt.c               |   34 ++++++++++++++++++++++++++++------

 drivers/video/console/mdacon.c  |    3 ++-

 drivers/video/console/promcon.c |    3 ++-

 drivers/video/console/sticon.c  |    2 +-

 drivers/video/console/vgacon.c  |   12 ++++++++----

 include/linux/console.h         |    2 +-

 include/linux/console_struct.h  |    3 +++

 7 files changed, 45 insertions(+), 14 deletions(-)
Index: linux-2.6.21-rc5/drivers/char/vt.c

===================================================================

--- linux-2.6.21-rc5.orig/drivers/char/vt.c

+++ linux-2.6.21-rc5/drivers/char/vt.c

@@ -348,10 +348,12 @@ void update_region(struct vc_data *vc, u
 /* Structure of attributes is hardware-dependent */
-static u8 build_attr(struct vc_data *vc, u8 _color, u8 _intensity, u8 _blink, u8 _underline, u8 _reverse)

+static u8 build_attr(struct vc_data *vc, u8 _color, u8 _intensity, u8 _blink,

+    u8 _underline, u8 _reverse, u8 _italic)

 {

 	if (vc->vc_sw->con_build_attr)

-		return vc->vc_sw->con_build_attr(vc, _color, _intensity, _blink, _underline, _reverse);

+		return vc->vc_sw->con_build_attr(vc, _color, _intensity,

+		       _blink, _underline, _reverse, _italic);
 #ifndef VT_BUF_VRAM_ONLY

 /*

@@ -368,10 +370,13 @@ static u8 build_attr(struct vc_data *vc,

 	u8 a = vc->vc_color;

 	if (!vc->vc_can_do_color)

 		return _intensity |

+		       (_italic ? 2 : 0) |

 		       (_underline ? 4 : 0) |

 		       (_reverse ? 8 : 0) |

 		       (_blink ? 0x80 : 0);

-	if (_underline)

+	if (_italic)

+		a = (a & 0xF0) | vc->vc_itcolor;

+	else if (_underline)

 		a = (a & 0xf0) | vc->vc_ulcolor;

 	else if (_intensity == 0)

 		a = (a & 0xf0) | vc->vc_ulcolor;

@@ -392,8 +397,10 @@ static u8 build_attr(struct vc_data *vc,
 static void update_attr(struct vc_data *vc)

 {

-	vc->...
[ message continues ]

ug.  It's better to include the names of the parameters, IMO.  But mixing

the two styles like this is nuts.
Happily, the declaration is unneeded anyway, so I'll just delete it.

-

The italic attribute is indeed part of ANSI standard, though not widely

implemented. Fbcon (monochrome mode) already supports inverse,

underline, and bold. I'll try to implement italics (if I can) too if

Acked-by: Antonino Daplas <adaplas@gmail.com>
Tony
-

Have the Linux kernel set a new VGA palette for the first 16 colors.

The new values reduce the saturation (white component) and therefore

increase contrast.
Already posted once: http://lkml.org/lkml/2006/1/15/149
Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
 vt.c |   12 ++++++------

 1 file changed, 6 insertions(+), 6 deletions(-)
Index: linux-2.6.21-rc5/drivers/char/vt.c

===================================================================

--- linux-2.6.21-rc5.orig/drivers/char/vt.c

+++ linux-2.6.21-rc5/drivers/char/vt.c

@@ -927,12 +927,12 @@ unsigned char color_table[] = { 0, 4, 2,

 				       8,12,10,14, 9,13,11,15 };
 /* the default colour table, for VGA+ colour systems */

-int default_red[] = {0x00,0xaa,0x00,0xaa,0x00,0xaa,0x00,0xaa,

-    0x55,0xff,0x55,0xff,0x55,0xff,0x55,0xff};

-int default_grn[] = {0x00,0x00,0xaa,0x55,0x00,0x00,0xaa,0xaa,

-    0x55,0x55,0xff,0xff,0x55,0x55,0xff,0xff};

-int default_blu[] = {0x00,0x00,0x00,0x00,0xaa,0xaa,0xaa,0xaa,

-    0x55,0x55,0x55,0x55,0xff,0xff,0xff,0xff};

+int default_red[] =

+{0x00,0xaa,0x00,0xaa,0x00,0xaa,0x00,0xaa,0x55,0xff,0x00,0xff,0x00,0xff,0x00,0xff};

+int default_grn[] =

+{0x00,0x00,0xaa,0x55,0x00,0x00,0xaa,0xaa,0x55,0x00,0xff,0xff,0x00,0x00,0xff,0xff};

+int default_blu[] =

+{0x00,0x00,0x00,0x00,0x90,0xaa,0xaa,0xaa,0x55,0x00,0x00,0x00,0xff,0xff,0xff,0xff};
 module_param_array(default_red, int, NULL, S_IRUGO | S_IWUSR);

 module_param_array(default_grn, int, NULL, S_IRUGO | S_IWUSR);

#<EOF>
-

<snip>
While the patch seems fine, this comment is not correct.  The patch is

decreasing the *brightness* in order to *increase* saturation.

Saturation[1] is the deepness of a color, not the white component

(brightness, lightness).
  - Jim Bruce
[1] http://www.poynton.com/notes/colour_and_gamma/ColorFAQ.html#RTFToC6

-

Not too sure about this, the default palette is based on ANSI/ECMA

standards (at least for the first 8 colors). Also, this will have subtle

effects on the 16-color logo. Since your first patch already allows us

to change the palette, let's leave the default alone.
Tony
-

Ok.

But to note: xterm and anything graphical (including MS Windows)

uses the anti-pale color (255,0,0) instead of (255,170,170).
Jan

--

-

Actually, what threw me off was index 4 in default_blu, which has a

value of 0x90.  This looks weird to me, but I guess that is a typo. I

really have nothing against using 0, 0, 255 instead of 170, 170, 255 in

the intense version of the first 8.
Tony 
-

That one is a psychological thing. :-) People like blue backgrounds, because a

green or red one would not really fit as a bg color for Midnight Commander,

pine and your-favorite-editor. So you choose blue because it fits nicely. (See

http://img81.imageshack.us/img81/8858/blueqj6.png for an example, and compare

with http://img81.imageshack.us/img81/7498/reddm1.png and

http://img142.imageshack.us/img142/8470/greennq2.png for counterexamples. Even

a bright blue (0,0,192) is still better than red/green, the reason being that

blue is much less percepted by the eye than green or red. You will find various

formulas on the 'net that will convert from color to grayscale - these formulas

have the 'perception' levels, which are, summarized, 76*r, 151*g, 26*b on a 255

scale.) Personally I find the regular blue (0,0,170/0xA0) a little too bright

so I turned it down to 0x90. Adjust for your preference.
Jan

--

-

Allow for the palette to be exposed and changed via sysfs. A call to

/usr/bin/reset will slurp the new definitions in for the current

console.
Already posted at http://lkml.org/lkml/2006/1/15/149
Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
 vt.c |    4 ++++

 1 file changed, 4 insertions(+)
Index: linux-2.6.21-rc5/drivers/char/vt.c

===================================================================

--- linux-2.6.21-rc5.orig/drivers/char/vt.c

+++ linux-2.6.21-rc5/drivers/char/vt.c

@@ -934,6 +934,10 @@ int default_grn[] = {0x00,0x00,0xaa,0x55

 int default_blu[] = {0x00,0x00,0x00,0x00,0xaa,0xaa,0xaa,0xaa,

     0x55,0x55,0x55,0x55,0xff,0xff,0xff,0xff};
+module_param_array(default_red, int, NULL, S_IRUGO | S_IWUSR);

+module_param_array(default_grn, int, NULL, S_IRUGO | S_IWUSR);

+module_param_array(default_blu, int, NULL, S_IRUGO | S_IWUSR);

+

 /*

  * gotoxy() must verify all boundaries, because the arguments

  * might also be negative. If the given position is out of

#<EOF>
-

I like this. The escape sequences to change the palette does not stay

permanently.
Tony
-

As much as you like it, there is a slight problem with it. Linux will

currently throw virtual consoles out of UTF8 mode when reset is called.
Also see:

	http://lkml.org/lkml/2005/5/17/289

	http://lkml.org/lkml/2005/5/17/297
These posts argue about terminfo being the culprit. But how can terminfo

be at fault, when `echo -en "\ec"` triggers it too?
Since I am in a patch mood, here's my stance/patch, which is compile and

run tested and behaves as expected (both with `echo` and `reset`).
Signed-off-by: Jan Engelhardt <jengelh@gmx.de>

Cc: Andrew Morton <akpm@osdl.org>

Cc: Daniel Jacobowitz <dan@debian.org>

Cc: Paul LeoNerd Evans <leonerd@leonerd.org.uk>

Obsoletes: https://bugzilla.novell.com/show_bug.cgi?id=225853
Index: linux-2.6.21-rc5/drivers/char/vt.c

===================================================================

--- linux-2.6.21-rc5.orig/drivers/char/vt.c

+++ linux-2.6.21-rc5/drivers/char/vt.c

@@ -1518,7 +1518,6 @@ static void reset_terminal(struct vc_dat

 	vc->vc_charset		= 0;

 	vc->vc_need_wrap	= 0;

 	vc->vc_report_mouse	= 0;

-	vc->vc_utf		= 0;

 	vc->vc_utf_count	= 0;
 	vc->vc_disp_ctrl	= 0;

#<EOF>

-

Should not reset actually reset terminal? This introduces

bug/unexpected behaviour...

							Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
Is it OK to do that? I recall when I was originally looking at the code

I didn't want to just remove that line, because it looked like that was

being used to first initialise the vc* structure when it is created, as

well as reset it every time. Doesn't this leave vc->vc_utf uninitialised

when a new VC is allocated?
--=20

Paul "LeoNerd" Evans
leonerd@leonerd.org.uk

ICQ# 4135350       |  Registered Linux# 179460

http://www.leonerd.org.uk/

That's true.  We can move the line vc->vc_utf = 0; in vc_init()

instead. 
Tony

While we're on that subject, did you take a look at my original mail?

The intent with that patch was to allow system policy to state all new

VCs are UTF-8-enabled by default. I feel that in 2007 this should be the

default setting.
Would it therefore be possible to have
   vc->vc_utf =3D some_default;
where some_default comes maybe from a sysctl or some other configurable

source? Or maybe even have a compiletime option?
This would get around many bugs. For example, on boot, "unicode_start"

can only set utf8 mode on the existing VCs 1 to 6. If X11 fails to

start, debian nicely runs me the XKeepsCrashing program, which offers to

show me logs and the like. It reads the locale, en_GB.UTF-8 and

determines we're in UTF-8 mode, so outputs Unicode linedrawing

characters for dialogs. Unfortunately, we're on VC7 which doesn't have

UTF-8 mode turned on, so much mess results.
It would be nice if the kernel's default UTF-8 mode for new VCs could be

synched to whatever local policy was regarding locale.
--=20

Paul "LeoNerd" Evans
leonerd@leonerd.org.uk

ICQ# 4135350       |  Registered Linux# 179460

http://www.leonerd.org.uk/

How about this? This should allow us to reset the terminal without

affecting utf, and also allows setting of a global utf default that can

be set via boot option or sysfs:
echo 1 > /sys/module/vt/parameters/default_utf

Might want to call it "default_utf8", but it's just minor.
Tony, if you have a patch, send it along so I can test it under "special local

circumstances" :-)
Jan

--

-

That's almost exactly what my suggestion was :)
(except that mine went into /proc/tty/vt/default_utf8_mode, but anywhere

is good really)
--=20

Paul "LeoNerd" Evans
leonerd@leonerd.org.uk

ICQ# 4135350       |  Registered Linux# 179460

http://www.leonerd.org.uk/

Tested and works here too.
Tony
-