twitter: linux.kernel - 26 new messages in 23 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

* allow retrieving entries with trailing dots - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/57d334aba1b16975?hl=en
* [GIT PULL] tracing: updates and fixes - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/2e1c72230f9c9abe?hl=en
* perf: Make printing table easily - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/1998ab7170f94457?hl=en
* perf: Make the install relative to DESTDIR if specified - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/ef7de55975f148b0?hl=en
* RAID + LUKS + LVM performance - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/43ac9c2556338695?hl=en
* USB: musb: fix build error introduced by isoc change - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/caa6f1b865b9da32?hl=en
* TCPCT part 2g: parse cookie pair and 64-bit timestamp - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c35ca27b143f9a64?hl=en
* ATA 4 KiB sector issues. - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/94d9b232ec44429a?hl=en
* Reposting: [PATCH v1] serial: Add OMAP high-speed UART driver. - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/9800da1317981df4?hl=en
* Group scheduler statistics in one struct - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/13c9b10b958af9d6?hl=en
* fix-taskstates-in-sched_switch-trace.patch - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/247a0ea55998c933?hl=en
* tracing: Fix erroneous task states in sched_switch event - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/826c856bbfdb4ff9?hl=en
* OPTPROBES: Don't default to y in Kconfig - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/5b3f23e449969437?hl=en
* weirdness with compiling a 2.6.33 kernel on arm debian - 2 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/73c443f96a3243ef?hl=en
* ZTE MF636 USB modem is not supported - 3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/670a7642716afea4?hl=en
* x86, k8 nb: Enable k8_northbridges unconditionally on AMD - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/23fd80db0655edba?hl=en
* Fix Readahead stalling by plugged device queues - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f6c8a91865f18ec5?hl=en
* x86: increase CONFIG_NODES_SHIFT max to 10 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/3f99a3f0c3aab026?hl=en
* bit errors on spitz - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/32584eab7e27d325?hl=en
* Congratulations! - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/7861dac5abc8dc25?hl=en
* Race condition in TTY ldisc layer in 2.6.33 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/0dd856e75c9c2098?hl=en
* 2.6.34-rc1: rcu lockdep bug? - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/20ae452eb2399ce9?hl=en
* arch/microblaze fixes for 2.6.34-rc2 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/cba3042b03f99359?hl=en

==============================================================================
TOPIC: allow retrieving entries with trailing dots
http://groups.google.com/group/linux.kernel/t/57d334aba1b16975?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Mar 11 2010 4:50 am
From: OGAWA Hirofumi

Philippe De Muyter <phdm@macqel.be> writes:

>> > This is unavoidable.
>
> We could perhaps reduce the disadvantage by moving the logic (test first
> with the trailing dots, and then without if needed) into fat_search_long
> instead of putting it in vfat_find as my patch proposal does. This way
> the name to find would only be compared once to unrelated entries,
> instead of possibly twice as my patch does.
>
> But therefore I need your help : fat_search_long isn't easy to read/modify.
>
> The logic could be modified as such :
> - if the searched name contains trailing dots, first compare
> the truncated part to the same length of the directory entry
> - if they are the same, test the length of the rest of the directory entry
> - if length_of_rest is 0, this could be the matching entry,
> but there could be a better one later; keep searching till the end.
> - if length_of_rest is not 0, compare the rest with the trailing dots
> - if rests are equal, we have found it; return
> - if rests are unequal, continue searching
>
>>
>> We would be able to introduce new mount option to do it if needed.
>
> A new mount option should be the last programming option. It is better to
> automatically do the right thing than to require the user to figure out
> he must add a mount option in /etc/fstab or whatever. Remember this is
> for hot-plug disks.

Sorry, but I'm not thinking this is primary one. So, requiring option
for it to avoid disadvantage of normal users, it sounds good.

