I'm trying to say "text size *and* config option is not set". That If it is so important for major kernel developer like you, Ingo, then why there's no scrollback at first place? Why nothing like that was not implemented up until now? My first ever Linux hack was changing default console output color. I think it was seven years ago. I though, it was not serious, if nobody did that already (in the 2.2.14). I added comment (like this), so anyone can skip reading body, if headers are "Ol...

Do you really think so? Yes, there are possibly LKML bots, that will read all messages in every thread. But i doubt they are humans. I also think, that kill-files and kill-names are common tools of the LKML readers. Thus, if someone sees my name with something like NAK in the subject, then nothing to worry about: next, please. I just amazed how inefficiently Subject, To, Cc headers are used. Everybody hurry through huge mail backlogs with subjects in thread all like one. Summary and keywords he...

Great idea! I've been experimenting with a new compat_dev_ioctl() function along the lines of what I just posted for the blkdev ioctls. For that, it would be perfect to streamline dev_ioctl further: * move the dev_load() and locking into dev_ifsioc{,_locked} * move the copy_to_user step to a single place at the end of dev_ioctl After that, we could have very simple dev_ioctl and compat_dev_ioctl functions calling the same dev_ifsioc{,_locked} functions. Arnd <>< -

Start with some old kernel, like mmm.. 2.6.0. The fact that same behaviour was present there may make you think about faulty assumptions you've -

Colored kernel message output (2/2) By popular request, this patch adds per-loglevel coloring. The user may set values using vt.printk_color= or by modifying the sysfs file in the running system. Signed-off-by: Jan Engelhardt <jengelh@gmx.de> --- arch/x86_64/kernel/early_printk.c | 11 +++++++---- drivers/char/Kconfig | 4 +++- drivers/char/vt.c | 32 ++++++++++++++++++++++++-------- drivers/net/netconsole.c | 3 ++- drivers/serial/825...

