* Re: [PATCH -v4] kbuild: Add extra gcc checks
From: Borislav Petkov @ 2011-03-01 14:56 UTC (permalink / raw)
To: Américo Wang
Cc: Arnd Bergmann, Sam Ravnborg, Michal Marek, torvalds, x86,
linux-kernel, Ingo Molnar, linux-kbuild, bp
In-Reply-To: <20110301132050.GA24374@cr0.private>
On Tue, Mar 01, 2011 at 09:20:50PM +0800, Américo Wang wrote:
> On Tue, Mar 01, 2011 at 12:35:00PM +0100, Arnd Bergmann wrote:
> >On Monday 28 February 2011, Borislav Petkov wrote:
> >> My intention was not to have multiple levels of warnings because then
> >> you have to go and enable the different levels and have to remember
> >> which level you used last, etc, etc.
> >
> >I wasn't suggesting more than two, so the two would have very distinct
> >definitions:
> >
> >W=1: Warnings that we would like to fix all over the tree, patches to
> > remove these are always welcome and you can build the entire kernel
> > with it. Once they are all fixed, we can make the warnings the default.
> >
> >W=2: Warnings that we know we don't always want to fix, meant for what
> > you describe here -- you build a single file and decide what to
> > do based on common sense.
> >
>
> Right, this makes sense. Borislav, could you implement this?
Yeah, I could try to come up with a sensible choice for mutual-exclusive
sets of -W.. options. Any preferences?
--
Regards/Gruss,
Boris.
^ permalink raw reply
* Re: [PATCH 2/4] ARM:boot:device tree: Merge specific atags into the device tree
From: Grant Likely @ 2011-03-01 14:56 UTC (permalink / raw)
To: Nicolas Pitre
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <alpine.LFD.2.00.1103010141140.10356-QuJgVwGFrdf/9pzu0YdTqQ@public.gmane.org>
On Mon, Feb 28, 2011 at 11:45 PM, Nicolas Pitre <nico-vtqb6HGKxmzR7s880joybQ@public.gmane.org> wrote:
> On Mon, 28 Feb 2011, John Bonesio wrote:
>
>> This patch is to merge in key atags into the appended device tree. An appended
>> device tree is where the zImage has a dtb binary appended at the end of it. The
>> boot code looks for an appended device tree, then looks for a few key atags
>> passed in by the bootloader.
>>
>> The bootargs and memory size settings, if they exist, override existing values
>> in the appended device tree. If these values don't currently exist in the
>> appended device tree, they are added.
>>
>> Signed-off-by: John Bonesio <bones-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
>
> Is this really useful?
>
> I understand this might be handy for testing purposes. But if your
> bootloader does ATAG only then your hardware is likely to have support
> in the kernel without device tree support just fine.
>
> IOW I don't think this would be of much value in upstream.
That's fine. This feature was implemented to meet a client's
requirement and to experiment with manipulating the .dtb in the zimage
wrapper. We're posting it here for completeness if anyone else wants
to play with it. Same for the last patch that allows appending
multiple dtbs.
g.
^ permalink raw reply
* [PATCH 2/4] ARM:boot:device tree: Merge specific atags into the device tree
From: Grant Likely @ 2011-03-01 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1103010141140.10356@xanadu.home>
On Mon, Feb 28, 2011 at 11:45 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Mon, 28 Feb 2011, John Bonesio wrote:
>
>> This patch is to merge in key atags into the appended device tree. ?An appended
>> device tree is where the zImage has a dtb binary appended at the end of it. The
>> boot code looks for an appended device tree, then looks for a few key atags
>> passed in by the bootloader.
>>
>> The bootargs and memory size settings, if they exist, override existing values
>> in the appended device tree. If these values don't currently exist in the
>> appended device tree, they are added.
>>
>> Signed-off-by: John Bonesio <bones@secretlab.ca>
>
> Is this really useful?
>
> I understand this might be handy for testing purposes. ?But if your
> bootloader does ATAG only then your hardware is likely to have support
> in the kernel without device tree support just fine.
>
> IOW I don't think this would be of much value in upstream.
That's fine. This feature was implemented to meet a client's
requirement and to experiment with manipulating the .dtb in the zimage
wrapper. We're posting it here for completeness if anyone else wants
to play with it. Same for the last patch that allows appending
multiple dtbs.
g.
^ permalink raw reply
* [PATCH 1/7] FIX: Verify Backup file name before reshape
From: Adam Kwolek @ 2011-03-01 14:56 UTC (permalink / raw)
To: neilb; +Cc: linux-raid, dan.j.williams, ed.ciechanowski, wojciech.neubauer
In-Reply-To: <20110301144932.10678.20916.stgit@gklab-128-013.igk.intel.com>
When reshape is continued backup_file is required for user data safety.
Grow_continue() has to verify if any file name is passed in.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
---
Grow.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/Grow.c b/Grow.c
index 47b8809..1470a91 100644
--- a/Grow.c
+++ b/Grow.c
@@ -3332,6 +3332,11 @@ int Grow_continue(int mdfd, struct supertype *st, struct mdinfo *info,
char *container = NULL;
int err;
+ if (backup_file == NULL) {
+ fprintf(stderr, Name ": Backup file name has to be specified "
+ "for reshape continuation.\n");
+ return 1;
+ }
if (!st->ss->external) {
err = sysfs_set_str(info, NULL, "array_state", "readonly");
if (err)
^ permalink raw reply related
* [PATCH] angstrom-jalimo.conf: Bump openjdk version to include security and build fixes
From: Stefan Schmidt @ 2011-03-01 14:55 UTC (permalink / raw)
To: openembedded-devel; +Cc: Stefan Schmidt
Signed-off-by: Stefan Schmidt <stefan@buglabs.net>
---
conf/distro/include/angstrom-jalimo.conf | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/conf/distro/include/angstrom-jalimo.conf b/conf/distro/include/angstrom-jalimo.conf
index 76cd5f1..9ba4c70 100644
--- a/conf/distro/include/angstrom-jalimo.conf
+++ b/conf/distro/include/angstrom-jalimo.conf
@@ -22,7 +22,7 @@ PREFERRED_VERSION_jamvm = "1.5.2"
PREFERRED_PROVIDER_swt3.4-gtk = "swt3.4-gtk"
PREFERRED_PROVIDER_classpath = "classpath"
-PREFERRED_VERSION_openjdk-6-jre = "6b18-1.8"
+PREFERRED_VERSION_openjdk-6-jre = "6b18-1.8.5"
PREFERRED_VERSION_icedtea6-native = "1.7.6"
# Stage JAR files not into ARCH related dirs
--
1.7.4.1
^ permalink raw reply related
* [PATCH 0/7] Grow_continue, use in assembly (cont.)
From: Adam Kwolek @ 2011-03-01 14:56 UTC (permalink / raw)
To: neilb; +Cc: linux-raid, dan.j.williams, ed.ciechanowski, wojciech.neubauer
The following series implements next part of resuming reshape from checkpoint.
In this series call to invoke reshape is included.
It is required to have backup file to run reshape, so backup file validation is added
(without checking in file system)
Array seams to be configured for reshape, monitor is blocked and doesn't makes changes
to process. On the end of reshape monitor unblock is placed also.
In patch:
Continue reshape after assembling array
some plans for supporting container operations is placed.
Reshape restoring is not working yet (a few more pathes are still required)
I hope some of therm I'll post tomorrow.
BR
Adam
---
Adam Kwolek (7):
FIX: array is frozen after reshape
Continue reshape after assembling array
FIX: Block monitor when starting array with reshape in progress
Add block_subarray()
FIX: configure disks slot for expansion
FIX: reshape in md should wait for monitoring process (external metadata)
FIX: Verify Backup file name before reshape
Assemble.c | 64 +++++++++++++++++++++++++++++++++++++++++++++------------
Grow.c | 15 ++++++++++++-
Incremental.c | 1 +
msg.c | 18 ++++++++++++----
msg.h | 2 ++
5 files changed, 81 insertions(+), 19 deletions(-)
--
Signature
^ permalink raw reply
* [Xenomai-help] SMP load balancing
From: Jeff Weber @ 2011-03-01 14:56 UTC (permalink / raw)
To: xenomai
[-- Attachment #1: Type: text/plain, Size: 1044 bytes --]
I am looking for guidance on how much I can rely upon the Linux kernel and
Xenomai schedulers to perform automatic load balancing, vs. how much I must
load balance manually. My config:
x86 SMP system with 2 CPUs
Linux 2.6.35.10 + xenomai-2.5.5.2
ISA hardware device with 1 IRQ
Xenomai kernel module driver using old-style native API (may be ported to
RTDM in the future)
user space application with multiple Linux and Xenomai threads
no effort [yet] to explicitly set CPU affinities for either Xenomai, nor
Linux
cat /proc/xenomai/affinity output = 000000ff
question: From /proc/xenomai/stat , I see all Xenomai kernel driver and
userspace threads running on only CPU0, though my IRQ handler is being
balanced on both CPUs. Will Xenomai ever "balance" or "migrate" threads to
other CPUs if the affinity mask allows this?
question: Does the Linux scheduler assume it owns 100% of the cycles on CPU0
(where all the Xenomai threads happen to be running), and thus make
incorrect scheduling decisions for Linux threads on CPU0?
thanks,
Jeff
[-- Attachment #2: Type: text/html, Size: 1126 bytes --]
^ permalink raw reply
* external udev rules which list devices
From: Johannes Meixner @ 2011-03-01 14:55 UTC (permalink / raw)
To: linux-hotplug
Hello,
in short:
I ask for an udev enhancement to make support for external
rules easier - in particular as a first step - support
for external listings of device IDs so that generic udev rules
could be applied to those devices.
Reasoning:
Currently udev rules which basically list devices which are
supported by external packages (usually peripheral devices)
so that a generic udev rule is applied to those devices
are in the external software packages which support the devices.
E.g. listings of USB vendor and product IDs for USB scanners
so that an ACL via udev's 70-acl.rules is applied.
Currently the scanner driver package sane-backends provides
its devices list as /etc/udev/rules.d/55-libsane.rules
and the package hplip for HP all-in-one devices provides
its devices list as /etc/udev/rules.d/55-hpmud.rules
In those device list rules the "libsane_matched" variable
is set to "yes" via entries like (long lines wrapped here):
-------------------------------------------------------------------
ACTION!="add", GOTO="libsane_rules_end"
SUBSYSTEMS="scsi", GOTO="libsane_scsi_rules_begin"
SUBSYSTEM="usb", GOTO="libsane_usb_rules_begin"
SUBSYSTEM!="usb", GOTO="libsane_usb_rules_end"
LABEL="libsane_usb_rules_begin"
...
# Epson GT-7700U | Epson Perfection 1240U | Epson Perfection 1240
ATTR{idVendor}="04b8", ATTR{idProduct}="010b", MODE="0664",
GROUP="lp", ENV{libsane_matched}="yes"
# Epson GT-6700U | Epson Perfection 640U | Epson Perfection 640
ATTR{idVendor}="04b8", ATTR{idProduct}="010c", MODE="0664",
GROUP="lp", ENV{libsane_matched}="yes"
...
LABEL="libsane_usb_rules_end"
SUBSYSTEMS!="scsi", GOTO="libsane_scsi_rules_end"
LABEL="libsane_scsi_rules_begin"
...
# Generic: SCSI device type 6 indicates a scanner
KERNEL="sg[0-9]*", ATTR{type}="6", MODE="0664", GROUP="lp",
ENV{libsane_matched}="yes"
# Some scanners advertise themselves as SCSI device type 3
# Epson Perfection 2450 | Epson Perfection 2450 PHOTO
KERNEL="sg[0-9]*", ATTR{type}="3", ATTR{vendor}="EPSON",
ATTR{model}="GT-9700", MODE="0664", GROUP="lp",
ENV{libsane_matched}="yes"
...
LABEL="libsane_scsi_rules_end"
LABEL="libsane_rules_end"
-------------------------------------------------------------------
Unfortunately the syntax of udev rules files and in particular the
values like event value, subsystem value, sysfs attribute values,
and device property values are not meant to be some kind
of "stable interface" so that external software could add
its own rules and rely on that this works "forever".
Regardless that the curent state seems to be pretty stable,
there is no guarantee and it might change in any udev release.
This results a dilemma:
On the one hand:
Because udev rules files are not meant as a "stable interface",
all udev rules files should be part of the udev package.
On the other hand:
If even the udev rules files which basically only list devices
would be part of the udev package, an upgrade of an external
software package to provides support for more external devices
would require an upgrade of udev to get an up-to-date list
of the new supported devices.
Therefore I ask for an udev enhancement to have a stable interface
so that external software packages could provide at least plain
list of devices to udev so that generic udev rules can be applied
to those devices.
There would have to be also a stable interface to specify
which particular generic udev rules should be applied.
Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex
^ permalink raw reply
* Re: [PATCH] perf lock: clean the options for perf record
From: Frederic Weisbecker @ 2011-03-01 14:55 UTC (permalink / raw)
To: Hitoshi Mitake
Cc: Peter Zijlstra, linux-kernel, h.mitake, Paul Mackerras,
Ingo Molnar, Arnaldo Carvalho de Melo, Steven Rostedt
In-Reply-To: <4D67E286.8010907@dcl.info.waseda.ac.jp>
On Sat, Feb 26, 2011 at 02:10:30AM +0900, Hitoshi Mitake wrote:
> It seems that I was too preprocessed with the method and
> forgot the purpose...
>
> Maybe the things like simple lockstat visualizer or
> special diff between two lockstat snapshots are
> useful for the first looking at big picture.
> I feel that they have worth to write and test.
Indeed they sound like good ideas. Being able to do a diff
on locks profiles would be useful to compare two changes on
the kernel.
^ permalink raw reply
* Re: [PATCH] btrfs file write debugging patch
From: Mitch Harder @ 2011-03-01 14:54 UTC (permalink / raw)
To: Zhong, Xin
Cc: Maria Wikström, Josef Bacik, Johannes Hirte, Chris Mason,
linux-btrfs@vger.kernel.org
In-Reply-To: <1865303E0DED764181A9D882DEF65FB68662A5EA7B@shsmsx502.ccr.corp.intel.com>
On Tue, Mar 1, 2011 at 5:56 AM, Zhong, Xin <xin.zhong@intel.com> wrote:
> Hi Mitch,
>
> I suspect there's a lock contention between flush-btrfs (lock_dellall=
oc_pages) and btrfs_file_aio_write. However I can not recreate it local=
ly. Could you please try below patch? Thanks!
>
> diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c index 65338a1..b9d0929=
100644
> --- a/fs/btrfs/file.c
> +++ b/fs/btrfs/file.c
> @@ -1007,17 +1007,16 @@ static ssize_t btrfs_file_aio_write(struct ki=
ocb *iocb,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto out;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
>
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 ret =3D btrfs_delalloc_reserve_space(in=
ode,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 num_pages << PAGE_CACHE_SHIFT);
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (ret)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
> -
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ret =3D prepare_pages(root, file, page=
s, num_pages,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
pos, first_index, last_index,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
write_bytes);
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (ret) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 btrfs_delalloc_release_=
space(inode,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (ret)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 ret =3D btrfs_delalloc_reserve_space(in=
ode,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0num_pages << PAGE_CACHE_SHIFT);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (ret) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 btrfs_drop_pages(pages,=
num_pages);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto out;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
>
>
Thanks.
I've tested this patch, but the build is still failing at the same
point as before.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1.8.0] add: make "add -u" update full tree without pathspec
From: Matthieu Moy @ 2011-03-01 14:53 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nguyen Thai Ngoc Duy, git, Sebastian Pipping, SZEDER Gábor,
Jeff King
In-Reply-To: <7vk4gkk5pd.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I already do not like the possibility of potential double deprecation
> myself, one to flip the default and then possibly another to drop the
> support of the traditional behavour, but anything I've seen so far would
> hurt the end users more than that plan.
I think promoting "git add -u ." more than a configuration option would
reduce the pain.
As a user, if I get used to typing "git add -u ." instead of "git add -u",
I get the current behavior regardless of the version of Git, without a
warning. Later, when all the machines I word on support the tree-wide
"git add -u" (either 1.7.x + some configuration or 1.8.y), I'll use it
as a new feature.
So, a warning like
warning: the behavior of "git add -u" without pathspec will change in
Git 1.8.0. To keep the current behavior, use this instead:
git add -u .
+ explanations about the config options as already discussed here
would be fine.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* linux-libc-headers do fetch Failed
From: saleh usman @ 2011-03-01 14:50 UTC (permalink / raw)
To: Openembedded Discussion
In-Reply-To: <BAY127-W1192DA5D5640002E5C3260D8DE0@phx.gbl>
Hi
I am building console-image and having problem while fetching liunx-libc-headers. Its giving an error of checksum mismatch. Kindly guide me how to resolve this issue.console log follows
NOTE: Running task 16 of 4329 (ID: 678, virtual:native:/oe/openembedded/recipes/linux-libc-headers/linux-libc-headers_2.6.31.bb, do_fetch)
NOTE: package linux-libc-headers-native-2.6.31-r6: task do_fetch: Started
FATAL: linux-libc-headers-native-2.6.31: http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.31.tar.bz2 cannot check archive integrity
ERROR: Error in executing python function in: /oe/openembedded/recipes/linux-libc-headers/linux-libc-headers_2.6.31.bb
ERROR: Exception:<type 'exceptions.SystemExit'> Message:1
ERROR: Printing the environment of the function
ERROR: Function base_do_fetch failed
ERROR: TaskFailed event exception, aborting
ERROR: Build of virtual:native:/oe/openembedded/recipes/linux-libc-headers/linux-libc-headers_2.6.31.bb do_fetch failed
NOTE: The checksums for '/oe/openembedded/sources/linux-2.6.31.tar.bz2' did not match.
Expected MD5: '84c077a37684e4cbfa67b18154390d8a' and Got: '9244b699b966804dfc2e243c89b3ead4'
Expected SHA256: '0acd83f7b85db7ee18c2b0b7505e1ba6fd722c36f49a8870a831c851660e3512' and Got: 'c522e06dc9639473f9962ed49b038ef5577e5d10cd2f4d9e4c62cdf3223de089'
NOTE: Your checksums:
SRC_URI[md5sum] = "9244b699b966804dfc2e243c89b3ead4"
SRC_URI[sha256sum] = "c522e06dc9639473f9962ed49b038ef5577e5d10cd2f4d9e4c62cdf3223de089"
FATAL: linux-libc-headers-native-2.6.31: http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.31.tar.bz2 cannot check archive integrity
Saelh Usman
^ permalink raw reply
* Re: SO_REUSEPORT - can it be done in kernel?
From: Eric Dumazet @ 2011-03-01 14:52 UTC (permalink / raw)
To: Thomas Graf
Cc: Herbert Xu, David Miller, rick.jones2, therbert, wsommerfeld,
daniel.baluta, netdev
In-Reply-To: <20110301143050.GB10761@canuck.infradead.org>
Le mardi 01 mars 2011 à 09:30 -0500, Thomas Graf a écrit :
> On Tue, Mar 01, 2011 at 09:22:35AM -0500, Thomas Graf wrote:
> > On Tue, Mar 01, 2011 at 03:06:59PM +0100, Eric Dumazet wrote:
> > > Would be nice to cpu affine named to _not_ run on CPU11, just to
> > > specialize it for TX completions and have softirq time percentage and
> > > "perf top -C 11 " results
>
> CPU 1 isolated as well (named running with mask 0,2-10)
>
> ----------------------------------------------------------------------------------------------------------------------
> PerfTop: 580 irqs/sec kernel:100.0% exact: 0.0% [1000Hz cpu-clock-msecs], (all, CPU: 1)
> ----------------------------------------------------------------------------------------------------------------------
>
> samples pcnt function DSO
> _______ _____ ___________________________ ___________________________________________________________
>
> 283.00 9.2% get_rx_page_info /lib/modules/2.6.38-rc5+/kernel/drivers/net/benet/be2net.ko
> 256.00 8.4% _raw_spin_unlock_irqrestore /lib/modules/2.6.38-rc5+/build/vmlinux
> 190.00 6.2% be_poll_rx /lib/modules/2.6.38-rc5+/kernel/drivers/net/benet/be2net.ko
> 182.00 5.9% get_page_from_freelist /lib/modules/2.6.38-rc5+/build/vmlinux
> 157.00 5.1% intel_idle /lib/modules/2.6.38-rc5+/build/vmlinux
> 143.00 4.7% __do_softirq /lib/modules/2.6.38-rc5+/build/vmlinux
> 133.00 4.3% sock_queue_rcv_skb /lib/modules/2.6.38-rc5+/build/vmlinux
> 133.00 4.3% __udp4_lib_lookup /lib/modules/2.6.38-rc5+/build/vmlinux
> 131.00 4.3% sk_run_filter /lib/modules/2.6.38-rc5+/build/vmlinux
sk_run_filter ? Do you have a packet filter running ?
^ permalink raw reply
* [Qemu-devel] Re: KVM call agend for Mar 1
From: Juan Quintela @ 2011-03-01 14:50 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm-devel
In-Reply-To: <m362s4l7hb.fsf@trasno.org>
Juan Quintela <quintela@redhat.com> wrote:
> Please send in any agenda items you are interested in covering.
As there are 0 items on the agenda, call got cancelled this week.
Enjoy, Juan.
> Thanks, Juan.
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: KVM call agend for Mar 1
From: Juan Quintela @ 2011-03-01 14:50 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm-devel
In-Reply-To: <m362s4l7hb.fsf@trasno.org>
Juan Quintela <quintela@redhat.com> wrote:
> Please send in any agenda items you are interested in covering.
As there are 0 items on the agenda, call got cancelled this week.
Enjoy, Juan.
> Thanks, Juan.
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 01/21]arch:arm:Kconfig remove one to many l's in the word.
From: Jiri Kosina @ 2011-03-01 14:52 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Justin P. Mattock, linux, linux-kernel
In-Reply-To: <20110228165530.GI20560@atomide.com>
On Mon, 28 Feb 2011, Tony Lindgren wrote:
> > The patch below removes an extra "l" in the word.
> >
> > Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
>
> Acked-by: Tony Lindgren <tony@atomide.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs, Novell Inc.
^ permalink raw reply
* Re: [Qemu-devel] 68k and BeBox (was SymbianOS, MeeGO, WebOS and QEMU)
From: Natalia Portillo @ 2011-03-01 14:51 UTC (permalink / raw)
To: François Revol; +Cc: Laurent Vivier, qemu-devel
In-Reply-To: <52D51874-95FA-40BB-9AA7-79FBBBFE6C92@free.fr>
Hi,
El 01/03/2011, a las 12:06, François Revol escribió:
>
> Le 1 mars 2011 à 13:02, Laurent Vivier a écrit :
>>>> Currently the fastest ones would be BeBox, Mac68k and NeXT machines, because almost all devices are already emulated, but the assembly itself, firmware and CPU/FPU/MMU in case of 68k.
>>>
>>> IIRC the Mac68k hardware is quite obscure and model-dependant...
>>> but EMILE and BasiliskII should say enough.
>>
>> They will not help you:
>> - EMILE uses Mac ROM to access hardware
>> - BasiliskII patches the ROM to call its internal drivers instead of
>> accessing hardware.
That's what MacOS itself does.
Indeed there is a document on how Mac OS X Server boots somewhere deep in the Apple's support page that describe the various patching methods they use to boot on m68k (for A/UX), OldWorld and NewWorld machines.
Remember that the Mac ROM, is the majority of the Mac OS APIs, that may be used or patched in RAM depending on the Mac OS version running.
vMac however is emulating the hardware more exactly.
>
>> If it can help I think I have all hardware reference manuals for m68k
>> macintosh.
>
> Actually I think they used to be online until recently, but Apple revamped their archived not too long ago IIRC.
For up to Mac II they are in the Inside Macintosh books, from them up to PowerPC you'll need to guess it, and for the cloneable systems, there is information in Apple Developer CDs.
Regards,
Natalia Portillo
^ permalink raw reply
* Re: Fwd: [PATCH]Maintain Chinese Documentations
From: Harry Wei @ 2011-03-01 14:51 UTC (permalink / raw)
To: jkosina; +Cc: akpm, joe, linux-kernel
In-Reply-To: <AANLkTi=00Otmr2kA5n_5tf_4ys385dyW+qBkTF0zRpQ3@mail.gmail.com>
On Tue, Mar 01, 2011 at 10:47:30PM +0800, jiaweiwei wrote:
> ---------- Forwarded message ----------
> From: Jiri Kosina <jkosina@suse.cz>
> Date: 2011/3/1
> Subject: Re: [PATCH]Maintain Chinese Documentations
> To: Harry Wei <jiaweiwei.xiyou@gmail.com>
> Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org, joe@perches.com,
> davem@davemloft.net, greg@kroah.com, rdunlap@xenotime.net
>
>
> On Wed, 16 Feb 2011, Harry Wei wrote:
>
> > I have translated some documentations of kernel so i want to
> > maintain Chinese documentation in our kernel directories.
>
> I don't see this in linux-next as of today, so I have picked it up.
Ok, thanks.
Best Regards.
Harry Wei.
>
> --
> Jiri Kosina
> SUSE Labs, Novell Inc.
>
>
>
> --
> do kernel
^ permalink raw reply
* Re: [PATCH] btrfs file write debugging patch
From: Mitch Harder @ 2011-03-01 14:51 UTC (permalink / raw)
To: Zhong, Xin
Cc: Maria Wikström, Josef Bacik, Johannes Hirte, Chris Mason,
linux-btrfs@vger.kernel.org
In-Reply-To: <1865303E0DED764181A9D882DEF65FB68662A5EA63@shsmsx502.ccr.corp.intel.com>
On Tue, Mar 1, 2011 at 4:14 AM, Zhong, Xin <xin.zhong@intel.com> wrote:
> Is your system running out of memory or is there any other thread like flush-btrfs competing for the same page?
>
There's no sign of memory pressure. Although I only have 1 GB in this
box, I'm still show ~1/2 GB RAM free during this build. There's no
swap space allocated, and nothing in dmesg that indicates there's a
transient spike of RAM pressure.
> I can only see one process in your ftrace log. You may need to trace all btrfs.ko function calls instead of a single process. Thanks!
>
That ftrace.log was run with ftrace defaults for a function trace. It
should collect calls from the whole system.
For the sake of consistency, I am intentionally trying to insure that
very few other things are going on at the same time as this build.
And I'm building with "-j1" so things will happen the same way each
time.
Also, I supplied just the tail end of the trace log. The full log
shows a few of the other build processes leading up to the problem,
but the ftrace ring buffer fills up surprisingly fast. Even with a
50MB ring buffer for ftrace, I usually collect less than 1 second of
information when something busy like a build is going on.
Let me know if you'd like to see the full log. It's bigger, but I can
find someplace to put it.
But I'm pretty sure that wmldbcreate is the only thing that is going
on when the breakage occurs. Otherwise I wouldn't get such consistent
breakage in the same spot every time.
^ permalink raw reply
* Re: [PATCH/alternative/raw and rough] setup.c: denote repo wide pathspecs by ':'
From: Junio C Hamano @ 2011-03-01 14:50 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Michael J Gruber, git
In-Reply-To: <AANLkTikzSsBZ757p4gnwsUrGNmRKHsxrqXeqPKyLihjT@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> No. ':foo' as a reference to 'foo' in index is a SHA1-extended syntax
> and I think we try to avoid ambiguation when a sha1-extended syntax
> may look like a path or vice versa.
Very true.
Just as a thought experiment (I am skeptical about this whole "this is
from root" prefix idea to begin with, but I don't want to shoot an idea
down prematurely when there may still be untold gems I haven't seen in
it):
$ git grep -e frotz .../
to abbreviate "I don't bother to count my ../" might be an alternative,
though.
The reason I am skeptical about the "from root prefix" is because I do not
see a way to make it compatible with other meaningful pathspecs.
$ cd Documentation
$ git grep -e frotz '*.txt'
would find frotz in all *.txt files in Documentation (and its
subdirectories), if the command takes "relatigve to cwd".
It also is very clear that
$ cd Documentation
$ git grep --full-tree -e frotz '*.txt'
would find those anywhere, inside or outside Documentation.
On the other hand, it is natural to expect that
$ git grep -e frotz ".../*.txt"
should find *.txt files _only_ at the root level, so it is not as useful as
the --full-tree (or --root).
^ permalink raw reply
* [PATCH] perf_events: update PEBS event constraints
From: Stephane Eranian @ 2011-03-01 13:50 UTC (permalink / raw)
To: linux-kernel
Cc: peterz, mingo, ming.m.lin, paulus, davem, fweisbec,
perfmon2-devel, eranian, eranian, robert.richter, acme
This patch updates PEBS event constraints for Intel Atom, Nehalem, Westmere.
This patch also reorganizes the PEBS format/constraint detection code. It is
now based on processor model and not PEBS format. Two processors may use the
same PEBS format without have the same list of PEBS events.
Signed-off-by: Stephane Eranian <eranian@google.com>
---
diff --git a/arch/x86/kernel/cpu/perf_event_intel_ds.c b/arch/x86/kernel/cpu/perf_event_intel_ds.c
index b7dcd9f..9b7ca73 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c
@@ -361,30 +361,49 @@ static int intel_pmu_drain_bts_buffer(void)
/*
* PEBS
*/
-
static struct event_constraint intel_core_pebs_events[] = {
PEBS_EVENT_CONSTRAINT(0x00c0, 0x1), /* INSTR_RETIRED.ANY */
PEBS_EVENT_CONSTRAINT(0xfec1, 0x1), /* X87_OPS_RETIRED.ANY */
PEBS_EVENT_CONSTRAINT(0x00c5, 0x1), /* BR_INST_RETIRED.MISPRED */
PEBS_EVENT_CONSTRAINT(0x1fc7, 0x1), /* SIMD_INST_RETURED.ANY */
- PEBS_EVENT_CONSTRAINT(0x01cb, 0x1), /* MEM_LOAD_RETIRED.L1D_MISS */
- PEBS_EVENT_CONSTRAINT(0x02cb, 0x1), /* MEM_LOAD_RETIRED.L1D_LINE_MISS */
- PEBS_EVENT_CONSTRAINT(0x04cb, 0x1), /* MEM_LOAD_RETIRED.L2_MISS */
- PEBS_EVENT_CONSTRAINT(0x08cb, 0x1), /* MEM_LOAD_RETIRED.L2_LINE_MISS */
- PEBS_EVENT_CONSTRAINT(0x10cb, 0x1), /* MEM_LOAD_RETIRED.DTLB_MISS */
+ INTEL_EVENT_CONSTRAINT(0xcb, 0x1), /* MEM_LOAD_RETIRED.* */
+ EVENT_CONSTRAINT_END
+};
+
+static struct event_constraint intel_atom_pebs_events[] = {
+ PEBS_EVENT_CONSTRAINT(0x00c0, 0x1), /* INSTR_RETIRED.ANY */
+ PEBS_EVENT_CONSTRAINT(0x00c5, 0x1), /* BR_INST_RETIRED.MISPRED */
+ PEBS_EVENT_CONSTRAINT(0x0ac4, 0x1), /* BR_INST_RETIRED.MISPRED */
+ INTEL_EVENT_CONSTRAINT(0xcb, 0x1), /* MEM_LOAD_RETIRED.* */
EVENT_CONSTRAINT_END
};
static struct event_constraint intel_nehalem_pebs_events[] = {
- PEBS_EVENT_CONSTRAINT(0x00c0, 0xf), /* INSTR_RETIRED.ANY */
- PEBS_EVENT_CONSTRAINT(0xfec1, 0xf), /* X87_OPS_RETIRED.ANY */
- PEBS_EVENT_CONSTRAINT(0x00c5, 0xf), /* BR_INST_RETIRED.MISPRED */
- PEBS_EVENT_CONSTRAINT(0x1fc7, 0xf), /* SIMD_INST_RETURED.ANY */
- PEBS_EVENT_CONSTRAINT(0x01cb, 0xf), /* MEM_LOAD_RETIRED.L1D_MISS */
- PEBS_EVENT_CONSTRAINT(0x02cb, 0xf), /* MEM_LOAD_RETIRED.L1D_LINE_MISS */
- PEBS_EVENT_CONSTRAINT(0x04cb, 0xf), /* MEM_LOAD_RETIRED.L2_MISS */
- PEBS_EVENT_CONSTRAINT(0x08cb, 0xf), /* MEM_LOAD_RETIRED.L2_LINE_MISS */
- PEBS_EVENT_CONSTRAINT(0x10cb, 0xf), /* MEM_LOAD_RETIRED.DTLB_MISS */
+ INTEL_EVENT_CONSTRAINT(0x0b, 0xf), /* MEM_INST_RETIRED.* */
+ INTEL_EVENT_CONSTRAINT(0x0f, 0xf), /* MEM_UNCORE_RETIRED.* */
+ PEBS_EVENT_CONSTRAINT(0x010c, 0xf), /* MEM_STORE_RETIRED.DTLB_MISS */
+ INTEL_EVENT_CONSTRAINT(0xc0, 0xf), /* INST_RETIRED.ANY */
+ INTEL_EVENT_CONSTRAINT(0xc2, 0xf), /* UOPS_RETIRED.* */
+ INTEL_EVENT_CONSTRAINT(0x00c4, 0xf),/* BR_INST_RETIRED.* */
+ PEBS_EVENT_CONSTRAINT(0x02c5, 0xf), /* BR_MISP_RETIRED.NEAR_CALL */
+ INTEL_EVENT_CONSTRAINT(0xc7, 0xf), /* SSEX_UOPS_RETIRED.* */
+ PEBS_EVENT_CONSTRAINT(0x20c8, 0xf), /* ITLB_MISS_RETIRED */
+ INTEL_EVENT_CONSTRAINT(0xcb, 0xf), /* MEM_LOAD_RETIRED.* */
+ EVENT_CONSTRAINT_END
+};
+
+static struct event_constraint intel_westmere_pebs_events[] = {
+ INTEL_EVENT_CONSTRAINT(0x0b, 0xf), /* MEM_INST_RETIRED.* */
+ INTEL_EVENT_CONSTRAINT(0x0f, 0xf), /* MEM_UNCORE_RETIRED.* */
+ PEBS_EVENT_CONSTRAINT(0x010c, 0xf), /* MEM_STORE_RETIRED.DTLB_MISS */
+ INTEL_EVENT_CONSTRAINT(0xc0, 0xf), /* INSTR_RETIRED.* */
+ INTEL_EVENT_CONSTRAINT(0xc2, 0xf), /* UOPS_RETIRED.* */
+
+ INTEL_EVENT_CONSTRAINT(0xc4, 0xf), /* BR_INST_RETIRED.* */
+ INTEL_EVENT_CONSTRAINT(0xc5, 0xf), /* BR_MISP_RETIRED.* */
+ INTEL_EVENT_CONSTRAINT(0xc7, 0xf), /* SSEX_UOPS_RETIRED.* */
+ PEBS_EVENT_CONSTRAINT(0x20c8, 0xf), /* ITLB_MISS_RETIRED */
+ INTEL_EVENT_CONSTRAINT(0xcb, 0xf), /* MEM_LOAD_RETIRED.* */
EVENT_CONSTRAINT_END
};
@@ -676,6 +695,55 @@ static void intel_pmu_drain_pebs_nhm(struct pt_regs *iregs)
* BTS, PEBS probe and setup
*/
+static void intel_ds_init_pebs_constraints(void)
+{
+ /*
+ * we only know hwo to deal with Family 6
+ */
+ if (boot_cpu_data.x86 != 6) {
+ x86_pmu.pebs = 0;
+ return;
+ }
+
+ switch (boot_cpu_data.x86_model) {
+ case 14: /* 65 nm core solo/duo, "Yonah" */
+ /* do not have PEBS */
+ x86_pmu.pebs = 0;
+ break;
+
+ case 15: /* original 65 nm celeron/pentium/core2/xeon, "Merom"/"Conroe" */
+ case 22: /* single-core 65 nm celeron/core2solo "Merom-L"/"Conroe-L" */
+ case 23: /* current 45 nm celeron/core2/xeon "Penryn"/"Wolfdale" */
+ case 29: /* six-core 45 nm xeon "Dunnington" */
+ x86_pmu.pebs_constraints = intel_core_pebs_events;
+ pr_cont("(Core2), ");
+ break;
+
+ case 26: /* 45 nm nehalem, "Bloomfield" */
+ case 30: /* 45 nm nehalem, "Lynnfield" */
+ case 46: /* 45 nm nehalem-ex, "Beckton" */
+ x86_pmu.pebs_constraints = intel_nehalem_pebs_events;
+ pr_cont("(Nehalem), ");
+ break;
+
+ case 28: /* Atom */
+ x86_pmu.pebs_constraints = intel_atom_pebs_events;
+ pr_cont("(Atom), ");
+ break;
+
+ case 37: /* 32 nm nehalem, "Clarkdale" */
+ case 44: /* 32 nm nehalem, "Gulftown" */
+ x86_pmu.pebs_constraints = intel_westmere_pebs_events;
+ pr_cont("(Westmere), ");
+ break;
+
+ default:
+ printk(KERN_CONT "PEBS not yet supported for model %d,",
+ boot_cpu_data.x86_model);
+ x86_pmu.pebs = 0;
+ }
+}
+
static void intel_ds_init(void)
{
/*
@@ -692,24 +760,24 @@ static void intel_ds_init(void)
switch (format) {
case 0:
- printk(KERN_CONT "PEBS fmt0%c, ", pebs_type);
+ printk(KERN_CONT "PEBS fmt0%c ", pebs_type);
x86_pmu.pebs_record_size = sizeof(struct pebs_record_core);
x86_pmu.drain_pebs = intel_pmu_drain_pebs_core;
- x86_pmu.pebs_constraints = intel_core_pebs_events;
break;
case 1:
- printk(KERN_CONT "PEBS fmt1%c, ", pebs_type);
+ printk(KERN_CONT "PEBS fmt1%c ", pebs_type);
x86_pmu.pebs_record_size = sizeof(struct pebs_record_nhm);
x86_pmu.drain_pebs = intel_pmu_drain_pebs_nhm;
- x86_pmu.pebs_constraints = intel_nehalem_pebs_events;
break;
default:
- printk(KERN_CONT "no PEBS fmt%d%c, ", format, pebs_type);
+ printk(KERN_CONT "no PEBS fmt%d%c\n",
+ format, pebs_type);
x86_pmu.pebs = 0;
- break;
+ return;
}
+ intel_ds_init_pebs_constraints();
}
}
^ permalink raw reply related
* Re: [PATCH] asm-generic/user.h: Fix spelling in comment
From: Jiri Kosina @ 2011-03-01 14:50 UTC (permalink / raw)
To: Tobias Klauser; +Cc: Arnd Bergmann, linux-arch, linux-kernel
In-Reply-To: <1298885542-6583-1-git-send-email-tklauser@distanz.ch>
On Mon, 28 Feb 2011, Tobias Klauser wrote:
> Fix two misspellings.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
> ---
> include/asm-generic/user.h | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/asm-generic/user.h b/include/asm-generic/user.h
> index 8b9c3c9..35638c3 100644
> --- a/include/asm-generic/user.h
> +++ b/include/asm-generic/user.h
> @@ -1,8 +1,8 @@
> #ifndef __ASM_GENERIC_USER_H
> #define __ASM_GENERIC_USER_H
> /*
> - * This file may define a 'struct user' structure. However, it it only
> - * used for a.out file, which are not supported on new architectures.
> + * This file may define a 'struct user' structure. However, it is only
> + * used for a.out files, which are not supported on new architectures.
> */
As this is not in linux-next-20110301, I have picked it up. Thanks,
--
Jiri Kosina
SUSE Labs, Novell Inc.
^ permalink raw reply
* [U-Boot] [PATCH 01/22] mkimage: Add OMAP boot image support
From: Aneesh V @ 2011-03-01 14:49 UTC (permalink / raw)
To: u-boot
In-Reply-To: <FCCFB4CDC6E5564B9182F639FC35608703707770E7@dbde02.ent.ti.com>
Hi Vaibhav,
On Tuesday 01 March 2011 07:54 PM, Bedia, Vaibhav wrote:
> Aneesh,
>
> On Monday, February 28, 2011 5:16 PM, V, Aneesh wrote:
>> From: John Rigby<john.rigby@linaro.org>
>>
>> Signed-off-by: John Rigby<john.rigby@linaro.org>
>> ---
>> common/image.c | 1 +
>> include/image.h | 1 +
>> tools/Makefile | 2 +
>> tools/mkimage.c | 2 +
>> tools/mkimage.h | 1 +
>> tools/omapimage.c | 229
>> +++++++++++++++++++++++++++++++++++++++++++++++++++++
>> tools/omapimage.h | 50 ++++++++++++ 7 files changed, 286
>> insertions(+), 0 deletions(-) create mode 100644
>> tools/omapimage.c create mode 100644 tools/omapimage.h
>
> As pointed in the RFC[1] which was posted by John, we should separate out the
> configuration header part as that is optional. We should also consider renaming
> it to make it generic. What do you think?
For OMAP4:
1. An 8 byte GP header is enough for booting from external MMC FAT
partition
2. A dummy CH with a dummy CHSETTINGS is essential for booting from
the RAW partition of eMMC or external MMC. This works for FAT
booting too.
3. A full configuration with proper CHSETTINGS and CHRAM will help us
in directly booting from SDRAM avoiding the SPL, but this is not
supported on all revisions of OMAP3/4
IMHO, let's have one image type(what John has created now) for (1) and
(2). It doesn't really harm to have 512 bytes of additional header
attached to your image when it makes it suitable for different types of
booting.
For 3, if that is supported in U-Boot in future, we will need a new
image type, maybe something like omapchimage.
Let me know if you had any special considerations for your SoC.
Best regards,
Aneesh
^ permalink raw reply
* [Qemu-devel] Re: [PATCH 0/2] ARM: Add Versatile Express board model
From: Amit Mahajan @ 2011-03-01 14:48 UTC (permalink / raw)
To: Peter Maydell
Cc: patches, qemu-devel, Bahadir Balban,
Dawid Ciężarkiewicz
In-Reply-To: <1298982742-31154-1-git-send-email-peter.maydell@linaro.org>
Thanks Peter for the efforts.
On Tue, 2011-03-01 at 12:32 +0000, Peter Maydell wrote:
> This patchset adds support for the ARM Versatile Express board
> with Cortex-A9 daughterboard. It's based on some vexpress modelling
> work done by Bahadir Balban and Amit Mahajan at B Labs, overhauled
> and cleaned up by me (thanks to them for making that work available).
>
> The patchset depends on the MMC cleanup work I posted last week:
> http://www.mail-archive.com/qemu-devel@nongnu.org/msg56148.html
> as it wants to wire up the MMC status lines.
>
> Peter Maydell (2):
> hw/arm_sysctl.c: Add the Versatile Express system registers
> hw/vexpress.c: Add model of ARM Versatile Express board
>
> Makefile.target | 1 +
> hw/arm_sysctl.c | 61 ++++++++++++++
> hw/vexpress.c | 238 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 300 insertions(+), 0 deletions(-)
> create mode 100644 hw/vexpress.c
>
--
Thanks
Amit Mahajan
^ permalink raw reply
* Re: Fwd: [PATCH 05/18] MAINTAINERS: Remove unnecessary linux-kernel@vger.kernel.org entries
From: Harry Wei @ 2011-03-01 14:47 UTC (permalink / raw)
To: broonie; +Cc: joe, akpm, linux-kernel
In-Reply-To: <AANLkTin2++GT3eRcTQeeqcB_1whedAt_0Hn+YY8y=v1s@mail.gmail.com>
On Tue, Mar 01, 2011 at 10:43:03PM +0800, jiaweiwei wrote:
> ---------- Forwarded message ----------
> From: Mark Brown <broonie@opensource.wolfsonmicro.com>
> Date: 2011/3/1
> Subject: Re: [PATCH 05/18] MAINTAINERS: Remove unnecessary
> linux-kernel@vger.kernel.org entries
> To: joe@perches.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org
>
>
> On Tue, Mar 01, 2011 at 10:10:30PM +0800, Harry Wei wrote:
>
> Please fix your MUA to word wrap within paragraphs.
I am so sorry, i will do.
>
> > I agree with Joe. I think any patch about kernel should be
> > emailed to LKML and other connection ML, as well as maintainers.
>
> You're missing my point. My point is that removing references to LKML
> from MAINTAINERS is working against this as it makes it harder for users
> to work out that they're supposed to do this.
Maybe you are right.
Thanks.
Best Regards.
Harry Wei.
> --
> 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/
>
>
>
> --
> do kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.