>> This changed vfat_find(), so, this patch will change the behavior of all
>> callers more or less. And the behavior seems to be really strange, you
>> can remove "a.", but you can't create it?
>
> Yes, you can remove any existing file, but if you want to create a file,
> the name creation rules are kept unchanged. So, creating "a." will
> succeed, it will actually be called "a" on disk, but you can still refer
> to it as "a." : that will succeed. That's the strange part of the behavior
> but that part is already present for compatibility reasons nor you nor me
> can do anything about :(
>
>> The behavior sounds random, right?
>
> It's a compromise to avoid creating name entries that are not universally
> accepted, but to allow accessing existing files and directories.
>
> The mount option could be useful then to allow the creation of file and
> directory names with trailing dot, but consistency between getdents and
> stat/open must be automatic.

No, this breaks consistency. With this patch, unlink("a."), then
open("a.", O_CREAT) and write(), the result depend on existent
files. This patch is providing two files on one name.

Thanks.
--
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: [GIT PULL] tracing: updates and fixes
http://groups.google.com/group/linux.kernel/t/2e1c72230f9c9abe?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Mar 11 2010 4:50 am
From: Ingo Molnar

* Steven Rostedt <rostedt@goodmis.org> wrote:

> Ingo,
>
> Please pull the latest tip/tracing/core tree, which can be found at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
> tip/tracing/core
>
>
> Arnaldo Carvalho de Melo (1):
> tracing: Update the comm field in the right variable in update_max_tr
>
> Steven Rostedt (2):
> function-graph: Fix unused reference to ftrace_set_func()
> function-graph: Use comment notation for func names of dangling '}'
>
> Tim Bird (1):
> function-graph: Add tracing_thresh support to function_graph tracer
>
> ----
> kernel/trace/ftrace.c | 6 ++----
> kernel/trace/trace.c | 24 ++++++++++++++++++++----
> kernel/trace/trace.h | 3 ++-
> kernel/trace/trace_functions_graph.c | 27 ++++++++++++++++++++++++---
> 4 files changed, 48 insertions(+), 12 deletions(-)

Pulled, thanks Steve!

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: perf: Make printing table easily
http://groups.google.com/group/linux.kernel/t/1998ab7170f94457?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Mar 11 2010 5:00 am
From: Ingo Molnar

* Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp> wrote:

> Hi,
>
> Making table of matrix by printf is painful work,
> but it can be found in perf here and there.
> So I'd like to propose semi-automation of making table.
> New files util/table.c provides stuffs for easy table printing.

Looks quite reasonable in theory. I suspect it would be useful to see a few
table printing places converted to this facility, to see the simplification
factor in practice.

==============================================================================
TOPIC: perf: Make the install relative to DESTDIR if specified
http://groups.google.com/group/linux.kernel/t/ef7de55975f148b0?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Mar 11 2010 5:00 am
From: John Kacur

Without this change, the install path is relative to
prefix/DESTDIR
where prefix is automatically set to $HOME

This can produce unexpected results. For example

make -C tools/perf DESTDIR=/home/jkacur/tmp install-man

creates the directory: /home/jkacur/home/jkacur/tmp/share/...
instead of the expected: /home/jkacur/tmp/share/...

Signed-off-by: John Kacur <jkacur@redhat.com>
---
tools/perf/Documentation/Makefile | 4 +++-
tools/perf/Makefile | 4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/tools/perf/Documentation/Makefile b/tools/perf/Documentation/Makefile
index bdd3b7e..bd498d4 100644
--- a/tools/perf/Documentation/Makefile
+++ b/tools/perf/Documentation/Makefile
@@ -24,7 +24,10 @@ DOC_MAN1=$(patsubst %.txt,%.1,$(MAN1_TXT))
DOC_MAN5=$(patsubst %.txt,%.5,$(MAN5_TXT))
DOC_MAN7=$(patsubst %.txt,%.7,$(MAN7_TXT))

+# Make the path relative to DESTDIR, not prefix
+ifndef DESTDIR
prefix?=$(HOME)
+endif
bindir?=$(prefix)/bin
htmldir?=$(prefix)/share/doc/perf-doc
pdfdir?=$(prefix)/share/doc/perf-doc
@@ -32,7 +35,6 @@ mandir?=$(prefix)/share/man
man1dir=$(mandir)/man1
man5dir=$(mandir)/man5
man7dir=$(mandir)/man7
-# DESTDIR=

ASCIIDOC=asciidoc
ASCIIDOC_EXTRA = --unsafe
diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index 2d53738..5da0cd0 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -216,7 +216,10 @@ STRIP ?= strip
# runtime figures out where they are based on the path to the executable.
# This can help installing the suite in a relocatable way.

+# Make the path relative to DESTDIR, not to prefix
+ifndef DESTDIR
prefix = $(HOME)
+endif
bindir_relative = bin
bindir = $(prefix)/$(bindir_relative)
mandir = share/man
@@ -233,7 +236,6 @@ sysconfdir = $(prefix)/etc
ETC_PERFCONFIG = etc/perfconfig
endif
lib = lib
-# DESTDIR=

export prefix bindir sharedir sysconfdir

--
1.6.6.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: RAID + LUKS + LVM performance
http://groups.google.com/group/linux.kernel/t/43ac9c2556338695?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Mar 11 2010 5:10 am
From: Mathias Buren

Hi,

(please cc me as I'm not subscribed)

I've a friend who's going to set up a fileserver consisting of 8x 1.5TB
HDDs, an 8-port PCI-E RAID card (Areca ARC-1220 @
http://www.areca.com.tw/products/pcie.htm ) etc.
The plan is create a RAID5 array spanning all the disks, then create 4
partitions. These 4 partitions would be encrypted using LUKS (Twofish or
AES256).
These 4 encrypted partition would be set up in RAID0 using Linux' software
(mdadm), then LVM would be used on top of that (one big PV, one big VG and
a big LV or so).

The reason for this is that kcryptd is not multithreaded (afaik). By having
4 encrypted partitions, then md0 on top of them, I'm forcing 4 kcryptd
processes to run on all four cpu cores whenever something is written to the
disks, which should improve (encryption) performance.

Is this a good way of doing it, or is there a smarter way?

Regards,

Mathias,

==============================================================================
TOPIC: USB: musb: fix build error introduced by isoc change
http://groups.google.com/group/linux.kernel/t/caa6f1b865b9da32?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Mar 11 2010 5:10 am
From: Felipe Balbi

On Mon, Mar 08, 2010 at 05:26:01PM +0100, ext Mike Frysinger wrote:
>From: Sonic Zhang <sonic.zhang@analog.com>
>
>The recent commit "usb: musb: Fix for isochronous IN transfer" (f82a689fa)
>seems to have been against an older kernel version. It uses the old style
>naming of variables. Unfortunately, this breaks building for most MUSB
>users out there since "bDesiredMode" has been renamed to "desired_mode".
>
>Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
>Signed-off-by: Mike Frysinger <vapier@gentoo.org>

applied, thanks

--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: TCPCT part 2g: parse cookie pair and 64-bit timestamp
http://groups.google.com/group/linux.kernel/t/c35ca27b143f9a64?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Mar 11 2010 5:10 am
From: William Allen Simpson

Every bit is sacred. Use as few bits as possible in tcp_options_received.
Group related timestamp flag bits for cache line memory efficiency.

Fix #define spacing for TCP options.

Define and parse 64-bit timestamp extended option (and minor cleanup).
However, only 32-bits are used at this time (permitted by specification).

Parse cookie pair extended option (previously defined).

Handle header extension.

Fix initialization in tcp_minisocks.

[updated to latest posted internet draft-simpson-tcpct-00]

Requires:
net: tcp_header_len_th and tcp_option_len_th
TCPCT part 2f: cleanup tcp_parse_options

Signed-off-by: William.Allen.Simpson@gmail.com
---
include/linux/tcp.h | 12 ++++-
include/net/tcp.h | 45 ++++++++--------
net/ipv4/tcp_input.c | 127 ++++++++++++++++++++++++++++++++++++++++++----
net/ipv4/tcp_minisocks.c | 6 ++
4 files changed, 155 insertions(+), 35 deletions(-)

==============================================================================
TOPIC: ATA 4 KiB sector issues.
http://groups.google.com/group/linux.kernel/t/94d9b232ec44429a?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Mar 11 2010 5:20 am
From: Theodore Tso

On Mar 10, 2010, at 11:19 AM, Damian Lukowski wrote:
>
> I have practically no knowledge of Linux' block device drivers,
> but is this really a partitioning issue? I think the problem is
> with the filesystems when clustering multiple blocks without
> knowledge of the sector alignment and sector size of the underlying
> block device. Maybe it is a better solution to adapt the filesystem
> buffer routine which reads/writes data from/to the block device?

No, it's really a partitioning issue. If the paging subsystem wants a 4k block to fill a particular page, we need to read that 4k block into memory. If we need to swap out that 4k block, we need to write that 4k block to swap space, or to the memory segment's backing store. If the partition is misaligned by 512 bytes, this is simply not possible. The file system has to do what is requested of it by its users, and the reality is that we need to do 4k aligned reads and writes with respect to the beginning of the partition, far more often than not.

Hence, if we want the best performance on 4k sector drives, the partition needs to be aligned with respect to what is most desirable for the device in question.

Best regards,

-- Ted

==============================================================================
TOPIC: Reposting: [PATCH v1] serial: Add OMAP high-speed UART driver.
http://groups.google.com/group/linux.kernel/t/9800da1317981df4?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Mar 11 2010 5:20 am
From: "Govindraj.R"

Hi Greg,

Could you please have this patch into your tty tree now?

As I do not see any further comment in community on this
for quite long time now.

--
Regards,
Govindraj.R

> This time CC'ing Linux-serial and LKML too, forgot last time.
>
> --
> Govindraj.R
>
>
> This patch adds driver support for OMAP3/4 high speed UART.
>
> This driver is made separate from 8250 driver as we cannot
> over load 8250 driver with omap platform specific configuration for
> features like DMA, it makes easier to implement features like DMA and
> hardware flow control and software flow control configuration with
> this driver as required for the omap-platform.
>
> This patch involves only the core driver and its dependent.
> This patch doesn't incorporate platform specific data as this will be
> posted from linux-omap tree and this driver was tested with Kevins PM
> branch which currently hosts the omap-serial platform data which utilises
> the omap-hwmod framework.
>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: Alan Cox <alan@linux.intel.com>
> Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
> Signed-off-by: Govindraj R <govindraj.raja@ti.com>
> ---
> arch/arm/plat-omap/include/plat/omap-serial.h | 128 +++
> drivers/serial/Kconfig | 27 +
> drivers/serial/Makefile | 1 +
> drivers/serial/omap-serial.c | 1316 +++++++++++++++++++++++++
> include/linux/serial_core.h | 3 +
> 5 files changed, 1475 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/plat-omap/include/plat/omap-serial.h
> create mode 100644 drivers/serial/omap-serial.c
>
> diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
> b/arch/arm/plat-omap/include/plat/omap-serial.h
> new file mode 100644
> index 0000000..2a1e7f9
> --- /dev/null
> +++ b/arch/arm/plat-omap/include/plat/omap-serial.h
> @@ -0,0 +1,128 @@
> +/*
> + * Driver for OMAP-UART controller.
> + * Based on drivers/serial/8250.c
> + *
> + * Copyright (C) 2010 Texas Instruments.
> + *
> + * Authors:
> + * Govindraj R <govindraj.raja@ti.com>
> + * Thara Gopinath <thara@ti.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#ifndef __OMAP_SERIAL_H__
> +#define __OMAP_SERIAL_H__
> +
> +#include <linux/serial_core.h>
> +#include <linux/platform_device.h>
> +
> +#include <plat/control.h>
> +#include <plat/mux.h>
> +
> +#define DRIVER_NAME "omap-hsuart"
> +
> +/*
> + * Use tty device name as ttyO, [O -> OMAP]
> + * in bootargs we specify as console=ttyO0 if uart1
> + * is used as console uart.
> + */
> +#define OMAP_SERIAL_NAME "ttyO"
> +
> +#define OMAP_MDR1_DISABLE 0x07
> +#define OMAP_MDR1_MODE13X 0x03
> +#define OMAP_MDR1_MODE16X 0x00
> +#define OMAP_MODE13X_SPEED 230400
> +
> +/*
> + * LCR = 0XBF: Switch to Configuration Mode B.
> + * In configuration mode b allow access
> + * to EFR,DLL,DLH.
> + * Reference OMAP TRM Chapter 17
> + * Section: 1.4.3 Mode Selection
> + */
> +#define OMAP_UART_LCR_CONF_MDB 0XBF
> +
> +/* WER = 0x7F
> + * Enable module level wakeup in WER reg
> + */
> +#define OMAP_UART_WER_MOD_WKUP 0X7F
> +
> +/* Enable XON/XOFF flow control on output */
> +#define OMAP_UART_SW_TX 0x04
> +
> +/* Enable XON/XOFF flow control on input */
> +#define OMAP_UART_SW_RX 0x04
> +
> +#define OMAP_UART_SYSC_RESET 0X07
> +#define OMAP_UART_TCR_TRIG 0X0F
> +#define OMAP_UART_SW_CLR 0XF0
> +
> +#define OMAP_UART_DMA_CH_FREE -1
> +
> +#define RX_TIMEOUT (3 * HZ)
> +#define OMAP_MAX_HSUART_PORTS 4
> +
> +#define MSR_SAVE_FLAGS UART_MSR_ANY_DELTA
> +
> +struct omap_uart_port_info {
> + bool dma_enabled; /* To specify DMA Mode */
> + unsigned int uartclk; /* UART clock rate */
> + void __iomem *membase; /* ioremap cookie or NULL */
> + resource_size_t mapbase; /* resource base */
> + unsigned long irqflags; /* request_irq flags */
> + upf_t flags; /* UPF_* flags */
> +};
> +
> +struct uart_omap_dma {
> + u8 uart_dma_tx;
> + u8 uart_dma_rx;
> + int rx_dma_channel;
> + int tx_dma_channel;
> + dma_addr_t rx_buf_dma_phys;
> + dma_addr_t tx_buf_dma_phys;
> + unsigned int uart_base;
> + /*
> + * Buffer for rx dma.It is not required for tx because the buffer
> + * comes from port structure.
> + */
> + unsigned char *rx_buf;
> + unsigned int prev_rx_dma_pos;
> + int tx_buf_size;
> + int tx_dma_used;
> + int rx_dma_used;
> + spinlock_t tx_lock;
> + spinlock_t rx_lock;
> + /* timer to poll activity on rx dma */
> + struct timer_list rx_timer;
> + int rx_buf_size;
> + int rx_timeout;
> +};
> +
> +struct uart_omap_port {
> + struct uart_port port;
> + struct uart_omap_dma uart_dma;
> + struct platform_device *pdev;
> +
> + unsigned char ier;
> + unsigned char lcr;
> + unsigned char mcr;
> + unsigned char fcr;
> + unsigned char efr;
> +
> + int use_dma;
> + /*
> + * Some bits in registers are cleared on a read, so they must
> + * be saved whenever the register is read but the bits will not
> + * be immediately processed.
> + */
> + unsigned int lsr_break_flag;
> + unsigned char msr_saved_flags;
> + char name[20];
> + unsigned long port_activity;
> +};
> +
> +

twitter

Thursday, March 11, 2010

linux.kernel - 26 new messages in 23 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts