* Re: [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit
From: Greg KH @ 2009-06-03 3:35 UTC (permalink / raw)
To: Robert Schwebel
Cc: James Bottomley, linux-arch, linux-embedded, David VomLehn,
Josh Boyer, Tim Bird, ksummit-2009-discuss
In-Reply-To: <20090602213452.GK32630@pengutronix.de>
On Tue, Jun 02, 2009 at 11:34:52PM +0200, Robert Schwebel wrote:
> Could flickerfree-bootsplash be a topic? Or is that completely pushed
> into the userspace these fastboot days?
We have that working today, no in-kernel work needed other than the
already-present KMS stuff. See the recent Moblin images for proof of
this.
thanks,
greg k-h
^ permalink raw reply
* Re: [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit
From: Steven Rostedt @ 2009-06-03 1:42 UTC (permalink / raw)
To: David VomLehn
Cc: James Bottomley, linux-arch, Josh Boyer, Tim Bird, linux-embedded,
ksummit-2009-discuss
In-Reply-To: <20090603000312.GA21055@cuplxvomd02.corp.sa.net>
On Tue, 2 Jun 2009, David VomLehn wrote:
> On Tue, Jun 02, 2009 at 03:37:44PM -0500, James Bottomley wrote:
> Our failure report includes things you'd expect as well as various pieces
> of history, such as:
> o IRQs
> o softirq dispatches (including max times)
> o selected /proc info, e.g. /proc/meminfo
>
> We also report info on the current thread, like backtracing and
> /proc/<pid>/maps, though I'm not sure it's as useful as it might be.
>
> Though I'm working on pushing this stuff out, other things that might be
> helpful are:
> o If you get to panic() by way of die(), you've lost the registers passed to
> die(). We save a pointer off, but it's really a kludge.
> o The implementation of die() varies from platform to platform and isn't even
> called die() everywhere.
> o It is truly nasty trying to get /proc information when you are in a panic
> situation--any semaphores being held are not going to be released, so you
> have to duplicate a lot of the code, minus the semaphores. Pretty gross
> and there is no way our implementation will be acceptable.
> o Increased reporting on what's happening in user/kernel space interaction.
> For example, a signal sent in good faith might kill a buggy process. It
> would be helpful to log signals that result in a process' death.
> o Then there is more speculative stuff. For example, your caches would
> have a copy of the most recently accessed code and data. If your
> processor supports dumping cache, it might help determing what went wrong.
If your system is hooked up to a serial console, another helpful thing to
do is to pass in "ftrace_dump_on_oops" in the command line and also keep
the event tracer running, where you enable just the events you are
interested in. Then if the system crashes, it will dump out the ftrace
buffer to the console, which could be logged by a serial console and then
you at least have a trace of the events that lead up to the crash.
The event tracer while active is not that much overhead and could be
enabled in a production system.
-- Steve
^ permalink raw reply
* Re: [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit
From: Eric W. Biederman @ 2009-06-03 0:52 UTC (permalink / raw)
To: David VomLehn
Cc: James Bottomley, linux-arch, Josh Boyer, Tim Bird, linux-embedded,
ksummit-2009-discuss
In-Reply-To: <20090603000312.GA21055@cuplxvomd02.corp.sa.net>
David VomLehn <dvomlehn@cisco.com> writes:
> On Tue, Jun 02, 2009 at 03:37:44PM -0500, James Bottomley wrote:
> ...
>> This is what made us suggest the presentation driven approach. We can
>> send people who understand how the kernel development process out
>> anointed as embedded maintainers. However, looking at the arch
>> directory, you have a ton of new kids on the block. We wondered if,
>> perhaps, rather than having seasoned kernel developers reach out to the
>> embedded community, we might try giving the embedded community the
>> opportunity to reach out to us. The topic of "flattened device tree"
>> look interesting to me (perhaps because I'm a hardened device driver
>> person and things like that always look interesting to me) ... if we can
>> get a few more like that out of the woodwork, this approach might end up
>> being successful.
>
> Failure reporting is the one area where embedded applications have
> little overlap with other Linux application domains. The cable settop box
> environment has:
> o Limited peristent storage
> o Low or no upstream bandwidth
> o Little access to hundreds of thousands of devices in the field
>
> When a kernel panics in the field, we have no place to put a core dump
> and, if we had a place to put it, it would take way too long to upload
> it when the box comes back up. And most people just don't understand when
> you knock at their door at midnight, JTAG probe in hand.
>
> We hook in a panic notifier and have it generate a really rich report.
> At present, this report stays in memory until we reboot and send it
> upstream (or write it to flash), but we could really write it to any
> device with which we can use polled I/O (interrupts being questionable
> at this point). Generic interfaces to support this would be useful.
>
> Many embedded devices have highly integrated stacks, so failures in user
> space lead to device reboots, and you want to leverage much of the same
> ability to store and send failure reports.
>
> Our failure report includes things you'd expect as well as various pieces
> of history, such as:
> o IRQs
> o softirq dispatches (including max times)
> o selected /proc info, e.g. /proc/meminfo
>
> We also report info on the current thread, like backtracing and
> /proc/<pid>/maps, though I'm not sure it's as useful as it might be.
>
> Though I'm working on pushing this stuff out, other things that might be
> helpful are:
> o If you get to panic() by way of die(), you've lost the registers passed to
> die(). We save a pointer off, but it's really a kludge.
> o The implementation of die() varies from platform to platform and isn't even
> called die() everywhere.
> o It is truly nasty trying to get /proc information when you are in a panic
> situation--any semaphores being held are not going to be released, so you
> have to duplicate a lot of the code, minus the semaphores. Pretty gross
> and there is no way our implementation will be acceptable.
> o Increased reporting on what's happening in user/kernel space interaction.
> For example, a signal sent in good faith might kill a buggy process. It
> would be helpful to log signals that result in a process' death.
> o Then there is more speculative stuff. For example, your caches would
> have a copy of the most recently accessed code and data. If your
> processor supports dumping cache, it might help determing what went wrong.
Have you looked at doing this with the kexec on panic infrastructure?
Things like mkdumpfile can now have enough information to dump this.
If you are space constrained a stand alone executable could be used
instead of a linux kernel to marshal the information into your buffer.
Eric
^ permalink raw reply
* Re: [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit
From: David VomLehn @ 2009-06-03 0:03 UTC (permalink / raw)
To: James Bottomley
Cc: Tim Bird, Josh Boyer, linux-arch, ksummit-2009-discuss,
linux-embedded
In-Reply-To: <1243975064.6342.10.camel@mulgrave.site>
On Tue, Jun 02, 2009 at 03:37:44PM -0500, James Bottomley wrote:
...
> This is what made us suggest the presentation driven approach. We can
> send people who understand how the kernel development process out
> anointed as embedded maintainers. However, looking at the arch
> directory, you have a ton of new kids on the block. We wondered if,
> perhaps, rather than having seasoned kernel developers reach out to the
> embedded community, we might try giving the embedded community the
> opportunity to reach out to us. The topic of "flattened device tree"
> look interesting to me (perhaps because I'm a hardened device driver
> person and things like that always look interesting to me) ... if we can
> get a few more like that out of the woodwork, this approach might end up
> being successful.
Failure reporting is the one area where embedded applications have
little overlap with other Linux application domains. The cable settop box
environment has:
o Limited peristent storage
o Low or no upstream bandwidth
o Little access to hundreds of thousands of devices in the field
When a kernel panics in the field, we have no place to put a core dump
and, if we had a place to put it, it would take way too long to upload
it when the box comes back up. And most people just don't understand when
you knock at their door at midnight, JTAG probe in hand.
We hook in a panic notifier and have it generate a really rich report.
At present, this report stays in memory until we reboot and send it
upstream (or write it to flash), but we could really write it to any
device with which we can use polled I/O (interrupts being questionable
at this point). Generic interfaces to support this would be useful.
Many embedded devices have highly integrated stacks, so failures in user
space lead to device reboots, and you want to leverage much of the same
ability to store and send failure reports.
Our failure report includes things you'd expect as well as various pieces
of history, such as:
o IRQs
o softirq dispatches (including max times)
o selected /proc info, e.g. /proc/meminfo
We also report info on the current thread, like backtracing and
/proc/<pid>/maps, though I'm not sure it's as useful as it might be.
Though I'm working on pushing this stuff out, other things that might be
helpful are:
o If you get to panic() by way of die(), you've lost the registers passed to
die(). We save a pointer off, but it's really a kludge.
o The implementation of die() varies from platform to platform and isn't even
called die() everywhere.
o It is truly nasty trying to get /proc information when you are in a panic
situation--any semaphores being held are not going to be released, so you
have to duplicate a lot of the code, minus the semaphores. Pretty gross
and there is no way our implementation will be acceptable.
o Increased reporting on what's happening in user/kernel space interaction.
For example, a signal sent in good faith might kill a buggy process. It
would be helpful to log signals that result in a process' death.
o Then there is more speculative stuff. For example, your caches would
have a copy of the most recently accessed code and data. If your
processor supports dumping cache, it might help determing what went wrong.
> James
^ permalink raw reply
* Re: Representing Embedded Architectures at the Kernel Summit
From: Jean-Christophe PLAGNIOL-VILLARD @ 2009-06-02 22:21 UTC (permalink / raw)
To: Josh Boyer
Cc: James Bottomley, ksummit-2009-discuss, linux-arch, linux-embedded
In-Reply-To: <20090602172941.GL3095@hansolo.jdub.homelinux.org>
On 13:29 Tue 02 Jun , Josh Boyer wrote:
> On Tue, Jun 02, 2009 at 03:22:20PM +0000, James Bottomley wrote:
> >Hi All,
> >
> >We've got to the point where there are simply too many embedded
> >architectures to invite all the arch maintainers to the kernel summit.
> >So, this year, we thought we'd do embedded via topic driven invitations
> >instead. So what we're looking for is a proposal to discuss the issues
> >most affecting embedded architectures, or preview any features affecting
> >the main kernel which embedded architectures might need ... or any other
> >topics from embedded architectures which might need discussion or
> >debate. If you'd like to do this, could you either reply to this email,
> >or send proposals to:
> >
> >ksummit-2009-discuss@lists.linux-foundation.org
>
> For those not following the ksummit list, below is the current list of
> suggested topics:
>
> PROPOSER TOPIC
>
> Jon Corbet How much do we owe sloppy application writers
> Jon Corbet The containers end game and how we get there
> Balbir Singh The Hacking Hour
> Rafael Wysocki Regression tracking and kernel quality
> Jon Corbet Criteria for acceptance of kernel tracepoints
> Jesse Barnes Profiling and performance counters
> Eric Biederman Procedures for dealing with patent problems
> John Linville Patch review checklist
> Matthew Wilcox How to handle style-only patches
> Dan Williams RAID unification / stacked block devices
> Jiri Kosina User-space drivers - worth encouraging?
> Sam Ravnborg Shipping user-space components in the kernel
> Kay Sievers Establishment/maintenance of per-subsystem todo lists
> Steve Rostedt Improving changelogs
> Jon Corbet I/O bandwidth controllers (maybe minisummit report)
> Ted Ts'o PulseAudio and kernel interface issues
> Greg KH Generic architecture support and arch layer cleanup
> (Josh Boyer: add device tree discussion?)
> Dave Jones cpumasks, churn, and unending API changes
> Dirk Hohndel Issues related to wireless technologies
> Jon Corbet Tracing:
> Merging utrace
> Ftrace mainline v. private debugging tools
> Non-ftrace visibility infrastructure
> Systemtap for kernel developers
> Marcel Holtmann Tracing and protocol dumping
I'd like to propose AMP and kernel relocate
as more and SoC will came with multiple core with or without the same arch
Best Regards,
J.
^ permalink raw reply
* Re: Representing Embedded Architectures at the Kernel Summit
From: Russell King @ 2009-06-02 21:48 UTC (permalink / raw)
To: Robert Schwebel
Cc: Grant Likely, James Bottomley, ksummit-2009-discuss, linux-arch,
linux-embedded, Josh Boyer, Tim Bird
In-Reply-To: <20090602214005.GL32630@pengutronix.de>
On Tue, Jun 02, 2009 at 11:40:05PM +0200, Robert Schwebel wrote:
> And even with the cpu core, we usually build kernels with optimized
> toolchains for their cpu family.
I'm afraid that doesn't make a blind bit of difference to the kernel -
it passes the relevent optimization flags to gcc which tell the compiler
which instructions to use (based upon the CPU architecture) and how to
schedule those instructions (based upon the CPU type(s) chosen in the
kernel configuration.)
All that an "optimized" toolchain is is a toolchain with a different
default optimization selected.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* Re: Representing Embedded Architectures at the Kernel Summit
From: Robert Schwebel @ 2009-06-02 21:40 UTC (permalink / raw)
To: Grant Likely, James Bottomley, ksummit-2009-discuss, linux-arch,
linux-e
In-Reply-To: <20090602211057.GA10800@flint.arm.linux.org.uk>
On Tue, Jun 02, 2009 at 10:10:58PM +0100, Russell King wrote:
> I really don't think combining SoC support is going to be realistic,
> device tree or not. When we had just four machine types (RiscPC,
> EBSA110, EBSA285, Netwinder) I did look into this and came to the
> conclusion that it would be far too inefficient for there to be any
> win.
>
> The big problem we have is that the only commonality between different
> SoCs is that the CPU executes ARM instructions. Everything else is
> entirely up to the SoC designer - eg location of memory, spacing of
> memory banks, type of interrupt controller, etc is all highly SoC
> specific. Nothing outside of the ARM CPU itself is standardized.
And even with the cpu core, we usually build kernels with optimized
toolchains for their cpu family. But nevertheless - describing hardware
inside a mach* makes sense.
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit
From: Robert Schwebel @ 2009-06-02 21:34 UTC (permalink / raw)
To: James Bottomley
Cc: Tim Bird, Josh Boyer, linux-arch, ksummit-2009-discuss,
linux-embedded, David VomLehn
In-Reply-To: <1243975064.6342.10.camel@mulgrave.site>
On Tue, Jun 02, 2009 at 03:37:44PM -0500, James Bottomley wrote:
> The topic of "flattened device tree" look interesting to me (perhaps
> because I'm a hardened device driver person and things like that
> always look interesting to me) ...
The recent oftree activities look indeed very promising; the different
boot-information-passing methods, mainly in powerpc and arm land, is
IMHO and important field where a generic kernel infrastructure would
make sense for the embedded people. Taken that oftree has created
robustness and compatiblity problems in the past but seems to move into
a good direction recently, feedback from core kernel developers would
certainly be a good thing.
> if we can get a few more like that out of the woodwork, this approach
> might end up being successful.
Could flickerfree-bootsplash be a topic? Or is that completely pushed
into the userspace these fastboot days?
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: Representing Embedded Architectures at the Kernel Summit
From: Geert Uytterhoeven @ 2009-06-02 21:18 UTC (permalink / raw)
To: Grant Likely, James Bottomley, ksummit-2009-discuss, linux-arch,
linux-e
In-Reply-To: <20090602211057.GA10800@flint.arm.linux.org.uk>
On Tue, Jun 2, 2009 at 23:10, Russell King <rmk@arm.linux.org.uk> wrote:
> On Tue, Jun 02, 2009 at 11:29:46AM -0600, Grant Likely wrote:
>> Embedded PowerPC and Microblaze has tackled this problem with the
>> "Flattened Device Tree" data format which is derived from the
>> OpenFirmware specifications, and there is some interest and debate (as
>> discussed recently on the ARM mailing list) about making flattened
>> device tree usable by ARM also (which I'm currently
>> proof-of-concepting).
>
> Note that I have to point out that ARM will probably never be in a
> situation where you can have a one kernel image boots on everything.
> That _is_ practical today (and does happen with all PXA now) with what
> we have within a very big restriction - which is that the kernel must
> be built to support PXA and not Atmel SoCs.
>
> I really don't think combining SoC support is going to be realistic,
> device tree or not. When we had just four machine types (RiscPC,
> EBSA110, EBSA285, Netwinder) I did look into this and came to the
> conclusion that it would be far too inefficient for there to be any
> win.
>
> The big problem we have is that the only commonality between different
> SoCs is that the CPU executes ARM instructions. Everything else is
> entirely up to the SoC designer - eg location of memory, spacing of
> memory banks, type of interrupt controller, etc is all highly SoC
> specific. Nothing outside of the ARM CPU itself is standardized.
That sounds very similar to m68k, which does support generic kernels
(except for Sun-3, which uses a completely different MMU)?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: Representing Embedded Architectures at the Kernel Summit
From: Bill Gatliff @ 2009-06-02 21:16 UTC (permalink / raw)
To: Grant Likely, James Bottomley, ksummit-2009-discuss, linux-arch,
linux-e
In-Reply-To: <20090602211057.GA10800@flint.arm.linux.org.uk>
Russell King wrote:
> The big problem we have is that the only commonality between different
> SoCs is that the CPU executes ARM instructions. Everything else is
> entirely up to the SoC designer - eg location of memory, spacing of
> memory banks, type of interrupt controller, etc is all highly SoC
> specific. Nothing outside of the ARM CPU itself is standardized.
>
>
And that diversity is precisely because of the diversity in ARM-based
embedded platforms.
Such diversity means that kernel/driver development is a constant
activity, which suggests that we shouldn't bother the effort to come up
with a comprehensive solution because none will exist. Rather, we
should maintain and improve the ability to rapidly prototype and adapt.
Things like furthering the deployment of platform_device,
clocksource/clockdevice, and so on.
ARM diversity is already a LOT easier to deal with than it was under
2.4, so we're making progress.
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: Representing Embedded Architectures at the Kernel Summit
From: Russell King @ 2009-06-02 21:10 UTC (permalink / raw)
To: Grant Likely
Cc: James Bottomley, ksummit-2009-discuss, linux-arch, linux-embedded,
Josh Boyer, Tim Bird
In-Reply-To: <fa686aa40906021029macf3c72g5261f8d4dbea935a@mail.gmail.com>
On Tue, Jun 02, 2009 at 11:29:46AM -0600, Grant Likely wrote:
> Embedded PowerPC and Microblaze has tackled this problem with the
> "Flattened Device Tree" data format which is derived from the
> OpenFirmware specifications, and there is some interest and debate (as
> discussed recently on the ARM mailing list) about making flattened
> device tree usable by ARM also (which I'm currently
> proof-of-concepting).
Note that I have to point out that ARM will probably never be in a
situation where you can have a one kernel image boots on everything.
That _is_ practical today (and does happen with all PXA now) with what
we have within a very big restriction - which is that the kernel must
be built to support PXA and not Atmel SoCs.
I really don't think combining SoC support is going to be realistic,
device tree or not. When we had just four machine types (RiscPC,
EBSA110, EBSA285, Netwinder) I did look into this and came to the
conclusion that it would be far too inefficient for there to be any
win.
The big problem we have is that the only commonality between different
SoCs is that the CPU executes ARM instructions. Everything else is
entirely up to the SoC designer - eg location of memory, spacing of
memory banks, type of interrupt controller, etc is all highly SoC
specific. Nothing outside of the ARM CPU itself is standardized.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* Re: [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit
From: Bill Gatliff @ 2009-06-02 20:44 UTC (permalink / raw)
To: James Bottomley
Cc: Tim Bird, Josh Boyer, linux-arch, ksummit-2009-discuss,
linux-embedded, David VomLehn
In-Reply-To: <1243975064.6342.10.camel@mulgrave.site>
James Bottomley wrote:
> On Tue, 2009-06-02 at 12:30 -0700, Tim Bird wrote:
>
>> With regard to a process to determine representatives, I'm not
>> sure we need one. Based on participation and inclusion in
>> MAINTAINERS, either Matt Mackall or David Woodhouse can
>> represent most embedded issues just fine. And I can say that
>> officially on behalf of CELF and it's members, which would
>> account for a large fraction of the overall embedded community.
>>
What about others like myself who would like to get more involved, but
don't show up in the MAINTAINERS list? I might be interested in lending
a hand in helping to represent the embedded issues...
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit
From: James Bottomley @ 2009-06-02 20:37 UTC (permalink / raw)
To: Tim Bird
Cc: Josh Boyer, linux-arch, ksummit-2009-discuss, linux-embedded,
David VomLehn
In-Reply-To: <4A257DF0.6040607@am.sony.com>
On Tue, 2009-06-02 at 12:30 -0700, Tim Bird wrote:
> Josh Boyer wrote:
> > 2) Encouraging upstream participation of "Embedded" distros
> >
> > Things like Moblin and Android are getting a lot of press these days, but
> > embedded distros have been around for a while. Are we getting good
> > participation from these vendors? Is there something we could be doing to
> > encourage such participation? Has CELF helped with this at all? etc
>
> CELF tries, but the progress is exceedingly slow. Recently
> we've been more focused on contracting specific feature work.
> (E.g. Squashfs mainlining).
>
> James Bottomley wrote:
> > Even for someone as inattentive as me, the general problems of getting
> > embedded people to agree the sky is blue did impinge on the peripheral
> > consciousness. Thus: If you can come up with such a process in a timely
> > fashion then fine ... if not, we'll do the topic based one suggested by
> > the PC.
>
> With regard to a process to determine representatives, I'm not
> sure we need one. Based on participation and inclusion in
> MAINTAINERS, either Matt Mackall or David Woodhouse can
> represent most embedded issues just fine. And I can say that
> officially on behalf of CELF and it's members, which would
> account for a large fraction of the overall embedded community.
>
> With regard to topics, do topics drive attendee invitations,
> or vice-versa?
>
> Here's my own issue list:
>
> tracing - already well (over?) represented
>
> bloat - tracing will help identify performance bloat.
> As for size bloat, a smaller kernel is always desirable, but we
> are seeing signs that Moore's law is catching up and making
> this less an issue (for the kernel - apps still have big
> problems here.)
>
> power management - Use cases for products that spend most
> of their time off (even while appearing to be running) are
> of interest. I don't know what the status 'wakelock-like'
> solutions is.
>
> fast boot - kernel is almost done? (!!!) The new target for
> kernel boot time is 300 milliseconds. Once there, almost
> all problems are then user space issues. It is interesting
> how much of a differentiator fast boot became for Linux
> in netbooks and dual-boot configurations, in just the last
> 2 years - which just shows that sometimes it pays off to
> optimize something. ;-)
OK, if that's what you all want, that's what we can do ... however, it
would likely be the same people discussing the same issues.
> participation - talking about this is like beating a dead horse
> (for me at least). I've been working on this for 5 years now,
> making baby steps forward. The issues are, by now, well understood
> (I hope). I'm not sure what a KS discussion is going to do
> to drive issues here.
This is what made us suggest the presentation driven approach. We can
send people who understand how the kernel development process out
anointed as embedded maintainers. However, looking at the arch
directory, you have a ton of new kids on the block. We wondered if,
perhaps, rather than having seasoned kernel developers reach out to the
embedded community, we might try giving the embedded community the
opportunity to reach out to us. The topic of "flattened device tree"
look interesting to me (perhaps because I'm a hardened device driver
person and things like that always look interesting to me) ... if we can
get a few more like that out of the woodwork, this approach might end up
being successful.
James
^ permalink raw reply
* Re: Representing Embedded Architectures at the Kernel Summit
From: Tim Bird @ 2009-06-02 19:30 UTC (permalink / raw)
To: Josh Boyer
Cc: James Bottomley, David VomLehn, ksummit-2009-discuss, linux-arch,
linux-embedded
In-Reply-To: <20090602185143.GA8655@zod.rchland.ibm.com>
Josh Boyer wrote:
> 2) Encouraging upstream participation of "Embedded" distros
>
> Things like Moblin and Android are getting a lot of press these days, but
> embedded distros have been around for a while. Are we getting good
> participation from these vendors? Is there something we could be doing to
> encourage such participation? Has CELF helped with this at all? etc
CELF tries, but the progress is exceedingly slow. Recently
we've been more focused on contracting specific feature work.
(E.g. Squashfs mainlining).
James Bottomley wrote:
> Even for someone as inattentive as me, the general problems of getting
> embedded people to agree the sky is blue did impinge on the peripheral
> consciousness. Thus: If you can come up with such a process in a timely
> fashion then fine ... if not, we'll do the topic based one suggested by
> the PC.
With regard to a process to determine representatives, I'm not
sure we need one. Based on participation and inclusion in
MAINTAINERS, either Matt Mackall or David Woodhouse can
represent most embedded issues just fine. And I can say that
officially on behalf of CELF and it's members, which would
account for a large fraction of the overall embedded community.
With regard to topics, do topics drive attendee invitations,
or vice-versa?
Here's my own issue list:
tracing - already well (over?) represented
bloat - tracing will help identify performance bloat.
As for size bloat, a smaller kernel is always desirable, but we
are seeing signs that Moore's law is catching up and making
this less an issue (for the kernel - apps still have big
problems here.)
power management - Use cases for products that spend most
of their time off (even while appearing to be running) are
of interest. I don't know what the status 'wakelock-like'
solutions is.
fast boot - kernel is almost done? (!!!) The new target for
kernel boot time is 300 milliseconds. Once there, almost
all problems are then user space issues. It is interesting
how much of a differentiator fast boot became for Linux
in netbooks and dual-boot configurations, in just the last
2 years - which just shows that sometimes it pays off to
optimize something. ;-)
participation - talking about this is like beating a dead horse
(for me at least). I've been working on this for 5 years now,
making baby steps forward. The issues are, by now, well understood
(I hope). I'm not sure what a KS discussion is going to do
to drive issues here.
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: Representing Embedded Architectures at the Kernel Summit
From: Josh Boyer @ 2009-06-02 18:51 UTC (permalink / raw)
To: James Bottomley
Cc: David VomLehn, ksummit-2009-discuss, linux-arch, linux-embedded
In-Reply-To: <1243967132.4280.11.camel@mulgrave.site>
On Tue, Jun 02, 2009 at 01:25:32PM -0500, James Bottomley wrote:
>On Tue, 2009-06-02 at 10:52 -0700, David VomLehn wrote:
>> On Tue, Jun 02, 2009 at 12:42:57PM -0500, James Bottomley wrote:
>> > On Tue, 2009-06-02 at 13:29 -0400, Josh Boyer wrote:
>> > > Which leads me to suggest that it is at least worth having someone with an
>> > > embedded focus at KS to simply keep an eye out for impacts of generic changes.
>> > > "Feature parity" is something I often deal with in trying to keep ppc4xx up to
>> > > speed with the rest of the archs in the kernel.
>> >
>> > We're fine with this, if that's how the embedded guys would like to do
>> > it ... how do you want to nominate the "someone with an embedded focus"?
>> > We chose the topic driven approach because that's the one it's easiest
>> > for the Kernel Summit Programme Committee to look at and make attendance
>> > decisions based upon. However, if all the embedded people want to
>> > choose their own representatives, that's fine by us too ... as long as
>> > you can devise a fair process.
>>
>> Now, James, I think you haven't been paying attention to the embedded Linux
>> world...asking us to devise *any* process is much more chaotic than herding
>> cats. Expecting something everyone agrees is fair would probably take until
>> at least KS 2010. That being said, we have three people who are listed in
>> MAINTAINERS under embedded Linux. We might start by seeing which of them
>> might take up the mantle and vote on the linux-embedded mailing list.
>
>Even for someone as inattentive as me, the general problems of getting
>embedded people to agree the sky is blue did impinge on the peripheral
>consciousness. Thus: If you can come up with such a process in a timely
>fashion then fine ... if not, we'll do the topic based one suggested by
>the PC.
Most of these are probably tired and old, but some possible topic suggestions:
1) Kernel binary bloat (again)
2) Encouraging upstream participation of "Embedded" distros
Things like Moblin and Android are getting a lot of press these days, but
embedded distros have been around for a while. Are we getting good
participation from these vendors? Is there something we could be doing to
encourage such participation? Has CELF helped with this at all? etc
3) Netbooks - the bridge between embedded and desktop?
Is the flourish of low cost netbooks, some pre-installed with Linux, having any
impact on how we review and develop general kernel code?
One of the problems I struggle with is coming up with embedded topics general
enough to be of interest to a broader set of both upstream kernel developers
and the embedded community. Those that are general enough have either been
discussed quite a bit already, or are already on the list of topics.
Maybe I'm just not trying hard enough.
josh
^ permalink raw reply
* Re: Representing Embedded Architectures at the Kernel Summit
From: Grant Likely @ 2009-06-02 18:46 UTC (permalink / raw)
To: David VomLehn
Cc: James Bottomley, ksummit-2009-discuss, linux-arch, linux-embedded,
Josh Boyer, Tim Bird
In-Reply-To: <20090602174538.GA10973@cuplxvomd02.corp.sa.net>
On Tue, Jun 2, 2009 at 11:45 AM, David VomLehn <dvomlehn@cisco.com> wrote:
> Should we decide to go this way, there probably a next step wherein we
> standardize the device tree entries for those devices that are shared across
> multiple architectures and platorms. This will likely be a never-ending
> and mostly thankless task, but will again make things easier in the long run.
devicetree-discuss@ozlabs.org mailing list is your friend here. In
PowerPC land we've mostly settled on the policy of not merging a
driver before the device tree binding is documented, posted and
reviewed. This weeds out a lot of common mistakes.
I also think the stuff in Documentation/powerpc/dts-bindings needs to
be moved out to a common location.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Representing Embedded Architectures at the Kernel Summit
From: James Bottomley @ 2009-06-02 18:25 UTC (permalink / raw)
To: David VomLehn
Cc: Josh Boyer, ksummit-2009-discuss, linux-arch, linux-embedded
In-Reply-To: <20090602175244.GB10973@cuplxvomd02.corp.sa.net>
On Tue, 2009-06-02 at 10:52 -0700, David VomLehn wrote:
> On Tue, Jun 02, 2009 at 12:42:57PM -0500, James Bottomley wrote:
> > On Tue, 2009-06-02 at 13:29 -0400, Josh Boyer wrote:
> > > Which leads me to suggest that it is at least worth having someone with an
> > > embedded focus at KS to simply keep an eye out for impacts of generic changes.
> > > "Feature parity" is something I often deal with in trying to keep ppc4xx up to
> > > speed with the rest of the archs in the kernel.
> >
> > We're fine with this, if that's how the embedded guys would like to do
> > it ... how do you want to nominate the "someone with an embedded focus"?
> > We chose the topic driven approach because that's the one it's easiest
> > for the Kernel Summit Programme Committee to look at and make attendance
> > decisions based upon. However, if all the embedded people want to
> > choose their own representatives, that's fine by us too ... as long as
> > you can devise a fair process.
>
> Now, James, I think you haven't been paying attention to the embedded Linux
> world...asking us to devise *any* process is much more chaotic than herding
> cats. Expecting something everyone agrees is fair would probably take until
> at least KS 2010. That being said, we have three people who are listed in
> MAINTAINERS under embedded Linux. We might start by seeing which of them
> might take up the mantle and vote on the linux-embedded mailing list.
Even for someone as inattentive as me, the general problems of getting
embedded people to agree the sky is blue did impinge on the peripheral
consciousness. Thus: If you can come up with such a process in a timely
fashion then fine ... if not, we'll do the topic based one suggested by
the PC.
James
^ permalink raw reply
* Re: Representing Embedded Architectures at the Kernel Summit
From: David VomLehn @ 2009-06-02 17:52 UTC (permalink / raw)
To: James Bottomley
Cc: Josh Boyer, ksummit-2009-discuss, linux-arch, linux-embedded
In-Reply-To: <1243964577.4229.49.camel@mulgrave.int.hansenpartnership.com>
On Tue, Jun 02, 2009 at 12:42:57PM -0500, James Bottomley wrote:
> On Tue, 2009-06-02 at 13:29 -0400, Josh Boyer wrote:
> > Which leads me to suggest that it is at least worth having someone with an
> > embedded focus at KS to simply keep an eye out for impacts of generic changes.
> > "Feature parity" is something I often deal with in trying to keep ppc4xx up to
> > speed with the rest of the archs in the kernel.
>
> We're fine with this, if that's how the embedded guys would like to do
> it ... how do you want to nominate the "someone with an embedded focus"?
> We chose the topic driven approach because that's the one it's easiest
> for the Kernel Summit Programme Committee to look at and make attendance
> decisions based upon. However, if all the embedded people want to
> choose their own representatives, that's fine by us too ... as long as
> you can devise a fair process.
Now, James, I think you haven't been paying attention to the embedded Linux
world...asking us to devise *any* process is much more chaotic than herding
cats. Expecting something everyone agrees is fair would probably take until
at least KS 2010. That being said, we have three people who are listed in
MAINTAINERS under embedded Linux. We might start by seeing which of them
might take up the mantle and vote on the linux-embedded mailing list.
> James
^ permalink raw reply
* Re: Representing Embedded Architectures at the Kernel Summit
From: James Bottomley @ 2009-06-02 17:48 UTC (permalink / raw)
To: Grant Likely
Cc: ksummit-2009-discuss, linux-arch, linux-embedded, Josh Boyer,
Tim Bird
In-Reply-To: <fa686aa40906021029macf3c72g5261f8d4dbea935a@mail.gmail.com>
On Tue, 2009-06-02 at 11:29 -0600, Grant Likely wrote:
> One topic that seems to garner debate is the issue of decoupling the
> kernel image from the target platform. ie. On x86, PowerPC and Sparc
> a kernel image will boot on any machine (assuming the needed drivers
> are enabled), but this is rarely the case in embedded. Most embedded
> kernels require explicit board support selected at compile time with
> no way to produce a generic kernel which will boot on a whole family
> of devices, let alone the whole architecture. Part of this is a
> firmware issue, where existing firmware passes very little in the way
> of hardware description to the kernel, but part is also not making
> available any form of common language for describing the machine.
OK, so my minimal understanding in this area lead me to believe this was
because most embedded systems didn't have properly discoverable busses
and therefore you had to tailor the kernel configuration exactly to the
devices the system had.
> Embedded PowerPC and Microblaze has tackled this problem with the
> "Flattened Device Tree" data format which is derived from the
> OpenFirmware specifications, and there is some interest and debate (as
> discussed recently on the ARM mailing list) about making flattened
> device tree usable by ARM also (which I'm currently
> proof-of-concepting). Josh Boyer has already touched on discussing
> flattened device tree support at kernel summit in an email to the
> ksummit list last week (quoted below), and I'm wondering if a broader
> discussing would be warranted.
>
> I think that in the absence of any established standard like the PC
> BIOS/EFI or a real Open Firmware interface, then the kernel should at
> least offer a recommended interface so that multiplatform kernels are
> possible without explicitly having the machine layout described to it
> at compile time. I know that some of the embedded distros are
> interested in such a thing since it gets them away from shipping
> separate images for each supported board. ie. It's really hard to do
> a generic live-cd without some form of multiplatform. FDT is a great
> approach, but it probably isn't the only option. It would be worth
> debating.
It sounds interesting ... however, it also sounds like an area which
might not impact the core kernel much ... or am I wrong about that? The
topics we're really looking for the Kernel Summit are ones that require
cross system input and which can't simply be sorted out by organising an
Embedded mini-summit.
Now if flattened device tree could help us out with BIOS, ACPI, EFI and
the other myriad boot and identification standards that seem designed to
hide system information rather than reveal it, then we might be all
ears ...
James
^ permalink raw reply
* Re: Representing Embedded Architectures at the Kernel Summit
From: David VomLehn @ 2009-06-02 17:45 UTC (permalink / raw)
To: Grant Likely
Cc: James Bottomley, ksummit-2009-discuss, linux-arch, linux-embedded,
Josh Boyer, Tim Bird
In-Reply-To: <fa686aa40906021029macf3c72g5261f8d4dbea935a@mail.gmail.com>
On Tue, Jun 02, 2009 at 11:29:46AM -0600, Grant Likely wrote:
> On Tue, Jun 2, 2009 at 9:22 AM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Hi All,
> >
> > We've got to the point where there are simply too many embedded
> > architectures to invite all the arch maintainers to the kernel summit.
> > So, this year, we thought we'd do embedded via topic driven invitations
> > instead. So what we're looking for is a proposal to discuss the issues
> > most affecting embedded architectures, or preview any features affecting
> > the main kernel which embedded architectures might need ... or any other
> > topics from embedded architectures which might need discussion or
> > debate. If you'd like to do this, could you either reply to this email,
> > or send proposals to:
> >
> > ksummit-2009-discuss@lists.linux-foundation.org
>
> Hi James,
>
> One topic that seems to garner debate is the issue of decoupling the
> kernel image from the target platform.
...
> Embedded PowerPC and Microblaze has tackled this problem with the
> "Flattened Device Tree" data format which is derived from the
> OpenFirmware specifications, and there is some interest and debate (as
> discussed recently on the ARM mailing list) about making flattened
> device tree usable by ARM also (which I'm currently
> proof-of-concepting). Josh Boyer has already touched on discussing
> flattened device tree support at kernel summit in an email to the
> ksummit list last week (quoted below), and I'm wondering if a broader
> discussing would be warranted.
I absolutely agree with this. We have been using the flattened device tree
on our MIPS platform to support multiple systems, and are close to posting
a patch to the MIPS Linux mailing list. At least one other MIPS platform
has indicated that they want to use the device tree.
> I think that in the absence of any established standard like the PC
> BIOS/EFI or a real Open Firmware interface, then the kernel should at
> least offer a recommended interface so that multiplatform kernels are
> possible without explicitly having the machine layout described to it
> at compile time. I know that some of the embedded distros are
> interested in such a thing since it gets them away from shipping
> separate images for each supported board. ie. It's really hard to do
> a generic live-cd without some form of multiplatform. FDT is a great
> approach, but it probably isn't the only option. It would be worth
> debating.
Is there another possibility besides the device tree that people are using
on 4 different architectures? We can't mandate support of the device tree
for any particular architecture or platform, but we can make sure the device
tree infrastructure is supported well enough that any architecture can pick
it up easily. Doing so will also encourage support in bootloaders which may
not currently do so.
Should we decide to go this way, there probably a next step wherein we
standardize the device tree entries for those devices that are shared across
multiple architectures and platorms. This will likely be a never-ending
and mostly thankless task, but will again make things easier in the long run.
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Representing Embedded Architectures at the Kernel Summit
From: James Bottomley @ 2009-06-02 17:42 UTC (permalink / raw)
To: Josh Boyer; +Cc: ksummit-2009-discuss, linux-arch, linux-embedded
In-Reply-To: <20090602172941.GL3095@hansolo.jdub.homelinux.org>
On Tue, 2009-06-02 at 13:29 -0400, Josh Boyer wrote:
> Which leads me to suggest that it is at least worth having someone with an
> embedded focus at KS to simply keep an eye out for impacts of generic changes.
> "Feature parity" is something I often deal with in trying to keep ppc4xx up to
> speed with the rest of the archs in the kernel.
We're fine with this, if that's how the embedded guys would like to do
it ... how do you want to nominate the "someone with an embedded focus"?
We chose the topic driven approach because that's the one it's easiest
for the Kernel Summit Programme Committee to look at and make attendance
decisions based upon. However, if all the embedded people want to
choose their own representatives, that's fine by us too ... as long as
you can devise a fair process.
James
^ permalink raw reply
* Re: Representing Embedded Architectures at the Kernel Summit
From: Grant Likely @ 2009-06-02 17:29 UTC (permalink / raw)
To: James Bottomley
Cc: ksummit-2009-discuss, linux-arch, linux-embedded, Josh Boyer,
Tim Bird
In-Reply-To: <1243956140.4229.25.camel@mulgrave.int.hansenpartnership.com>
On Tue, Jun 2, 2009 at 9:22 AM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> Hi All,
>
> We've got to the point where there are simply too many embedded
> architectures to invite all the arch maintainers to the kernel summit.
> So, this year, we thought we'd do embedded via topic driven invitations
> instead. So what we're looking for is a proposal to discuss the issues
> most affecting embedded architectures, or preview any features affecting
> the main kernel which embedded architectures might need ... or any other
> topics from embedded architectures which might need discussion or
> debate. If you'd like to do this, could you either reply to this email,
> or send proposals to:
>
> ksummit-2009-discuss@lists.linux-foundation.org
Hi James,
One topic that seems to garner debate is the issue of decoupling the
kernel image from the target platform. ie. On x86, PowerPC and Sparc
a kernel image will boot on any machine (assuming the needed drivers
are enabled), but this is rarely the case in embedded. Most embedded
kernels require explicit board support selected at compile time with
no way to produce a generic kernel which will boot on a whole family
of devices, let alone the whole architecture. Part of this is a
firmware issue, where existing firmware passes very little in the way
of hardware description to the kernel, but part is also not making
available any form of common language for describing the machine.
Embedded PowerPC and Microblaze has tackled this problem with the
"Flattened Device Tree" data format which is derived from the
OpenFirmware specifications, and there is some interest and debate (as
discussed recently on the ARM mailing list) about making flattened
device tree usable by ARM also (which I'm currently
proof-of-concepting). Josh Boyer has already touched on discussing
flattened device tree support at kernel summit in an email to the
ksummit list last week (quoted below), and I'm wondering if a broader
discussing would be warranted.
I think that in the absence of any established standard like the PC
BIOS/EFI or a real Open Firmware interface, then the kernel should at
least offer a recommended interface so that multiplatform kernels are
possible without explicitly having the machine layout described to it
at compile time. I know that some of the embedded distros are
interested in such a thing since it gets them away from shipping
separate images for each supported board. ie. It's really hard to do
a generic live-cd without some form of multiplatform. FDT is a great
approach, but it probably isn't the only option. It would be worth
debating.
Cheers,
g.
On Thu, May 28, 2009 at 5:41 PM, Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> Not to hijack this entirely, but I'm wondering if we could tie in some of the
> cross-arch device tree discussions that have been taking place among the ppc,
> sparc, and arm developers.
>
> I know the existing OF code for ppc, sparc, and microblaze could probably use
> some consolidation and getting some of the arch maintainers together in a room
> might prove fruitful. Particularly if we are going to discuss how to make
> drivers work for device tree and standard platforms alike.
>
> josh
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Representing Embedded Architectures at the Kernel Summit
From: Josh Boyer @ 2009-06-02 17:29 UTC (permalink / raw)
To: James Bottomley; +Cc: ksummit-2009-discuss, linux-arch, linux-embedded
In-Reply-To: <1243956140.4229.25.camel@mulgrave.int.hansenpartnership.com>
On Tue, Jun 02, 2009 at 03:22:20PM +0000, James Bottomley wrote:
>Hi All,
>
>We've got to the point where there are simply too many embedded
>architectures to invite all the arch maintainers to the kernel summit.
>So, this year, we thought we'd do embedded via topic driven invitations
>instead. So what we're looking for is a proposal to discuss the issues
>most affecting embedded architectures, or preview any features affecting
>the main kernel which embedded architectures might need ... or any other
>topics from embedded architectures which might need discussion or
>debate. If you'd like to do this, could you either reply to this email,
>or send proposals to:
>
>ksummit-2009-discuss@lists.linux-foundation.org
For those not following the ksummit list, below is the current list of
suggested topics:
PROPOSER TOPIC
Jon Corbet How much do we owe sloppy application writers
Jon Corbet The containers end game and how we get there
Balbir Singh The Hacking Hour
Rafael Wysocki Regression tracking and kernel quality
Jon Corbet Criteria for acceptance of kernel tracepoints
Jesse Barnes Profiling and performance counters
Eric Biederman Procedures for dealing with patent problems
John Linville Patch review checklist
Matthew Wilcox How to handle style-only patches
Dan Williams RAID unification / stacked block devices
Jiri Kosina User-space drivers - worth encouraging?
Sam Ravnborg Shipping user-space components in the kernel
Kay Sievers Establishment/maintenance of per-subsystem todo lists
Steve Rostedt Improving changelogs
Jon Corbet I/O bandwidth controllers (maybe minisummit report)
Ted Ts'o PulseAudio and kernel interface issues
Greg KH Generic architecture support and arch layer cleanup
(Josh Boyer: add device tree discussion?)
Dave Jones cpumasks, churn, and unending API changes
Dirk Hohndel Issues related to wireless technologies
Jon Corbet Tracing:
Merging utrace
Ftrace mainline v. private debugging tools
Non-ftrace visibility infrastructure
Systemtap for kernel developers
Marcel Holtmann Tracing and protocol dumping
Some of these certainly impact embedded architectures and workloads. Examples
would be "Generic architecture support, arch layer cleanup", tracing, profiling
and performance counters, userspace drivers, etc.
Which leads me to suggest that it is at least worth having someone with an
embedded focus at KS to simply keep an eye out for impacts of generic changes.
"Feature parity" is something I often deal with in trying to keep ppc4xx up to
speed with the rest of the archs in the kernel.
josh
^ permalink raw reply
* Representing Embedded Architectures at the Kernel Summit
From: James Bottomley @ 2009-06-02 15:22 UTC (permalink / raw)
To: ksummit-2009-discuss, linux-arch, linux-embedded
Hi All,
We've got to the point where there are simply too many embedded
architectures to invite all the arch maintainers to the kernel summit.
So, this year, we thought we'd do embedded via topic driven invitations
instead. So what we're looking for is a proposal to discuss the issues
most affecting embedded architectures, or preview any features affecting
the main kernel which embedded architectures might need ... or any other
topics from embedded architectures which might need discussion or
debate. If you'd like to do this, could you either reply to this email,
or send proposals to:
ksummit-2009-discuss@lists.linux-foundation.org
James
^ permalink raw reply
* [PATCH] Cgroup: add cgroup members's exit data statistics
From: Marco @ 2009-06-02 14:36 UTC (permalink / raw)
To: containers; +Cc: linux-kernel, Linux Embedded
From: Marco Stornelli <marco.stornelli@gmail.com>
This patch adds the possibility for an application to receive statistics information only
for processes belonging to a cgroup. The mechanism is the same of the cpu's exit data statistics.
With this patch, instead of waiting on a specific cpumask, an application can wait for
exit data on a specific container. Through this patch it's possible to have a simple death
notifier mechanism. We can select the processes to watch and wait for their death.
A death notify mechanism is especially useful for embedded systems.
Signed-off-by: Marco Stornelli <marco.stornelli@gmail.com>
---
diff -uprN linux-2.6.29-orig/Documentation/accounting/getdelays.c linux-2.6.29/Documentation/accounting/getdelays.c
--- linux-2.6.29-orig/Documentation/accounting/getdelays.c 2009-03-24 00:12:14.000000000 +0100
+++ linux-2.6.29/Documentation/accounting/getdelays.c 2009-06-02 15:47:01.000000000 +0200
@@ -77,9 +77,11 @@ static void usage(void)
"[-m cpumask] [-t tgid] [-p pid]\n");
fprintf(stderr, " -d: print delayacct stats\n");
fprintf(stderr, " -i: print IO accounting (works only with -p)\n");
+ fprintf(stderr, " -q: print context switch accounting\n");
fprintf(stderr, " -l: listen forever\n");
fprintf(stderr, " -v: debug on\n");
- fprintf(stderr, " -C: container path\n");
+ fprintf(stderr, " -C: container path (container statistics)\n");
+ fprintf(stderr, " -N: container path (death notify)\n");
}
/*
@@ -263,13 +265,14 @@ int main(int argc, char *argv[])
char *logfile = NULL;
int loop = 0;
int containerset = 0;
+ int containernotify = 0;
char containerpath[1024];
int cfd = 0;
struct msgtemplate msg;
while (1) {
- c = getopt(argc, argv, "qdiw:r:m:t:p:vlC:");
+ c = getopt(argc, argv, "qdiw:r:m:t:p:vlC:N:");
if (c < 0)
break;
@@ -290,6 +293,10 @@ int main(int argc, char *argv[])
containerset = 1;
strncpy(containerpath, optarg, strlen(optarg) + 1);
break;
+ case 'N':
+ containernotify = 1;
+ strncpy(containerpath, optarg, strlen(optarg) + 1);
+ break;
case 'w':
logfile = strdup(optarg);
printf("write to file %s\n", logfile);
@@ -364,8 +371,13 @@ int main(int argc, char *argv[])
}
}
- if (tid && containerset) {
- fprintf(stderr, "Select either -t or -C, not both\n");
+ if (tid && (containerset || containernotify)) {
+ fprintf(stderr, "Select either -t or -C or -N\n");
+ goto err;
+ }
+
+ if (containerset && containernotify) {
+ fprintf(stderr, "Select either -C or -N, not both\n");
goto err;
}
@@ -392,7 +404,23 @@ int main(int argc, char *argv[])
goto err;
}
}
- if (!maskset && !tid && !containerset) {
+
+ if (containernotify) {
+ cfd = open(containerpath, O_RDONLY);
+ if (cfd < 0) {
+ perror("error opening container file");
+ goto err;
+ }
+ rc = send_cmd(nl_sd, id, mypid, CGROUPSTATS_CMD_GET,
+ CGROUPSTATS_CMD_ATTR_REGISTER_FD,
+ &cfd, sizeof(__u32));
+ if (rc < 0) {
+ perror("error sending cgroupstats command");
+ goto err;
+ }
+ }
+
+ if (!maskset && !tid && !containerset && !containernotify) {
usage();
goto err;
}
@@ -400,6 +428,7 @@ int main(int argc, char *argv[])
do {
int i;
+ PRINTF("Recv...\n");
rep_len = recv(nl_sd, &msg, sizeof(msg), 0);
PRINTF("received %d bytes\n", rep_len);
@@ -495,6 +524,14 @@ done:
if (rc < 0)
err(rc, "error sending deregister cpumask\n");
}
+ if (containernotify) {
+ rc = send_cmd(nl_sd, id, mypid, CGROUPSTATS_CMD_GET,
+ CGROUPSTATS_CMD_ATTR_DEREGISTER_FD,
+ &cfd, sizeof(__u32));
+ printf("Sent deregister container, retval %d\n", rc);
+ if (rc < 0)
+ err(rc, "error sending deregister container\n");
+ }
err:
close(nl_sd);
if (fd)
--- linux-2.6.29-orig/kernel/taskstats.c 2009-03-24 00:12:14.000000000 +0100
+++ linux-2.6.29/kernel/taskstats.c 2009-06-02 15:54:37.000000000 +0200
@@ -56,6 +56,8 @@ __read_mostly = {
static struct nla_policy
cgroupstats_cmd_get_policy[CGROUPSTATS_CMD_ATTR_MAX+1] __read_mostly = {
[CGROUPSTATS_CMD_ATTR_FD] = { .type = NLA_U32 },
+ [CGROUPSTATS_CMD_ATTR_REGISTER_FD] = { .type = NLA_U32 },
+ [CGROUPSTATS_CMD_ATTR_DEREGISTER_FD] = { .type = NLA_U32 },
};
struct listener {
@@ -70,6 +72,16 @@ struct listener_list {
};
static DEFINE_PER_CPU(struct listener_list, listener_array);
+struct cgroup_listener {
+ struct list_head list;
+ pid_t pid;
+ char valid;
+ struct dentry *d_cgroup;
+ int ready_to_send;
+};
+
+static struct listener_list cgroup_listener_array;
+
enum actions {
REGISTER,
DEREGISTER,
@@ -124,6 +136,63 @@ static int send_reply(struct sk_buff *sk
}
/*
+ * Send taskstats data in @skb to listeners registered for cgroup members exit
+ * data
+ */
+static void send_cgroup_listeners(struct sk_buff *skb,
+ struct listener_list *listeners)
+{
+ struct genlmsghdr *genlhdr = nlmsg_data(nlmsg_hdr(skb));
+ struct cgroup_listener *s, *tmp;
+ struct sk_buff *skb_next, *skb_cur = skb;
+ void *reply = genlmsg_data(genlhdr);
+ int rc, delcount = 0;
+
+ rc = genlmsg_end(skb, reply);
+ if (rc < 0) {
+ nlmsg_free(skb);
+ return;
+ }
+
+ rc = 0;
+ down_read(&listeners->sem);
+ list_for_each_entry(s, &listeners->list, list) {
+ if (!s->ready_to_send)
+ continue;
+ skb_next = NULL;
+ if (!list_is_last(&s->list, &listeners->list)) {
+ skb_next = skb_clone(skb_cur, GFP_KERNEL);
+ if (!skb_next)
+ break;
+ }
+ rc = genlmsg_unicast(skb_cur, s->pid);
+ if (rc == -ECONNREFUSED) {
+ s->valid = 0;
+ delcount++;
+ }
+ s->ready_to_send = 0;
+ skb_cur = skb_next;
+ }
+ up_read(&listeners->sem);
+
+ if (skb_cur)
+ nlmsg_free(skb_cur);
+
+ if (!delcount)
+ return;
+
+ /* Delete invalidated entries */
+ down_write(&listeners->sem);
+ list_for_each_entry_safe(s, tmp, &listeners->list, list) {
+ if (!s->valid) {
+ list_del(&s->list);
+ kfree(s);
+ }
+ }
+ up_write(&listeners->sem);
+}
+
+/*
* Send taskstats data in @skb to listeners registered for @cpu's exit data
*/
static void send_cpu_listeners(struct sk_buff *skb,
@@ -290,6 +359,43 @@ ret:
return;
}
+
+static int add_cgroup_del_listener(pid_t pid, struct dentry *d_cgroup,
+ int isadd)
+{
+ struct listener_list *listeners = &cgroup_listener_array;
+ struct cgroup_listener *s, *tmp;
+
+ if (isadd == REGISTER) {
+ s = kmalloc(sizeof(struct cgroup_listener), GFP_KERNEL);
+ if (!s)
+ goto cleanup;
+ s->pid = pid;
+ INIT_LIST_HEAD(&s->list);
+ s->valid = 1;
+ s->d_cgroup = d_cgroup;
+ s->ready_to_send = 0;
+
+ down_write(&listeners->sem);
+ list_add(&s->list, &listeners->list);
+ up_write(&listeners->sem);
+ return 0;
+ }
+
+ /* Deregister or cleanup */
+cleanup:
+ down_write(&listeners->sem);
+ list_for_each_entry_safe(s, tmp, &listeners->list, list) {
+ if (s->pid == pid) {
+ list_del(&s->list);
+ kfree(s);
+ break;
+ }
+ }
+ up_write(&listeners->sem);
+ return 0;
+}
+
static int add_del_listener(pid_t pid, const struct cpumask *mask, int isadd)
{
struct listener_list *listeners;
@@ -391,6 +497,32 @@ static int cgroupstats_user_cmd(struct s
struct file *file;
int fput_needed;
+ na = info->attrs[CGROUPSTATS_CMD_ATTR_REGISTER_FD];
+ if (na) {
+ fd = nla_get_u32(info->attrs[CGROUPSTATS_CMD_ATTR_REGISTER_FD]);
+ file = fget_light(fd, &fput_needed);
+ if (!file)
+ return 0;
+
+ rc = add_cgroup_del_listener(info->snd_pid, file->f_dentry,
+ REGISTER);
+ fput_light(file, fput_needed);
+ return rc;
+ }
+
+ na = info->attrs[CGROUPSTATS_CMD_ATTR_DEREGISTER_FD];
+ if (na) {
+ fd = nla_get_u32(info->attrs[CGROUPSTATS_CMD_ATTR_DEREGISTER_FD]);
+ file = fget_light(fd, &fput_needed);
+ if (!file)
+ return 0;
+
+ rc = add_cgroup_del_listener(info->snd_pid, file->f_dentry,
+ DEREGISTER);
+ fput_light(file, fput_needed);
+ return rc;
+ }
+
na = info->attrs[CGROUPSTATS_CMD_ATTR_FD];
if (!na)
return -EINVAL;
@@ -517,15 +649,32 @@ ret:
return sig->stats;
}
+int check_ready_to_send(pid_t pid, struct listener_list *cgroup_list)
+{
+ struct listener_list *listeners = cgroup_list;
+ struct cgroup_listener *s, *tmp;
+ int ready = 0;
+
+ list_for_each_entry_safe(s, tmp, &listeners->list, list) {
+ if (cgroup_verify_pid(pid, s->d_cgroup) > 0) {
+ s->ready_to_send = 1;
+ ready = 1;
+ }
+ }
+
+ return ready;
+}
+
/* Send pid data out on exit */
void taskstats_exit(struct task_struct *tsk, int group_dead)
{
int rc;
struct listener_list *listeners;
+ struct listener_list *cgroup_listeners = &cgroup_listener_array;
struct taskstats *stats;
struct sk_buff *rep_skb;
size_t size;
- int is_thread_group;
+ int is_thread_group, target = 0;
if (!family_registered)
return;
@@ -545,7 +694,16 @@ void taskstats_exit(struct task_struct *
}
listeners = &__raw_get_cpu_var(listener_array);
- if (list_empty(&listeners->list))
+ if (!list_empty(&listeners->list))
+ target |= CPU_TARGET;
+
+ down_write(&cgroup_listeners->sem);
+ if (!list_empty(&cgroup_listeners->list))
+ if (check_ready_to_send(tsk->pid, cgroup_listeners))
+ target |= CGROUP_TARGET;
+ up_write(&cgroup_listeners->sem);
+
+ if (!target)
return;
rc = prepare_reply(NULL, TASKSTATS_CMD_NEW, &rep_skb, size);
@@ -573,7 +731,10 @@ void taskstats_exit(struct task_struct *
memcpy(stats, tsk->signal->stats, sizeof(*stats));
send:
- send_cpu_listeners(rep_skb, listeners);
+ if (target & CPU_TARGET)
+ send_cpu_listeners(rep_skb, listeners);
+ if (target & CGROUP_TARGET)
+ send_cgroup_listeners(rep_skb, cgroup_listeners);
return;
err:
nlmsg_free(rep_skb);
@@ -595,12 +756,15 @@ static struct genl_ops cgroupstats_ops =
void __init taskstats_init_early(void)
{
unsigned int i;
+ struct listener_list *listeners = &cgroup_listener_array;
taskstats_cache = KMEM_CACHE(taskstats, SLAB_PANIC);
for_each_possible_cpu(i) {
INIT_LIST_HEAD(&(per_cpu(listener_array, i).list));
init_rwsem(&(per_cpu(listener_array, i).sem));
}
+ INIT_LIST_HEAD(&listeners->list);
+ init_rwsem(&listeners->sem);
}
static int __init taskstats_init(void)
--- linux-2.6.29-orig/kernel/cgroup.c 2009-03-24 00:12:14.000000000 +0100
+++ linux-2.6.29/kernel/cgroup.c 2009-06-02 15:50:57.000000000 +0200
@@ -2040,6 +2040,44 @@ static int pid_array_load(pid_t *pidarra
}
/**
+ * cgroup_verify_pid - it verifies if a pid is in a cgroup
+ * @dentry: A dentry entry belonging to the cgroup for which stats have
+ * been requested.
+ *
+ * Return value can be < 0 for error, 0 not pid not found, > 0 pid found
+ */
+int cgroup_verify_pid(pid_t pid, struct dentry *dentry)
+{
+ int ret = -EINVAL;
+ struct cgroup *cgrp;
+ struct cgroup_iter it;
+ struct task_struct *tsk;
+
+ /*
+ * Validate dentry by checking the superblock operations,
+ * and make sure it's a directory.
+ */
+ if (dentry->d_sb->s_op != &cgroup_ops ||
+ !S_ISDIR(dentry->d_inode->i_mode))
+ goto err;
+
+ ret = 0;
+ cgrp = dentry->d_fsdata;
+
+ cgroup_iter_start(cgrp, &it);
+ while ((tsk = cgroup_iter_next(cgrp, &it))) {
+ if (tsk->pid == pid) {
+ cgroup_iter_end(cgrp, &it);
+ return 1;
+ }
+ }
+ cgroup_iter_end(cgrp, &it);
+
+err:
+ return ret;
+}
+
+/**
* cgroupstats_build - build and fill cgroupstats
* @stats: cgroupstats to fill information into
* @dentry: A dentry entry belonging to the cgroup for which stats have
--- linux-2.6.29-orig/include/linux/cgroup.h 2009-03-24 00:12:14.000000000 +0100
+++ linux-2.6.29/include/linux/cgroup.h 2009-06-02 15:55:11.000000000 +0200
@@ -32,6 +32,7 @@ extern void cgroup_fork(struct task_stru
extern void cgroup_fork_callbacks(struct task_struct *p);
extern void cgroup_post_fork(struct task_struct *p);
extern void cgroup_exit(struct task_struct *p, int run_callbacks);
+extern int cgroup_verify_pid(pid_t pid, struct dentry *dentry);
extern int cgroupstats_build(struct cgroupstats *stats,
struct dentry *dentry);
@@ -450,6 +451,10 @@ static inline void cgroup_exit(struct ta
static inline void cgroup_lock(void) {}
static inline void cgroup_unlock(void) {}
+static inline int cgroup_verify_pid(pid_t pid, struct dentry *dentry)
+{
+ return -EINVAL;
+}
static inline int cgroupstats_build(struct cgroupstats *stats,
struct dentry *dentry)
{
--- linux-2.6.29-orig/include/linux/cgroupstats.h 2009-03-24 00:12:14.000000000 +0100
+++ linux-2.6.29/include/linux/cgroupstats.h 2009-06-01 11:37:46.000000000 +0200
@@ -63,6 +63,8 @@ enum {
enum {
CGROUPSTATS_CMD_ATTR_UNSPEC = 0,
CGROUPSTATS_CMD_ATTR_FD,
+ CGROUPSTATS_CMD_ATTR_REGISTER_FD,
+ CGROUPSTATS_CMD_ATTR_DEREGISTER_FD,
__CGROUPSTATS_CMD_ATTR_MAX,
};
--- linux-2.6.29-orig/include/linux/taskstats.h 2009-03-24 00:12:14.000000000 +0100
+++ linux-2.6.29/include/linux/taskstats.h 2009-06-02 15:35:24.000000000 +0200
@@ -37,6 +37,9 @@
#define TS_COMM_LEN 32 /* should be >= TASK_COMM_LEN
* in linux/sched.h */
+#define CPU_TARGET 0x1
+#define CGROUP_TARGET 0x2
+
struct taskstats {
/* The version number of this struct. This field is always set to
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox