* Re: [patch 2/4] Configure out file locking features
From: Tim Bird @ 2008-07-31 17:32 UTC (permalink / raw)
To: Adrian Bunk
Cc: Thomas Petazzoni, linux-kernel, linux-embedded, michael,
Matt Mackall, matthew, linux-fsdevel, akpm
In-Reply-To: <20080731164918.GE20212@cs181140183.pp.htv.fi>
Adrian Bunk wrote:
> And for embedded systems with which applications is it 100% safe to
> disable this option?
Sony's digital cameras.
This option *is* disabled in the kernel for (most) Sony digital cameras.
Those digital cameras have the kernel, busybox, a custom C library,
and one proprietary application. The application does not use
flock() (or AIO, or ethtool or multi-cast)
These cameras were heavily tested, and are shipping now. I can't
make any guarantees for other developers, but those of us who
are careful about our application development would like the option
to eliminate completely unused features from the kernel. (And
the C library, but that's a different issue.)
> And don't answer "doesn't use flock()", I want a real-life example of a
> device where you could guarantee a developer that disabling this option
> in his product would be safe.
I'm not sure why a guarantee is required that other developers
use this option safely. Maybe this is a point of disconnect between
embedded folks and non-embedded folks. We're accustomed to making
tradeoff decisions that only affect our product, and which
we take full responsibility for testing.
If warnings or support avoidance for the general population using
such config options is the issue, I think that David Woodhouse's
suggestion that such things could taint the kernel is an interesting
idea. Maybe have we could have an "unsafe-config" taint flag?
I should add that I am sympathetic with the larger issue you raise
about nibbling at the bottom with patches that only address a
few KB of the problem, while the size continues to build (to an
even greater degree) with each release. My response is that I agree
with you on the nibbling bit, but probably just at a different
level of KB savings.
That is, I presume you'd be OK with something that saved 100K or
even 20K, but balk at bit at these patches, which save 10k or less.
My threshold is lower (probably down to about 5K, so these are
pretty close to the bubble), but even I wouldn't recommend
applying anything much below that. We've already started
considering to drop some linux-tiny patches that just don't save
enough to warrant continued maintenance.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: [patch 0/4] [resend] Add configuration options to disable features not needed on embedded devices
From: Tim Bird @ 2008-07-31 17:59 UTC (permalink / raw)
To: David Miller
Cc: dwmw2, torvalds, thomas.petazzoni, linux-kernel, linux-embedded,
michael
In-Reply-To: <20080731.032553.67275433.davem@davemloft.net>
David Miller wrote:
> Some folks might find it instructive to do a google code search
> or similar on the multicast socket options this things dikes out
> of the tree.
>
> Even simple things like NTP will spew failures with this CONFIG_IGMP
> thing turned off. And that's just the tip of the iceberg.
I don't know of any embedded products that ship with NTP turned
on. It's best to assume, with embedded, that we're not shipping
ANY of the desktop or server applications you are familiar with.
Absent those, does something break in the kernel with multicast
support when IGMP is turned off?
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: [patch 2/4] Configure out file locking features
From: Robert Schwebel @ 2008-07-31 18:12 UTC (permalink / raw)
To: Tim Bird
Cc: Adrian Bunk, Thomas Petazzoni, linux-kernel, linux-embedded,
michael, Matt Mackall, matthew, linux-fsdevel, akpm
In-Reply-To: <4891F724.3030406@am.sony.com>
On Thu, Jul 31, 2008 at 10:32:20AM -0700, Tim Bird wrote:
> > And for embedded systems with which applications is it 100% safe to
> > disable this option?
>
> Sony's digital cameras.
We have also several very small automation & measurement devices in the
field which run a very dedicated more or less single application which
can be carefully audited.
In the OSADL safety working group, people are discussing about Linux for
safety critical applications. If we want to achieve such scenarios,
stripped-down systems are an absolute must.
Although increasing processor power even in embedded applications lead
to more and more standard-line kernels plus normal userspace components
(i.e. glibc instead of uclibc), there are still applications where the
final product consists only of the kernel plus the app, whereas during
development time, the system has a full-blown configuration.
rsc
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: [patch 0/4] [resend] Add configuration options to disable features
From: Ulrich Teichert @ 2008-07-31 18:50 UTC (permalink / raw)
To: Tim Bird
Cc: David Miller, dwmw2, torvalds, thomas.petazzoni, linux-kernel,
linux-embedded, michael
In-Reply-To: <4891FD95.7090700@am.sony.com>
Hi,
>I don't know of any embedded products that ship with NTP turned
>on.
Well, I do. To be exact, I've developed parts of it. But it's numbers
are only into the thousands, so that makes it insignificant ;-)
>It's best to assume, with embedded, that we're not shipping
>ANY of the desktop or server applications you are familiar with.
>Absent those, does something break in the kernel with multicast
>support when IGMP is turned off?
I do not think of NTP as desktop or server application, but that's
probably just me,
CU,
Uli
--
Dipl. Inf. Ulrich Teichert|e-mail: Ulrich.Teichert@gmx.de | Listening to:
Stormweg 24 |Pale Bride (The Von Bondies), No Time (Statues),
24539 Neumuenster, Germany|Am Strand (Smoke Blow), Sacred Decay (The Estranged)
^ permalink raw reply
* Re: [patch 2/4] Configure out file locking features
From: Adrian Bunk @ 2008-07-31 19:16 UTC (permalink / raw)
To: Tim Bird
Cc: Thomas Petazzoni, linux-kernel, linux-embedded, michael,
Matt Mackall, matthew, linux-fsdevel, akpm
In-Reply-To: <4891F724.3030406@am.sony.com>
On Thu, Jul 31, 2008 at 10:32:20AM -0700, Tim Bird wrote:
> Adrian Bunk wrote:
> > And for embedded systems with which applications is it 100% safe to
> > disable this option?
>
> Sony's digital cameras.
>
> This option *is* disabled in the kernel for (most) Sony digital cameras.
> Those digital cameras have the kernel, busybox, a custom C library,
> and one proprietary application. The application does not use
> flock() (or AIO, or ethtool or multi-cast)
>
> These cameras were heavily tested, and are shipping now. I can't
> make any guarantees for other developers, but those of us who
> are careful about our application development would like the option
> to eliminate completely unused features from the kernel. (And
> the C library, but that's a different issue.)
>
> > And don't answer "doesn't use flock()", I want a real-life example of a
> > device where you could guarantee a developer that disabling this option
> > in his product would be safe.
>
> I'm not sure why a guarantee is required that other developers
> use this option safely. Maybe this is a point of disconnect between
> embedded folks and non-embedded folks. We're accustomed to making
> tradeoff decisions that only affect our product, and which
> we take full responsibility for testing.
Thanks. That's quite different from Thomas' "In practice, I only tested
a CONFIG_FILE_LOCKING=n kernel with a basic Busybox under Qemu." and
addresses my concerns.
In case I didn't express myself clearly:
I was not interested in guarantees for random developers but in seeing
some reasonable use case for a real device.
> If warnings or support avoidance for the general population using
> such config options is the issue, I think that David Woodhouse's
> suggestion that such things could taint the kernel is an interesting
> idea. Maybe have we could have an "unsafe-config" taint flag?
A CONFIG_EMBEDDED=y flag?
> I should add that I am sympathetic with the larger issue you raise
> about nibbling at the bottom with patches that only address a
> few KB of the problem, while the size continues to build (to an
> even greater degree) with each release. My response is that I agree
> with you on the nibbling bit, but probably just at a different
> level of KB savings.
>
> That is, I presume you'd be OK with something that saved 100K or
> even 20K, but balk at bit at these patches, which save 10k or less.
> My threshold is lower (probably down to about 5K, so these are
> pretty close to the bubble), but even I wouldn't recommend
> applying anything much below that. We've already started
> considering to drop some linux-tiny patches that just don't save
> enough to warrant continued maintenance.
It's not only about limits, I also have a general dislike for the
"add more config options" approach.
I get your point why it brings advantages in some cases, but if you are
looking for a cheerleader it won't be me. ;-)
> -- Tim
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [patch 2/4] Configure out file locking features
From: Adrian Bunk @ 2008-07-31 19:31 UTC (permalink / raw)
To: Robert Schwebel
Cc: Tim Bird, Thomas Petazzoni, linux-kernel, linux-embedded, michael,
Matt Mackall, matthew, linux-fsdevel, akpm
In-Reply-To: <20080731181214.GD8254@pengutronix.de>
On Thu, Jul 31, 2008 at 08:12:14PM +0200, Robert Schwebel wrote:
> On Thu, Jul 31, 2008 at 10:32:20AM -0700, Tim Bird wrote:
> > > And for embedded systems with which applications is it 100% safe to
> > > disable this option?
> >
> > Sony's digital cameras.
>
> We have also several very small automation & measurement devices in the
> field which run a very dedicated more or less single application which
> can be carefully audited.
>
> In the OSADL safety working group, people are discussing about Linux for
> safety critical applications. If we want to achieve such scenarios,
> stripped-down systems are an absolute must.
>...
My first reaction is that as soon as you enable CONFIG_EMBEDDED you can
easily enter codepaths noone else has used for a while and that got
unnoticed broken.
> rsc
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [patch 0/4] [resend] Add configuration options to disable features
From: Josh Boyer @ 2008-07-31 19:46 UTC (permalink / raw)
To: Ulrich Teichert
Cc: Tim Bird, David Miller, dwmw2, torvalds, thomas.petazzoni,
linux-kernel, linux-embedded, michael
In-Reply-To: <200807311850.m6VIoqCE015883@arbas.nms.ulrich-teichert.org>
On Thu, 2008-07-31 at 20:50 +0200, Ulrich Teichert wrote:
> Hi,
>
> >I don't know of any embedded products that ship with NTP turned
> >on.
>
> Well, I do. To be exact, I've developed parts of it. But it's numbers
> are only into the thousands, so that makes it insignificant ;-)
>
> >It's best to assume, with embedded, that we're not shipping
> >ANY of the desktop or server applications you are familiar with.
> >Absent those, does something break in the kernel with multicast
> >support when IGMP is turned off?
>
> I do not think of NTP as desktop or server application, but that's
> probably just me,
No, it's not just you. NTP is useful in cases where things do care
about time but hardware designers were too cheap to put an RTC on the
board.
I will admit that it's use in embedded products is probably very limited
though.
josh
^ permalink raw reply
* Re: [patch 0/4] [resend] Add configuration options to disable features
From: David Woodhouse @ 2008-07-31 19:55 UTC (permalink / raw)
To: Josh Boyer
Cc: Ulrich Teichert, Tim Bird, David Miller, torvalds,
thomas.petazzoni, linux-kernel, linux-embedded, michael
In-Reply-To: <1217533588.2328.1.camel@localhost.localdomain>
On Thu, 2008-07-31 at 15:46 -0400, Josh Boyer wrote:
> On Thu, 2008-07-31 at 20:50 +0200, Ulrich Teichert wrote:
> > Hi,
> >
> > >I don't know of any embedded products that ship with NTP turned
> > >on.
> >
> > Well, I do. To be exact, I've developed parts of it. But it's numbers
> > are only into the thousands, so that makes it insignificant ;-)
> >
> > >It's best to assume, with embedded, that we're not shipping
> > >ANY of the desktop or server applications you are familiar with.
> > >Absent those, does something break in the kernel with multicast
> > >support when IGMP is turned off?
> >
> > I do not think of NTP as desktop or server application, but that's
> > probably just me,
>
> No, it's not just you. NTP is useful in cases where things do care
> about time but hardware designers were too cheap to put an RTC on the
> board.
>
> I will admit that it's use in embedded products is probably very limited
> though.
NTP is a red herring. It has a check for multicast support in its
configure script and wraps it all in #ifdef MCAST anyway.
So even if it _does_ crap out when I build my standard distro kernel
with !CONFIG_IGMP and use the standard distro build of ntpd, that still
isn't particularly relevant to the kind of application where someone
would built a kernel without IGMP support and build their own ntpd to
match.
--
dwmw2
^ permalink raw reply
* Re: [patch 2/4] Configure out file locking features
From: Tim Bird @ 2008-07-31 20:37 UTC (permalink / raw)
To: Adrian Bunk
Cc: Thomas Petazzoni, linux-kernel, linux-embedded, michael,
Matt Mackall, matthew, linux-fsdevel, akpm
In-Reply-To: <20080731191650.GA23516@cs181140183.pp.htv.fi>
Adrian Bunk wrote:
> On Thu, Jul 31, 2008 at 10:32:20AM -0700, Tim Bird wrote:
>> If warnings or support avoidance for the general population using
>> such config options is the issue, I think that David Woodhouse's
>> suggestion that such things could taint the kernel is an interesting
>> idea. Maybe have we could have an "unsafe-config" taint flag?
>
> A CONFIG_EMBEDDED=y flag?
If this is sufficient, it works for me!
> It's not only about limits, I also have a general dislike for the
> "add more config options" approach.
>
> I get your point why it brings advantages in some cases, but if you are
> looking for a cheerleader it won't be me. ;-)
Understood. I promise not to send you any pom-poms. ;-)
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: [patch 1/4] Configure out AIO support
From: Bernhard Fischer @ 2008-07-31 22:42 UTC (permalink / raw)
To: Adrian Bunk
Cc: Thomas Petazzoni, linux-kernel, linux-embedded, michael,
Matt Mackall, bcrl, linux-aio, akpm
In-Reply-To: <20080731101219.GC4221@cs181140183.pp.htv.fi>
On Thu, Jul 31, 2008 at 01:12:19PM +0300, Adrian Bunk wrote:
>On Thu, Jul 31, 2008 at 12:09:29PM +0200, Bernhard Fischer wrote:
>> On Thu, Jul 31, 2008 at 11:27:04AM +0200, Thomas Petazzoni wrote:
>> >This patchs adds the CONFIG_AIO option which allows to remove support
>> >for asynchronous I/O operations, that are not necessarly used by
>> >applications, particularly on embedded devices. As this is a
>> >size-reduction option, it depends on CONFIG_EMBEDDED. It allows to
>> >save ~7 kilobytes of kernel code/data:
>>
>> Shouldn't this also make sure not to install aio_abi.h or at least an
>> empty aio_abi.h?
>
>The userspace headers are independent of any kernel configuration
>(except for the architecture).
I beg to disagree:
internals as exposed by e.g. aio_abi.h are impl dependent. Noone except
the impl and it's users are interrested in it.
If a per package feature, independent of arch, is off, all respective
features stuff should be off for that particular installation.
I.e. if I, for subsequent installations, choose to turn on feature, the
requested feature-stuff will be installed properly. If I, OTOH, choose
to (keep to) turn off feature, then all feature-related stuff should --
and has to be and stay -- turned off.
In the particular case of the kernel exposing unwanted API extensions
that are off, all such API reminiscences should be off, thus not
installed to my staging dir at all since i explicitely asked for doing
away with all of the API.
From a libc POV i'd agree, but from an inherently broken userspace POV
installing willingly broken stuff is just wrong and misleading, imo.
^ permalink raw reply
* Re: AT91 kernel programming documentation ?
From: Stefan Schoenleitner @ 2008-08-01 6:36 UTC (permalink / raw)
To: Robert Schwebel; +Cc: linux-embedded
In-Reply-To: <20080730140113.GY8254@pengutronix.de>
Hi,
Robert Schwebel wrote:
> [...]
>
>> Now I would like to add different hardware to the board and write some
>> kernel code for it.
>
> What kind of hardware?
An audio codec (TLV320AIC23B) connected to the I2C and I2S (over Atmel SSC) bus.
There seems to be a codec driver already (drivers/media/video/tlv320aic23b.c)
though it looks like I'll have to modify the driver a bit to support other
sampling rates as well.
Currently my first goal is to get the audio codec up and running so that it
works with ALSA.
Then I would like to add two SPI devices as well.
Since most of the chipselect lines are already used I was thinking of using a
demultiplexer which is supported by the AT91SAM9260.
Due to the fact that the board will be a custom design, I guess I will also have
to write a board implementation (i.e. arch/arm/mach-at91/board-<myboardname>.c)
so that the kernel for example knows which ports are used for communication
buses on the pins.
Reading the source code already shed a little light on how things are done.
>
>> Unfortunately, there doesn't seem to be a lot of documentation. At
>> the moment I'm reading mach-at91 related source code and trying to
>> find out how things work.
>
> I assume you've already bought a copy of the Rubini Device Driver book?
I read various papers and kernel documentation, parts of it also being from the
second edition of the book.
However, I just saw that there's a newer (third edition) available.
It's online under a CC license: http://lwn.net/Kernel/LDD3/
However, although the book gives a good intoduction on writing drivers, it seems
to miss some parts like SPI, I2C, board implementation and such.
IMHO the best way is to use the book as reference for driver implementation and
to read the existing AT91 kernel code.
>> Specificly, I would like to know how the different SoC devices can be
>> accessed and used, how I can do port multiplexing, how I can tell the
>> kernel which hardware is attached to where and so on.
>
> Check arch/arm/mach-at91/*. It very much depends on what you want to do.
> Documentation/drivermodel/ might also be worth a look.
arch/arm/mach-at91 is where I looked at the source most of the time.
However, I didn't notice Documentation/drivermodel until now.
Thank you for mentioning it.
^ permalink raw reply
* Re: [patch 0/4] [resend] Add configuration options to disable features
From: Robert Schwebel @ 2008-08-01 7:17 UTC (permalink / raw)
To: Josh Boyer
Cc: Ulrich Teichert, Tim Bird, David Miller, dwmw2, torvalds,
thomas.petazzoni, linux-kernel, linux-embedded, michael
In-Reply-To: <1217533588.2328.1.camel@localhost.localdomain>
On Thu, Jul 31, 2008 at 03:46:28PM -0400, Josh Boyer wrote:
> > I do not think of NTP as desktop or server application, but that's
> > probably just me,
>
> No, it's not just you. NTP is useful in cases where things do care
> about time but hardware designers were too cheap to put an RTC on the
> board.
Yes, we also have such customer systems, i.e. one which is used in a
Telemetry application where you can have hundrets of PXA270 data
concentrators that collect data from FPGAs and push them to a PC via
ethernet. As the system does not work without the PC, the hardware
designers decided that they can save hundrets of RTCs.
Or another autonomous data collection system where only one system of
several tens has an RTC...
We used chrony in these cases, as the standard ntputils seem to be
optimized for scenarios where you have permanent network connection,
which is often not the case in embedded applications.
rsc
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: [patch 2/4] Configure out file locking features
From: Robert Schwebel @ 2008-08-01 7:28 UTC (permalink / raw)
To: Adrian Bunk
Cc: Robert Schwebel, Tim Bird, Thomas Petazzoni, linux-kernel,
linux-embedded, michael, Matt Mackall, matthew, linux-fsdevel,
akpm
In-Reply-To: <20080731193126.GB23516@cs181140183.pp.htv.fi>
On Thu, Jul 31, 2008 at 10:31:26PM +0300, Adrian Bunk wrote:
> > In the OSADL safety working group, people are discussing about Linux
> > for safety critical applications. If we want to achieve such
> > scenarios, stripped-down systems are an absolute must.
> >...
>
> My first reaction is that as soon as you enable CONFIG_EMBEDDED you
> can easily enter codepaths noone else has used for a while and that
> got unnoticed broken.
That may be no problem; if we ever come to a safety kernel, it will have
to be audited and carefully tested anyway.
rsc
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Book about embedded-type device drivers
From: Thomas Petazzoni @ 2008-08-01 8:42 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <4892AF01.7040205@gmail.com>
Le Fri, 01 Aug 2008 08:36:49 +0200,
Stefan Schoenleitner <dev.c0debabe@gmail.com> a écrit :
> I read various papers and kernel documentation, parts of it also
> being from the second edition of the book.
> However, I just saw that there's a newer (third edition) available.
> It's online under a CC license: http://lwn.net/Kernel/LDD3/
The 3rd edition is certainly newer than the second, but starts to be
quite old. It has been written against the 2.6.10/2.6.11 kernels.
> However, although the book gives a good intoduction on writing
> drivers, it seems to miss some parts like SPI, I2C, board
> implementation and such. IMHO the best way is to use the book as
> reference for driver implementation and to read the existing AT91
> kernel code.
In addition to « Linux Device Drivers », a good book is « Essential
Linux Device Drivers », from Sreekrishnan Venkateswaran, available at
Prentice Hall. This book is very recent (April 2008).
1. Introduction
2. A peek inside the kernel (timers, concurrency, memory, etc.)
3. Kernel facilities (threads, helper interfaces)
4. Laying the groundwork (IRQ, device model, memory barriers, etc.)
5. Character drivers
6. Serial drivers (including TTY drivers and line discipline drivers)
7. Input drivers (evdev interface, serio, keyboard, mice, touch
controllers, accelerometers, etc.)
8. I2C (I2C core, EEPROM driver, RTC driver, i2c-dev, SPI, 1-wire)
9. PCMCIA and Compact Flash
10. PCI
11. USB
12. Video drivers (frame buffer, console drivers)
13. Audio drivers
14. Block drivers
15. Network interface cards
16. Linux without wires (Bluetooth, Infrared, Wifi)
17. MTD
18. Embedded Linux
19. Drivers in userspace
20. More devices and drivers
21. Debugging device drivers
22. Maintenance and delivery
23. Shutting Down
I'm at the end of chapter 8, and until now, it's really good.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: Book about embedded-type device drivers
From: Markus Franke @ 2008-08-01 9:13 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: linux-embedded
In-Reply-To: <20080801104210.462583ee@surf>
Hi,
Thomas Petazzoni schrieb:
> In addition to « Linux Device Drivers », a good book is « Essential
> Linux Device Drivers », from Sreekrishnan Venkateswaran, available at
> Prentice Hall. This book is very recent (April 2008).
thank you very much for the hint. LDD3 is indeed a bit outdated and I
also missed a chapter about I2C device driver development.
Best regards,
Markus
^ permalink raw reply
* Re: [PATCH 2/6] Container Freezer: Make refrigerator always available
From: Thomas Petazzoni @ 2008-08-01 14:27 UTC (permalink / raw)
To: Matt Helsley
Cc: Andrew Morton, Rafael J. Wysocki, Paul Menage, Li Zefan,
Linux-Kernel, Linux Containers, linux-pm, Cedric Le Goater,
Serge E. Hallyn, Michael Opdenacker, linux-embedded
In-Reply-To: <20080801050700.528446138@us.ibm.com>
Hi,
Le Thu, 31 Jul 2008 22:07:01 -0700,
Matt Helsley <matthltc@us.ibm.com> a écrit :
> --- a/kernel/Makefile
> +++ b/kernel/Makefile
> @@ -5,7 +5,7 @@
> obj-y = sched.o fork.o exec_domain.o panic.o printk.o \
> cpu.o exit.o itimer.o time.o softirq.o resource.o \
> sysctl.o capability.o ptrace.o timer.o user.o \
> - signal.o sys.o kmod.o workqueue.o pid.o \
> + signal.o sys.o kmod.o workqueue.o pid.o freezer.o \
I have the impression that the code in kernel/power/process.c was
compiled only if CONFIG_PM_SLEEP was set. Now that the code has been
moved to kernel/freezer.c, it is unconditionnaly compiled in every
kernel. Is that correct ?
If so, is it possible to put this new feature under some
CONFIG_SOMETHING option, for people who care about the kernel size ?
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 2/6] Container Freezer: Make refrigerator always available
From: Matt Helsley @ 2008-08-01 19:08 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Andrew Morton, Rafael J. Wysocki, Paul Menage, Li Zefan,
Linux-Kernel, Linux Containers, linux-pm, Cedric Le Goater,
Serge E. Hallyn, Michael Opdenacker, linux-embedded
In-Reply-To: <20080801162712.63721e8c@surf>
On Fri, 2008-08-01 at 16:27 +-0200, Thomas Petazzoni wrote:
+AD4 Hi,
+AD4
+AD4 Le Thu, 31 Jul 2008 22:07:01 -0700,
+AD4 Matt Helsley +ADw-matthltc+AEA-us.ibm.com+AD4 a +AOk-crit :
+AD4
+AD4 +AD4 --- a/kernel/Makefile
+AD4 +AD4 +-+-+- b/kernel/Makefile
+AD4 +AD4 +AEAAQA -5,7 +-5,7 +AEAAQA
+AD4 +AD4 obj-y +AD0 sched.o fork.o exec+AF8-domain.o panic.o printk.o +AFw
+AD4 +AD4 cpu.o exit.o itimer.o time.o softirq.o resource.o +AFw
+AD4 +AD4 sysctl.o capability.o ptrace.o timer.o user.o +AFw
+AD4 +AD4 - signal.o sys.o kmod.o workqueue.o pid.o +AFw
+AD4 +AD4 +- signal.o sys.o kmod.o workqueue.o pid.o freezer.o +AFw
+AD4
+AD4 I have the impression that the code in kernel/power/process.c was
+AD4 compiled only if CONFIG+AF8-PM+AF8-SLEEP was set. Now that the code has been
+AD4 moved to kernel/freezer.c, it is unconditionnaly compiled in every
+AD4 kernel. Is that correct ?
+AD4
+AD4 If so, is it possible to put this new feature under some
+AD4 CONFIG+AF8-SOMETHING option, for people who care about the kernel size ?
How about making it depend on a combination of CONFIG variables?
Here's an RFC PATCH. Completely untested.
Signed-off-by: Matt Helsley +ADw-matthltc+AEA-us.ibm.com+AD4
---
kernel/Makefile +AHw 3 +-+--
kernel/power/Kconfig +AHw 3 +-+-+-
2 files changed, 5 insertions(+-), 1 deletion(-)
Index: linux-2.6.27-rc1-mm1/kernel/Makefile
+AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0
--- linux-2.6.27-rc1-mm1.orig/kernel/Makefile
+-+-+- linux-2.6.27-rc1-mm1/kernel/Makefile
+AEAAQA -5,7 +-5,7 +AEAAQA
obj-y +AD0 sched.o fork.o exec+AF8-domain.o panic.o printk.o +AFw
cpu.o exit.o itimer.o time.o softirq.o resource.o +AFw
sysctl.o capability.o ptrace.o timer.o user.o +AFw
- signal.o sys.o kmod.o workqueue.o pid.o freezer.o +AFw
+- signal.o sys.o kmod.o workqueue.o pid.o +AFw
rcupdate.o extable.o params.o posix-timers.o +AFw
kthread.o wait.o kfifo.o sys+AF8-ni.o posix-cpu-timers.o mutex.o +AFw
hrtimer.o rwsem.o nsproxy.o srcu.o semaphore.o +AFw
+AEAAQA -24,6 +-24,7 +AEAAQA CFLAGS+AF8-REMOVE+AF8-sched+AF8-clock.o +AD0 -pg
CFLAGS+AF8-REMOVE+AF8-sched.o +AD0 -mno-spe -pg
endif
+-obj-+ACQ(CONFIG+AF8-FREEZER) +-+AD0 freezer.o
obj-+ACQ(CONFIG+AF8-PROFILING) +-+AD0 profile.o
obj-+ACQ(CONFIG+AF8-SYSCTL+AF8-SYSCALL+AF8-CHECK) +-+AD0 sysctl+AF8-check.o
obj-+ACQ(CONFIG+AF8-STACKTRACE) +-+AD0 stacktrace.o
Index: linux-2.6.27-rc1-mm1/kernel/power/Kconfig
+AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0
--- linux-2.6.27-rc1-mm1.orig/kernel/power/Kconfig
+-+-+- linux-2.6.27-rc1-mm1/kernel/power/Kconfig
+AEAAQA -85,6 +-85,9 +AEAAQA config PM+AF8-SLEEP
depends on SUSPEND +AHwAfA HIBERNATION +AHwAfA XEN+AF8-SAVE+AF8-RESTORE
default y
+-config FREEZER
+- def+AF8-bool PM+AF8-SLEEP +AHwAfA CGROUP+AF8-FREEZER
+-
config SUSPEND
bool +ACI-Suspend to RAM and standby+ACI
depends on PM +ACYAJg ARCH+AF8-SUSPEND+AF8-POSSIBLE
^ permalink raw reply
* Re: [patch 0/4] [resend] Add configuration options to disable features
From: Linus Torvalds @ 2008-08-01 19:15 UTC (permalink / raw)
To: Josh Boyer
Cc: Ulrich Teichert, Tim Bird, David Miller, dwmw2, thomas.petazzoni,
linux-kernel, linux-embedded, michael
In-Reply-To: <1217533588.2328.1.camel@localhost.localdomain>
On Thu, 31 Jul 2008, Josh Boyer wrote:
> On Thu, 2008-07-31 at 20:50 +0200, Ulrich Teichert wrote:
> >
> > I do not think of NTP as desktop or server application, but that's
> > probably just me,
>
> No, it's not just you. NTP is useful in cases where things do care
> about time but hardware designers were too cheap to put an RTC on the
> board.
In fact, didn't one of the netgear firewall/switch/routers end up being
famous for overloading some NTP service exactly because all the _millions_
of routers ended up using the same (incorrect) NTP host?
So NTP is very definitely an embedded thing too.
Linus
^ permalink raw reply
* Re: [patch 4/4] Configure out IGMP support
From: David Woodhouse @ 2008-08-01 19:41 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: linux-kernel, linux-embedded, michael, Matt Mackall, netdev,
davem, akpm
In-Reply-To: <20080731093221.565015353@free-electrons.com>
On Thu, 2008-07-31 at 11:27 +0200, Thomas Petazzoni wrote:
> This patchs adds the CONFIG_IGMP option which allows to remove support
> for the Internet Group Management Protocol, used in
> multicast. Multicast is not necessarly used by applications,
> particularly on embedded devices. As this is a size-reduction option,
> it depends on CONFIG_EMBEDDED. It allows to save ~10 kilobytes of
> kernel code/data:
The config option probably lives in net/Kconfig, not init/Kconfig.
And please could you make it clear how this interacts with IP_MULTICAST?
We already have a CONFIG_IP_MULTICAST option, for which the help text
says "For more people, it's safe to say N'. And I think it defaults to
that too. What more does CONFIG_IGMP remove? It's not made clear by the
help text.
--
dwmw2
^ permalink raw reply
* Re: [patch 0/4] [resend] Add configuration options to disable features
From: David Woodhouse @ 2008-08-01 19:47 UTC (permalink / raw)
To: Linus Torvalds
Cc: Josh Boyer, Ulrich Teichert, Tim Bird, David Miller,
thomas.petazzoni, linux-kernel, linux-embedded, michael
In-Reply-To: <alpine.LFD.1.10.0808011212430.3277@nehalem.linux-foundation.org>
On Fri, 2008-08-01 at 12:15 -0700, Linus Torvalds wrote:
>
> On Thu, 31 Jul 2008, Josh Boyer wrote:
> > On Thu, 2008-07-31 at 20:50 +0200, Ulrich Teichert wrote:
> > >
> > > I do not think of NTP as desktop or server application, but that's
> > > probably just me,
> >
> > No, it's not just you. NTP is useful in cases where things do care
> > about time but hardware designers were too cheap to put an RTC on the
> > board.
>
> In fact, didn't one of the netgear firewall/switch/routers end up being
> famous for overloading some NTP service exactly because all the _millions_
> of routers ended up using the same (incorrect) NTP host?
>
> So NTP is very definitely an embedded thing too.
And it's _still_ a red herring.
I just booted a !CONFIG_IGMP kernel on my workstation and NTP is running
just fine (as is IPv6).
Even though ntpd has a configure test for multicast and can be built
without multicast support at all, it isn't even necessary to build it
that way -- the stock Fedora build of it works just fine.
(Actually, I never managed to get ntpd to work _with_ multicast, but
that's a different issue... :)
--
dwmw2
^ permalink raw reply
* [PATCH] embedded: fix vc_translate operator precedence
From: Tim Bird @ 2008-08-01 21:05 UTC (permalink / raw)
To: linux-embedded; +Cc: linux kernel
This fixes a bug in operator precedence in the newly introduced vc_translate
macro. Without this fix, the translation of some characters on the
kernel console is garbled.
This patch was copied to the e-mail list previously for testing. Now,
all reports confirm that it works, so this is an official post for
application.
Signed-off-by: Tim Bird <tim.bird@am.sony.com>
---
vt_kern.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/vt_kern.h b/include/linux/vt_kern.h
index 14c0e91..8c8119f 100644
--- a/include/linux/vt_kern.h
+++ b/include/linux/vt_kern.h
@@ -74,7 +74,7 @@ void con_protect_unimap(struct vc_data *vc, int rdonly);
int con_copy_unimap(struct vc_data *dst_vc, struct vc_data *src_vc);
#define vc_translate(vc, c) ((vc)->vc_translate[(c) | \
- (vc)->vc_toggle_meta ? 0x80 : 0])
+ ((vc)->vc_toggle_meta ? 0x80 : 0)])
#else
#define con_set_trans_old(arg) (0)
#define con_get_trans_old(arg) (-EINVAL)
^ permalink raw reply related
* Re: conceptual map of the kernel source (Interactive Linux kernel map)
From: Linus Walleij @ 2008-08-01 22:07 UTC (permalink / raw)
To: Constantine Shulyupin, linux-embedded
In-Reply-To: <8aa6b0650807310644g10b8ce3dvd634d482cab659ea@mail.gmail.com>
2008/7/31 Constantine Shulyupin <const@linuxdriver.co.il>:
> I am updating the kernel map: http://www.makelinux.net/kernel_map
> It is conceptual map consisting of more than 200 most important kernel
> functions.
I was very impressed once I saw this map first, which was through
your (?) contributions to the Linux entries in Wikipedia. Keep up the
good work!
> Could you please have a look and suggest fixes and updates.
The embedded systems will be interested in most things not
asm-i386 and arch-i386. For example you show a lot of PCI
and such things in the lowest layers, I wonder if it'd be worth
the effort to make arch-specific views of the lowermost parts
(but probably not).
Another this is that flash drivers MTD, doesn't fit into the picture,
instead harddisk is uses as example.
Linus
^ permalink raw reply
* Re: conceptual map of the kernel source (Interactive Linux kernel map)
From: Constantine Shulyupin @ 2008-08-01 22:28 UTC (permalink / raw)
To: Linus Walleij; +Cc: linux-embedded
In-Reply-To: <63386a3d0808011507h28aa213mb27d32b2f855b9ac@mail.gmail.com>
Thank you for idea.
I wish to make map of embeedded Linux in future.
Now I focus on "generic" kernel.
On Sat, Aug 2, 2008 at 1:07 AM, Linus Walleij
<linus.ml.walleij@gmail.com> wrote:
> 2008/7/31 Constantine Shulyupin <const@linuxdriver.co.il>:
>
>> I am updating the kernel map: http://www.makelinux.net/kernel_map
>> It is conceptual map consisting of more than 200 most important kernel
>> functions.
>
> I was very impressed once I saw this map first, which was through
> your (?) contributions to the Linux entries in Wikipedia. Keep up the
> good work!
>
>> Could you please have a look and suggest fixes and updates.
>
> The embedded systems will be interested in most things not
> asm-i386 and arch-i386. For example you show a lot of PCI
> and such things in the lowest layers, I wonder if it'd be worth
> the effort to make arch-specific views of the lowermost parts
> (but probably not).
>
> Another this is that flash drivers MTD, doesn't fit into the picture,
> instead harddisk is uses as example.
>
> Linus
>
--
Constantine Shulyupin
Freelance Embedded Linux Engineer
054-4234440
http://www.linuxdriver.co.il/
^ permalink raw reply
* Re: [PATCH 2/6] Container Freezer: Make refrigerator always available
From: Rafael J. Wysocki @ 2008-08-01 22:53 UTC (permalink / raw)
To: Matt Helsley, Andrew Morton
Cc: Thomas Petazzoni, Paul Menage, Li Zefan, Linux-Kernel,
Linux Containers, linux-pm, Cedric Le Goater, Serge E. Hallyn,
Michael Opdenacker, linux-embedded
In-Reply-To: <1217617689.25300.213.camel@localhost.localdomain>
On Friday, 1 of August 2008, Matt Helsley wrote:
>
> On Fri, 2008-08-01 at 16:27 +-0200, Thomas Petazzoni wrote:
> > Hi,
> >
> > Le Thu, 31 Jul 2008 22:07:01 -0700,
> > Matt Helsley <matthltc@us.ibm.com> a +AOk-crit :
> >
> > > --- a/kernel/Makefile
> > > +-+-+- b/kernel/Makefile
> > > @@ -5,7 +-5,7 @@
> > > obj-y = sched.o fork.o exec_domain.o panic.o printk.o +AFw
> > > cpu.o exit.o itimer.o time.o softirq.o resource.o +AFw
> > > sysctl.o capability.o ptrace.o timer.o user.o +AFw
> > > - signal.o sys.o kmod.o workqueue.o pid.o +AFw
> > > +- signal.o sys.o kmod.o workqueue.o pid.o freezer.o +AFw
> >
> > I have the impression that the code in kernel/power/process.c was
> > compiled only if CONFIG_PM_SLEEP was set. Now that the code has been
> > moved to kernel/freezer.c, it is unconditionnaly compiled in every
> > kernel. Is that correct ?
> >
> > If so, is it possible to put this new feature under some
> > CONFIG_SOMETHING option, for people who care about the kernel size ?
>
> How about making it depend on a combination of CONFIG variables?
> Here's an RFC PATCH. Completely untested.
>
> Signed-off-by: Matt Helsley <matthltc@us.ibm.com>
Can you please also make the contents of include/linux/freezer.h depend on
CONFIG_FREEZER instead of CONFIG_PM_SLEEP?
Also, I'm not really sure if kernel/power/Kconfig is the right place to define
CONFIG_FREEZER.
Perhaps we should even move freezer.c from kernel/power to kernel
and define CONFIG_FREEZER in Kconfig in there. Andrew, what do you think?
> ---
> kernel/Makefile | 3 +-+--
> kernel/power/Kconfig | 3 +-+-+-
> 2 files changed, 5 insertions(+-), 1 deletion(-)
>
> Index: linux-2.6.27-rc1-mm1/kernel/Makefile
> ===================================================================
> --- linux-2.6.27-rc1-mm1.orig/kernel/Makefile
> +-+-+- linux-2.6.27-rc1-mm1/kernel/Makefile
> @@ -5,7 +-5,7 @@
> obj-y = sched.o fork.o exec_domain.o panic.o printk.o +AFw
> cpu.o exit.o itimer.o time.o softirq.o resource.o +AFw
> sysctl.o capability.o ptrace.o timer.o user.o +AFw
> - signal.o sys.o kmod.o workqueue.o pid.o freezer.o +AFw
> +- signal.o sys.o kmod.o workqueue.o pid.o +AFw
> rcupdate.o extable.o params.o posix-timers.o +AFw
> kthread.o wait.o kfifo.o sys_ni.o posix-cpu-timers.o mutex.o +AFw
> hrtimer.o rwsem.o nsproxy.o srcu.o semaphore.o +AFw
> @@ -24,6 +-24,7 @@ CFLAGS_REMOVE_sched_clock.o = -pg
> CFLAGS_REMOVE_sched.o = -mno-spe -pg
> endif
>
> +-obj-$(CONFIG_FREEZER) +-= freezer.o
> obj-$(CONFIG_PROFILING) +-= profile.o
> obj-$(CONFIG_SYSCTL_SYSCALL_CHECK) +-= sysctl_check.o
> obj-$(CONFIG_STACKTRACE) +-= stacktrace.o
> Index: linux-2.6.27-rc1-mm1/kernel/power/Kconfig
> ===================================================================
> --- linux-2.6.27-rc1-mm1.orig/kernel/power/Kconfig
> +-+-+- linux-2.6.27-rc1-mm1/kernel/power/Kconfig
> @@ -85,6 +-85,9 @@ config PM_SLEEP
> depends on SUSPEND || HIBERNATION || XEN_SAVE_RESTORE
> default y
>
> +-config FREEZER
> +- def_bool PM_SLEEP || CGROUP_FREEZER
> +-
> config SUSPEND
> bool "Suspend to RAM and standby"
> depends on PM && ARCH_SUSPEND_POSSIBLE
>
>
>
>
>
\0^[¹þÿ\a°þÿ\0¦þÿ\0Ÿþÿ\0˜þÿ\0þÿ\0`âÿ \x1f#: \x1f#' \x1f#\x12 \x1f#\x05ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ýýûXÓÌÎÿýýüÿýýüÿÍÆÉÿýýûÿýýüÿýýûÿÑÊÍÿòîïÿýýüÿýýüÿþþýÿÔÍÐÿÕÏÒÿðèéÿöïïÿöïðÿöïïÿöïïÿͼ¿ÿn}‘ÿ\0Fƒÿ0ˆµÿ8¡Õÿ@³îÿE¿úÿ•ìþÿ@Íþÿ1Åþÿ\x1dºþÿ
°þÿ\0«þÿ\0¢þÿ\0™þÿ\0þÿ\0‡þÿ\0Zàÿ \x1f#A \x1f#/ \x1f#\x17 \x1f#\aÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0þþý\x06ýýûâÔÍÏÿüüúÿÎÇÊÿüûúÿüûúÿüûúÿüûúÿÒËÎÿóîîÿýýüÿÔÍÐÿÕÎÑÿõññÿùôôÿôìíÿõîïÿõíîÿôììÿíãäÿ©˜Ÿÿ%r™ÿ\0-oÿ\0Kÿ7§Þÿ=·ôÿD¿üÿŽéþÿ4Åþÿ!¼þÿ\x0f´þÿ\0¬þÿ\0£þÿ\0›þÿ\0’þÿ\0‹þÿ\0\x7fþÿ\0Wâÿ \x1f#D \x1f#2 \x1f#\x19 \x1f#\bÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0üüúvÓÌÎÿñììÿüûúÿÏÇÊÿüûúÿüûúÿüûúÿüûúÿÓÌÏÿóîîÿÔÍÐÿôïðÿüûúÿöððÿòéêÿôìíÿôììÿòèèÿôììÿ¾«ÿp}‘ÿ!q›ÿ\06sÿ\09~ÿ\0\³ÿ:ºùÿ?¿þÿ…åþÿ%¿þÿ\x13¶þÿ\0¬þÿ\0¤þÿ\0œþÿ\0”þÿ\0‹þÿ\0þÿ\0zþÿ\0Sâÿ \x1f#D \x1f#3 \x1f#\x1a \x1f#\bÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0üüú\x15ÓÌÎùÖÏÑÿûúøÿÏÇÊÿûúøÿûúùÿûúøÿûúùÿûûùÿÓÌÏÿòíîÿýýûÿú÷öÿôìíÿñçèÿóêëÿòèéÿðååÿñèçÿáÔÕÿ’vxÿ\x1em•ÿ\x1fsŸÿ\07vÿ\0Fvÿ\0Gœÿ\0gÉÿ;»þÿ{ßþÿ\x17¸þÿ\x03¬þÿ\0¥þÿ\0žþÿ\0•þÿ\0Žþÿ\0‚þÿ\0{þÿ\0rþÿ\0Pàÿ \x1f#D \x1f#3 \x1f#\x1a \x1f#\bÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ûúøœÔÍÏÿðêêÿúù÷ÿÏÇÊÿúø÷ÿúø÷ÿûúøÿûúøÿûúøÿÕÍÐÿòííÿöñðÿñçèÿñæçÿñçèÿñææÿîââÿðååÿñèçÿ•—ÿorÿ\x19mšÿ\x1au¤ÿa§ÿ\0Dxÿ\0Zœÿ\0P®ÿ\0kÎÿsÛþÿ\x05®þÿ\0¦þÿ\0žþÿ\0–þÿ\0Žþÿ\0…þÿ\0}þÿ\0tþÿ\0lþÿ\0Màÿ \x1f#D \x1f#3 \x1f#\x1a \x1f#\bÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ûûø.ÔÍÏýÖÏÑÿúøöÿúøöÿúøöÿúøöÿúøöÿúø÷ÿúù÷ÿúù÷ÿÓÉÌÿéÝßÿïãäÿðåæÿðåæÿîââÿíààÿïããÿðæåÿàÓÓÿ‘vxÿ\x16i•ÿ\x15ožÿ\x19wªÿ\x19ƒ¿ÿr¦Äÿ\0Uœÿ\0f³ÿ\0T¶ÿ\0tâÿ\0pâÿ\0lâÿ\0hâÿ\0dâÿ\0`àÿ\0Zâÿ\0Vâÿ\0Ràÿ\0Màÿ\0?Åÿ \x1f#D \x1f#3 \x1f#\x1a \x1f#\bÿÿÿ\0ÿÿÿ\0ÿÿÿ\0úùö½×ÐÒÿïêéÿúøöÿù÷õÿúøöÿúøöÿúøöÿúøöÿ÷òñÿòééÿÒÂÆÿå×ÙÿïãäÿîáâÿëÜÜÿìÞÞÿíßßÿîââÿïäãÿ¯–˜ÿmo€ÿ\x11jšÿ\x12p£ÿ\x14z±ÿ\x16‡Åÿ^[–Ýÿ\x7f¼âÿ\0a³ÿ\0mÂÿ\0Úÿ\0‚Ýÿ\0‰éÿ\0’òÿ\0˜úÿ\0œþÿ\0Ÿþÿ\amÚÿLz•w \x1f#J \x1f#H \x1f#> \x1f#. \x1f#\x17 \x1f#\bÿÿÿ\0ÿÿÿ\0ù÷õS×ÐÒÿúùöÿøöóÿù÷ôÿù÷ôÿù÷ôÿù÷õÿöðïÿñççÿíàáÿíàáÿνÁÿàÐÒÿêÚÚÿêÚÚÿêÜÛÿëÝÜÿíàßÿíáàÿÝÏÏÿ’uxÿ\x10h—ÿ\x0ejžÿ\x0fr©ÿ\x13\x7f¹ÿ\x17ŒËÿ\x1c›àÿ §ôÿƒÉóÿ\0kÅÿ\0~Úÿ\0\x7fâÿ\0…ìÿ\0òÿ\0•üÿ\0˜þÿ\0œþÿ\0iÚÿ\amÛÿOz™t \x1f#? \x1f#3 \x1f#$ \x1f#\x11 \x1f#\x05ÿÿÿ\0÷õñ\x05÷õò׺°´ÿîçæÿøöóÿøõóÿöðïÿòêéÿïããÿëÜÝÿéÙÚÿèØÙÿè××ÿº¥©ÿÕÂÄÿéÙÙÿêÛÛÿêÜÛÿëÝÜÿìßÞÿíâàÿ®•–ÿjn€ÿ\x06fœÿ\bk£ÿ u°ÿ\r¿ÿ\x10ŒÏÿ\x1ašáÿ ©ôÿ+²ýÿ‡Îüÿ\0xÚÿ\0zßÿ\0‚éÿ\0Œõÿ\0‘üÿ\0•þÿ\0˜þÿ\0›þÿ\0zìÿ\ajÜÿWŒ®l \x1f#& \x1f#\x17 \x1f#
\x1f#\x03ÿÿÿ\0öôð\x17¶©«üÁ·¹ÿ¾°³ÿ»ª®ÿº¦ªÿ²šžÿ²™ÿ®•™ÿ«’–ÿ«’–ÿ¤ŠŽÿ®—šÿ¹¥©ÿÖÄÆÿéÚÙÿêÛÚÿëÝÜÿëÞÝÿìàÞÿÛÌÌÿ’txÿ\x05hŸÿ\x01hŸÿ\x03n©ÿ\x05x¸ÿ\f„Åÿ\x0eŽÒÿ\x18™âÿ!«ôÿ/·ýÿ8¹þÿ¾ýþÿ¸øþÿ°õþÿ©òþÿ îþÿ–éþÿåþÿ‡âþÿ\x7fÝþÿxÙþÿhÊþÿ \x1f#' \x1f#\x15 \x1f#\b \x1f#\x02ÿÿÿ\0˜†*˜†Ñµœ›ÿ¤„†ÿ \x7fÿ¥†ˆÿ¦‡‰ÿ§‰‹ÿº ¢ÿº ¢ÿÁ©«ÿì®ÿË·¸ÿÖÅÆÿ×ÇÇÿéÚÙÿêÛÚÿéÛÚÿêÞÜÿêÞÜÿ•–ÿg]|ÿ\0i¥ÿ\0h£ÿ\0q°ÿ\0{¾ÿ\x02ƒÉÿ\bŠÒÿ\x14™âÿ$©ôÿ4·ýÿ@¾þÿœïþÿPÑþÿ?Ëþÿ-Áþÿ^[¹þÿ\a°þÿ\0¦þÿ\0Ÿþÿ\0˜þÿ\0þÿ\0`âÿ \x1f#0 \x1f#\x1d \x1f#\f \x1f#\x03ÿÿÿ\0 \x1f#\x01q\S؉…üÔÀÂÿÜÉÊÿÜÉÊÿÛÈÉÿÛÉÉÿÜÊÊÿÜÊÊÿ¸¤¨ÿÖÅÅÿÞÍÍÿÝÍÍÿÞÏÎÿèÚØÿèÚØÿéÜÚÿêÝÛÿ×ÉÈÿ–uvù\x051ÿ\0i©ÿ\0jªÿ\0r·ÿ\0}Äÿ\0ƒÌÿ\0Q¬ÿ\x14™âÿ$«ôÿ2·ýÿFÀþÿ•ìþÿ@Íþÿ1Åþÿ\x1dºþÿ
°þÿ\0«þÿ\0¢þÿ\0™þÿ\0þÿ\0‡þÿ\0Zàÿ \x1f#< \x1f#* \x1f#\x14 \x1f#\x06ÿÿÿ\0 \x1f#\x01Q;0dq\SæÓ¼¼ÿàÎÎÿßÍÍÿßÍÍÿßÍÍÿÞÍÌÿßÎÎÿ¶¤§ÿÕÄÄÿÞÎÍÿßÏÎÿçØ×ÿèÚØÿèÚØÿèÚØÿéÜÙÿ©‘‘ÿ‡imÏ\00–ÿ\0k¯ÿ\0m²ÿ\0t¾ÿ\0}Èÿ\0„Ìÿ\04ÿ\0Q¯ÿ!©ôÿ4¸ýÿGÀþÿŽéþÿ4Åþÿ!¼þÿ\x0f´þÿ\0¬þÿ\0£þÿ\0›þÿ\0’þÿ\0‹þÿ\0\x7fþÿ\0Wâÿ \x1f#C \x1f#1 \x1f#\x18 \x1f#\bÿÿÿ\0\0\0\0\x01\x11\x11\x13\vV@5È£ŠˆýÖÄÄÿàÏÎÿáÐÏÿáÑÐÿãÒÑÿãÒÑÿ´¢¥ÿÓÃÃÿåÖÔÿçÙ×ÿæØÕÿæØÖÿæØÖÿæÙÖÿÔÅÄÿ•tuú+$&V\02˜ÿ\0m·ÿ\0p»ÿ\0xÄÿ\0|Ëÿ\0ƒÍÿ\0;”ÿ\05–ÿ\0ZÄÿ8¸ýÿPÂþÿ…åþÿ%¿þÿ\x13¶þÿ\0¬þÿ\0¤þÿ\0œþÿ\0”þÿ\0‹þÿ\0þÿ\0zþÿ\0Sâÿ \x1f#D \x1f#3 \x1f#\x1a \x1f#\bÿÿÿ\0ÿÿÿ\0\x10\x10\x12\b\x0f\x0e\x10\x1cw_YêÔ¿¾ÿàÏÎÿàÑÏÿáÑÐÿàÑÏÿáÒÐÿµ£¥ÿÓÄÃÿäÕÓÿäÖÓÿäÖÓÿãÖÓÿãÖÓÿãÖÓÿ¦ŽÿŠloÒ\x1f\x1e"J\03žÿ\0p¿ÿ\0qÂÿ\0wÈÿ\0}Ëÿ\0€Íÿ\0;–ÿ\0=˜ÿ\0=«ÿ\0eÐÿTÇþÿ{ßþÿ\x17¸þÿ\x03¬þÿ\0¥þÿ\0žþÿ\0•þÿ\0Žþÿ\0‚þÿ\0{þÿ\0rþÿ\0Pàÿ \x1f#D \x1f#3 \x1f#\x1a \x1f#\bÿÿÿ\0ÿÿÿ\0\v
\f\x03\x0f\x0f\x10\x11T?5¿ ˆ†ýåÖÔÿßÐÎÿßÐÎÿßÐÎÿßÐÎÿ²¡£ÿÑÂÁÿãÕÒÿãÕÒÿãÕÒÿáÔÐÿàÓÏÿÑÂÀÿ“rrù,%'V\x1f\x1e"E\05¤ÿ\0qÈÿ\0rÉÿ\0wËÿ\0zÌÿ\0~ÍÿQ™Ãÿ\0=ÿ\0L¸ÿ\0VËÿ\0lÖÿ\0xâÿ\0sâÿ\0oâÿ\0kâÿ\0fâÿ\0bâÿ\0[Öÿ\0Zâÿ\0Vâÿ\0Râÿ\0@Åÿ \x1f#D \x1f#3 \x1f#\x1a \x1f#\bÿÿÿ\0ÿÿÿ\0ÿÿÿ\0\x0e\r\x0f\a\r\r\x0e^[s[UéÒ¿½ÿÝÎÌÿÜÍÊÿÝÎÌÿÛÍÊÿ± ¡ÿ;½ÿàÒÎÿáÔÐÿÜÎËÿÞÐÍÿßÒÎÿ¥ŒŒÿ‰kmÖ\x1c^[\x1fO\x1d\x1c\x1fB\03¥ÿ\0tÏÿ\0uÍÿ\0wËÿ\0zÌÿ\0~Íÿ\0„Óÿf¬Úÿ\0L¼ÿ\0YÔÿ\0aßÿ\0zñÿ\0rñÿ\0töÿ\0}ýÿ\0„þÿ\0„þÿ\0pëÿ'çù \x1f#K \x1f#I \x1f#G \x1f#> \x1f#. \x1f#\x17 \x1f#\bÿÿÿ\0ÿÿÿ\0ÿÿÿ\0\x10\x10\x12\x02\x0e\r\x0f\x0eR=4¦œ†‚ýãÕÑÿÛÍÊÿÚËÉÿÚÌÉÿ®Ÿÿ˼ºÿÞÑÍÿÜÍÊÿÜÎÊÿÛÍÉÿÊ»¹ÿpoû!^[\x1dk\x16\x16\x19W1;Sa\r4’þ\fcÒþ\0uÐÿ\0uÌÿ\0uÌÿ\0|Íÿ\0ˆÓÿ\x14”âÿr½óÿ\0[Öÿ\0bàÿ\0iëÿ\0põÿ\0vøÿ\0}þÿ\0‚þÿ\0„þÿ\0oëÿ\x11lÙþ \x1f#I \x1f#C \x1f#; \x1f#0 \x1f#" \x1f#\x11 \x1f#\x05ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0\r\f\x0e\x05\r\r\x0f\x18pZRåκ¸ÿÙËÈÿ×ÈÅÿÖÇÄÿ¬›œÿȹ·ÿÙËÇÿÚËÇÿØÉÅÿØÉÅÿ¡‰ˆÿ„hiÝ\x12\x12\x14j\x12\x11\x13]\x0f\x0e\x10K-9S[\x116’ý\v^Ìþ\0sÌÿ\0wÌÿ\0|Íÿ\0‡Óÿ\x17™âÿ-«ôÿ~Ìýÿ\0bæÿ\0lïÿ\0röÿ\0xüÿ\0{þÿ\0þÿ\0‚þÿ\0„þÿ\0‰þÿ\x1cqÙüQˆÏÏ \x1f#- \x1f#\x1f \x1f#\x13 \x1f# \x1f#\x03ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0\x10\x10\x12\x02\r\r\x0f\fM:1†˜‚~ýÊ»¹ÿÔÅÂÿÔÅÂÿ©˜™ÿŶ´ÿØÉÅÿÔÅÁÿÓÅÀÿÄ´±ÿŽnmü^[\x17\x18v\x11\x10\x12i\x0f\x0e\x10[\v
\fI\b\a\b?%/CV\x137’ý
ZÇþ\0wÌÿ\0}Íÿ\x02ˆÓÿ\x1a™âÿ6±ôÿM¿ýÿ…Óþÿ\0môÿ\0r÷ÿ\0wþÿ\0~þÿ\0þÿ\0„þÿ\0‡þÿ\0‹þÿ\0Œþÿ\x1cqÙü \x1f#* \x1f#\x19 \x1f#\f \x1f#\x05 \x1f#\x01ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0\r\f\x0e\x05\r\r\x0e\x16jLDåɶ³ÿÒÿÿÐÁ¾ÿ¦•–ÿÁ²¯ÿÒÄ¿ÿѾÿÏÁ¼ÿœ„ƒÿƒefß\x11\x11\x13m\x10\x0f\x11c\r\r\x0eT\b\b C\x05\x04\x05:\x05\x05\x05<\x1d"1U\x169‘ý\bWÅÿ\0}Íÿ\0‡Óÿ\x1a™âÿ:³ôÿ[ÇýÿvÑþÿ¾ýþÿ¸øþÿ°õþÿ©òþÿ îþÿ–éþÿåþÿ‡âþÿ\x7fÝþÿxÙþÿhÊþÿ \x1f#! \x1f#\x10 \x1f#\x06 \x1f#\x01ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0\0\0\0\x01\x0f\x0e\x10\vP71gb]þó±ÿ̼¸ÿ¢’’ÿ¼®«ÿÏÀ»ÿ̽¸ÿ¼¬¨ÿŒljý^[\x17\x18v\x11\x10\x12i\x0f\x0e\x10\
\vJ\x05\x05\x06<\x02\x01\x025\x02\x02\x036\x06\x06\x06=\x15\x19!O\x1a<‘ü\aVÃÿ\0‡Óÿ\x1eœãÿ@µôÿbÊýÿ…ÚþÿœïþÿPÑþÿ?Ëþÿ-Áþÿ^[¹þÿ\a°þÿ\0¦þÿ\0Ÿþÿ\0˜þÿ\0þÿ\0`âÿ \x1f#0 \x1f#\x1c \x1f#\f \x1f#\x03ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0\x10\x10\x12\x04\x0e\r\x0f\x15fHAÌ®«ÿȸ´ÿ ÿºª§ÿȸ³ÿȹ³ÿ—€~ÿceß\x11\x11\x13m\x10\x10\x12d\r\r\x0eT\b\b C\x03\x03\x048\x01\x01\x013\x01\0\x013\x02\x02\x036\x06\x06\x06=\x16\x19"N\x1d@”ú\x06YÌÿ\x1fœæÿH¹öÿlÌýÿŽÝþÿ•ìþÿ@Íþÿ1Åþÿ\x1dºþÿ
°þÿ\0«þÿ\0¢þÿ\0™þÿ\0þÿ\0‡þÿ\0Zàÿ \x1f#< \x1f#) \x1f#\x13 \x1f#\x05ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0\0\0\0\x01\x0e\x0e\x10 8-':pQJþºª§ÿ›‹Šÿ´¤¡ÿô®ÿ´£Ÿÿ{WSþ\x1d\x18\x18w\x11\x10\x12i\x0f\x0e\x10\
\vJ\x05\x05\x06<\x01\x01\x014\0\0\02\0\0\01\x01\0\x011\x03\x02\x032\a\x06\a5\f\f\x0e;#H£ù\x05^ÞÿC¶ùÿlÍýÿ’ßþÿŽéþÿ4Åþÿ!¼þÿ\x0f´þÿ\0¬þÿ\0£þÿ\0›þÿ\0’þÿ\0‹þÿ\0\x7fþÿ\0Wâÿ \x1f#B \x1f#0 \x1f#\x18 \x1f#\bÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0\v
\f\x03\x0e\x0e\x10\x12_D=¤¸¤ ÿ—†…ÿ°Ÿœÿ¿®©ÿ‘ywÿ{XUø\x11\x11\x13m\x10\x10\x12d\r\r\x0eU\b\b C\x03\x03\x048\x01\x01\x012\0\0\0/\0\0\0+\0\0\0&\x01\x01\x01!\x04\x04\x04\x1d\r\r\x0e\x1e\x17\x16\x18%*R´ö\x04cçÿaÇþÿ”àþÿ…åþÿ%¿þÿ\x13¶þÿ\0¬þÿ\0¤þÿ\0œþÿ\0”þÿ\0‹þÿ\0þÿ\0zþÿ\0Sâÿ \x1f#D \x1f#3 \x1f#\x1a \x1f#\bÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0\0\0\0\x01\f\f\r\b\x19\x18\x1a\x1flNFô•ƒ‚ÿ«š–ÿ«™•ÿyUQþ!\x19\x1a{\x11\x10\x12i\x0f\x0e\x10]\v
\fJ\x06\x06\a;\x01\x01\x02/\0\0\0(\0\0\0#\0\0\0\x1c\0\0\0\x15\0\0\0\x0e\x03\x03\x03
\x0e\r\x0f ^[^[\x1e\x0e\x1f\x1e"^[.X·ó\x02béÿÕþÿ{ßþÿ\x17¸þÿ\x03¬þÿ\0¥þÿ\0žþÿ\0•þÿ\0Žþÿ\0‚þÿ\0{þÿ\0rþÿ\0Pàÿ \x1f#D \x1f#3 \x1f#\x1a \x1f#\bÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0\v
\f\x03\r\f\x0e\x0fW>7~Švuÿ¥”ÿwXUÿ{XUø\x12\x11\x13m\x10\x10\x12c\x0e\x0e\x0fR
\v<\x05\x04\x05+\x01\x01\x01 \0\0\0\x17\0\0\0\x10\0\0\0\v\0\0\0\x06\0\0\0\x03\0\0\0\x01 \x1f#\x01 \x1f#\x04 \x1f#\f \x1f#\x1a1]¸ñ\x01aæÿpÙþÿ\x05®þÿ\0¦þÿ\0žþÿ\0–þÿ\0Žþÿ\0…þÿ\0}þÿ\0tþÿ\0lþÿ\0Màÿ \x1f#D \x1f#3 \x1f#\x1a \x1f#\bÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0\v
\f\x06\r\f\x0e\x19hJCݤ’ŽÿwTOþ#\x1a\x1cx\x12\x12\x14e\x11\x11\x13U\x0f\x0e\x10>\v
\f'\x04\x04\x05\x16\0\0\0\f\0\0\0\a\0\0\0\x04\0\0\0\x02\0\0\0\x01 \x1f#\0 \x1f#\0 \x1f#\0 \x1f#\x01 \x1f#\x04 \x1f#\f \x1f#\x1a<j¶ä\0tâÿ\0pâÿ\0lâÿ\0hâÿ\0dâÿ\0`àÿ\0Zâÿ\0Vâÿ\0Ràÿ\0Màÿ\0Hàÿ \x1f#D \x1f#3 \x1f#\x1a \x1f#\bÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0\0\0\0\x01\f\f\r\rI4/W~]XÿŒllð\x14\x13\x16]\x15\x14\x17T\x15\x15\x17>\x13\x12\x15%\x0f\x0f\x10\x11\x05\x05\x06\x06\0\0\0\x02\0\0\0\x01 \x1f#\0 \x1f#\0 \x1f#\0 \x1f#\0 \x1f#\0 \x1f#\0 \x1f#\0 \x1f#\x01 \x1f#\x04 \x1f#\f \x1f#\x19 \x1f#) \x1f#7 \x1f#@ \x1f#D \x1f#D \x1f#D \x1f#D \x1f#D \x1f#D \x1f#D \x1f#D \x1f#= \x1f#. \x1f#\x17 \x1f#\bÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0\r\f\x0e\x05\x0e\x0e\x10\x14lUOµ7-.P\x18\x17\x1aE\x1a\x19\x1c;^[\x1a\x1d%\x1a\x1a\x1d\x11\x18\x17\x1a\x04\0\0\0\x01ÿÿÿ\0 \x1f#\0 \x1f#\0 \x1f#\0 \x1f#\0 \x1f#\0 \x1f#\0 \x1f#\0 \x1f#\0 \x1f#\0 \x1f#\x01 \x1f#\x04 \x1f#\v \x1f#\x17 \x1f#$ \x1f#. \x1f#2 \x1f#3 \x1f#3 \x1f#3 \x1f#3 \x1f#3 \x1f#3 \x1f#3 \x1f#. \x1f#" \x1f#\x11 \x1f#\x05ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0\0\0\0\x01\x12\x12\x14\a#"#\x17\x1a\x19\x1c$\x1d\x1c +\x1e\x1d!&\x1e\x1e!\x16 \x1f#\b \x1f#\x01ÿÿÿ\0ÿÿÿ\0 \x1f#\0 \x1f#\0 \x1f#\0 \x1f#\0 \x1f#\0 \x1f#\0 \x1f#\0 \x1f#\0 \x1f#\0 \x1f#\0 \x1f#\x01 \x1f#\x03 \x1f# \x1f#\x10 \x1f#\x16 \x1f#\x19 \x1f#\x1a \x1f#\x1a \x1f#\x1a \x1f#\x1a \x1f#\x1a \x1f#\x1a \x1f#\x1a \x1f#\x17 \x1f#\x11 \x1f#\b \x1f#\x03ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0 \x1f#\x01\x1c^[\x1f\b\x1e\x1d!\x11 \x1f#\x16 \x1f#\x14 \x1f#\v \x1f#\x03ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0 \x1f#\0 \x1f#\0 \x1f#\0 \x1f#\0 \x1f#\0 \x1f#\0 \x1f#\0 \x1f#\0 \x1f#\0 \x1f#\0 \x1f#\0 \x1f#\0 \x1f#\x02 \x1f#\x05 \x1f#\a \x1f#\b \x1f#\b \x1f#\b \x1f#\b \x1f#\b \x1f#\b \x1f#\b \x1f#\b \x1f#\b \x1f#\x05 \x1f#\x03 \x1f#\x01ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿÿ\0ÿÿ
^ permalink raw reply
* Re: [PATCH 2/6] Container Freezer: Make refrigerator always available
From: Matt Helsley @ 2008-08-01 23:24 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Andrew Morton, Thomas Petazzoni, Paul Menage, Li Zefan,
Linux-Kernel, Linux Containers, linux-pm, Cedric Le Goater,
Serge E. Hallyn, Michael Opdenacker, linux-embedded
In-Reply-To: <200808020053.18638.rjw@sisk.pl>
On Sat, 2008-08-02 at 00:53 +-0200, Rafael J. Wysocki wrote:
+AD4 On Friday, 1 of August 2008, Matt Helsley wrote:
+AD4 +AD4
+AD4 +AD4 On Fri, 2008-08-01 at 16:27 +-0200, Thomas Petazzoni wrote:
+AD4 +AD4 +AD4 Hi,
+AD4 +AD4 +AD4
+AD4 +AD4 +AD4 Le Thu, 31 Jul 2008 22:07:01 -0700,
+AD4 +AD4 +AD4 Matt Helsley +ADw-matthltc+AEA-us.ibm.com+AD4 a +AOk-crit :
+AD4 +AD4 +AD4
+AD4 +AD4 +AD4 +AD4 --- a/kernel/Makefile
+AD4 +AD4 +AD4 +AD4 +-+-+- b/kernel/Makefile
+AD4 +AD4 +AD4 +AD4 +AEAAQA -5,7 +-5,7 +AEAAQA
+AD4 +AD4 +AD4 +AD4 obj-y +AD0 sched.o fork.o exec+AF8-domain.o panic.o printk.o +AFw
+AD4 +AD4 +AD4 +AD4 cpu.o exit.o itimer.o time.o softirq.o resource.o +AFw
+AD4 +AD4 +AD4 +AD4 sysctl.o capability.o ptrace.o timer.o user.o +AFw
+AD4 +AD4 +AD4 +AD4 - signal.o sys.o kmod.o workqueue.o pid.o +AFw
+AD4 +AD4 +AD4 +AD4 +- signal.o sys.o kmod.o workqueue.o pid.o freezer.o +AFw
+AD4 +AD4 +AD4
+AD4 +AD4 +AD4 I have the impression that the code in kernel/power/process.c was
+AD4 +AD4 +AD4 compiled only if CONFIG+AF8-PM+AF8-SLEEP was set. Now that the code has been
+AD4 +AD4 +AD4 moved to kernel/freezer.c, it is unconditionnaly compiled in every
+AD4 +AD4 +AD4 kernel. Is that correct ?
+AD4 +AD4 +AD4
+AD4 +AD4 +AD4 If so, is it possible to put this new feature under some
+AD4 +AD4 +AD4 CONFIG+AF8-SOMETHING option, for people who care about the kernel size ?
+AD4 +AD4
+AD4 +AD4 How about making it depend on a combination of CONFIG variables?
+AD4 +AD4 Here's an RFC PATCH. Completely untested.
+AD4 +AD4
+AD4 +AD4 Signed-off-by: Matt Helsley +ADw-matthltc+AEA-us.ibm.com+AD4
+AD4
+AD4 Can you please also make the contents of include/linux/freezer.h depend on
+AD4 CONFIG+AF8-FREEZER instead of CONFIG+AF8-PM+AF8-SLEEP?
Good point -- I'll add that to this patch and repost.
+AD4 Also, I'm not really sure if kernel/power/Kconfig is the right place to define
+AD4 CONFIG+AF8-FREEZER.
There's no nice place to put it since we're dealing with CONFIG+AF8
variables in two different Kconfig files. I put it in
kernel/power/Kconfig because I wasn't certain Kbuild would do the right
thing if I referenced PM+AF8-SLEEP from init/Kconfig.
+AD4 Perhaps we should even move freezer.c from kernel/power to kernel
It's already there. Perhaps you meant something else
(kernel/power/process.c?)?
+AD4 and define CONFIG+AF8-FREEZER in Kconfig in there. Andrew, what do you think?
The Kconfig files in kernel/ are Kconfig.hz and Kconfig.preemt which
don't seem appropriate. I suppose we could add another (perhaps
Kconfig.cgroup).
Thanks for the review+ACE
Cheers,
-Matt
^ 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