Well humm.. in an unmodified kernel, the last function that has knowledge of the loglevel is _call_console_drivers() in kernel/printk.c. From there, the call chain is directly -> __call_console_drivers() -> drivers/char/vt.c:vt_console_print(). _call_console_drivers() skips the <N> substring and passes on the rest of the message: if (msg_level < 0 && ((end - cur_index) > 2) && LOG_BUF(cur_index + 0) == '<' &a...

This is just as "bad" as the loglevel parameter. Because you'd have to parse str[0] in _every_ write() function. Furthermore, the string that is being printed also goes to klogd/syslog, including the <N> tag already. If you now add a color byte in the KERN_* macros, then (Paraphrased one paragraph above.) -

On Sat, 6 Oct 2007 22:09:52 +0200 (CEST) As the nearest thing to a tty maintainer I'd like to NAK this as "Silly" -

Colored kernel message output (1/2) 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. There is no way to disable this option. It would only add ugly ifdefs, and the default color is the one that vt.c used for all the past years anyway, so apart from the config option, nothing changes for the conservative user. References: http://lkml.org/lkml/2007/4/1/162 [ message continues ]

I assumed it was an interrupt issue based on the 'irq mepg' error, not a DMA issue. Any suggestions on how to log more information about PCI DMA events on a system wide basis? I've seen this since 2.6.18. -- Scott <linux-kernel@bluecamel.eml.cc> -

As found by sparse, a user space pointer is assigned to a kernel data structure while calling other code with set_fs(KERNEL_DS), which could lead to leaking kernel data if that pointer is ever accessed. I could not find any place in the floppy drivers that actually uses that pointer, but assigning it to an empty string is a safer choice and gets rid of the sparse warning. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Index: linux-2.6/block/compat_ioctl.c ===================================...

These are shared by all cd-rom drivers and should have common handlers. Do slight cosmetic cleanups in the process. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Index: linux-2.6/block/compat_ioctl.c =================================================================== --- linux-2.6.orig/block/compat_ioctl.c +++ linux-2.6/block/compat_ioctl.c @@ -92,6 +92,84 @@ static int compat_hdio_ioctl(struct inod return error; } +struct compat_cdrom_read_audio { + union cdrom_addr addr; + u8 ad...

This is my block ioctl series split up into managable chunks. I'm not really sure about the last two of these, I'd prefer to get a second opinion on those. Please apply once your tests have gone though. Arnd <>< -

Make compat_blkdev_ioctl and blkdev_ioctl reflect the respective native versions. This is somewhat more efficient and makes it easier to keep the two in sync. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Index: linux-2.6/block/Makefile =================================================================== --- linux-2.6.orig/block/Makefile +++ linux-2.6/block/Makefile @@ -11,3 +11,4 @@ obj-$(CONFIG_IOSCHED_DEADLINE) += deadli obj-$(CONFIG_IOSCHED_CFQ) += cfq-iosched.o obj-$(CONFIG_BLK_DEV...

Hmm, I'm not sure. They are modeled after the put_{short,int,uint,...} functions that only exist in block/ioctl.c and I put them in so I could use almost identical code in the native and compat path. If we find these generally useful, I guess we could have both versions of each of these functions in global headers, e.g. in linux/uaccess.h and linux/compat.h, but right now I would recommend using plain put_user in all compat code except for block ioctl. Arnd <>< -

Normally, all compat_ioctl operations are called without the BKL, the block device operations are an exception to this rule. Make this work the same as the other handlers. Signed-off-by: Arnd Bergmann <arnd@arndb.de> --- It would be good to find out whether it has been using the BKL on purpose or by accident, before this patch gets applied. Index: linux-2.6/block/compat_ioctl.c =================================================================== --- linux-2.6.orig/block/compat_ioctl....

Yes it's fixed by commit 176df2457 on 2007/09/21. It was CVE-2007-4573. Regards, Willy -

from: Gilles Gigan <gilles.gigan@bluebottle.com> Adds watchdog driver for EPIC Nano 7240 boards from IEI Signed-off-by: Gilles Gigan <gilles.gigan@bluebottle.com> --- diff -uprN -X linux-2.6.23-rc9/Documentation/dontdiff linux-2.6.23-rc9/drivers/char/watchdog/Kconfig linux-2.6.23-rc9-dirty/drivers/char/watchdog/Kconfig --- linux-2.6.23-rc9/drivers/char/watchdog/Kconfig 2007-10-06 01:43:44.000000000 +1000 +++ linux-2.6.23-rc9-dirty/drivers/char/watchdog/Kconfig 2007-10-06 14:49:03.00...

The 'fe-lock' branch of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git fe-lock contains the following changes that I would like to get tested: [netdrvr] forcedeth: make NAPI unconditional [netdrvr] forcedeth: interrupt handling cleanup [netdrvr] forcedeth: process TX completions using NAPI [netdrvr] forcedeth: internal simplification and cleanups [netdrvr] forcedeth: timer overhaul These are intended for feedback and testing, NOT for mergin...

It should also be pointed out that these patches were generated on top of davem's net-2.6.24.git tree. They -probably- apply to -mm, but you might have to remove the forcedeth patches -mm already has, before applying. -

commit 39572457a4dfe9a9dc1efd6641e7a6467e5658a1 Author: Jeff Garzik <jeff@garzik.org> Date: Sat Oct 6 01:21:01 2007 -0400 [netdrvr] forcedeth: internal simplification and cleanups * remove changelog from source; its kept in git repository * split guts of RX/TX DMA engine disable into disable portion, and wait/etc. portions. * consolidate descriptor version tests using nv_optimized() * consolidate NIC DMA start, stop and drain into ...

commit a606d2a111cdf948da5d69eb1de5526c5c2dafef Author: Jeff Garzik <jeff@garzik.org> Date: Fri Oct 5 22:56:05 2007 -0400 [netdrvr] forcedeth: interrupt handling cleanup * nv_nic_irq_optimized() and nv_nic_irq_other() were complete duplicates of nv_nic_irq(), with the exception of one function call. Consolidate all three into a single interrupt handler, deleting a lot of redundant code. * greatly simplify irq handler locking. Prior ...

The current Linux kernel currently contains the generate_random_uuid() function, which creates - based on RFC 4122 - truly random UUIDs and provides them to userspace through /proc/sys/kernel/random/boot_id and /proc/sys/kernel/random/uuid. The attached patch additionally adds the "Time-based UUID" variant of RFC 4122 to the Linux Kernel. With this patch applied, userspace applications may easily get real unique time-based UUIDs through /proc/sys/kernel/random/uuid_time. The attached implementation ...

This patch fixes the DMA cascade by masking the correct bits. Tested and working with Dreamcast PVR2 DMA. With this patch applied the existing mainline code in arch/sh/drivers/dma/dma-sh.c works, whereas before I was patching that to get round this problem. Signed-off by: Adrian McMenamin <adrian@mcmen.demon.co.uk> diff --git a/include/asm-sh/cpu-sh4/dma.h b/include/asm-sh/cpu-sh4/dma.h index 36e26a9..aaf71b0 100644 --- a/include/asm-sh/cpu-sh4/dma.h +++ b/include/asm-sh/cpu-sh4/dma.h @...

-