Re: [Laptopkernel-devel] Introduction and general thoughts

[Sebastian Henschel]

Received at 2003-05-29 / 12:40 by Bernd Wurst:
> 
> Am Don, 29.05.2003 um 01:41 Uhr schrieb Stephan Skrodzki:
> > Am Mit, 2003-05-28 um 23.17 schrieb Hanno Böck:
> > > As you see, we don't focus just on tm800-stuff, instead we want to have
> > > a kernel with lots of laptop-specific patches (as long as they don't
> > > interferre).
> > so, how (just for example) could cpufreq get along with the performance
> > settings of the acpi environment? And even if those two patches would
> > cooperate, the next question which would come up would, which /proc
> > interface (acpi or cpufreq) would work how on which laptop.

this is something you have to find out for your specific laptop by
yourself. if acpi and cpufreq can both be integrated (and i think so, since
dominik brodowski, former maintainer of cpufreq, also works on acpi),
then this is good enuff for the laptopkernel project. though it would be
nice if there were a note saying something about the concurrent use of
these two features. sorry, i do not have any experience with cpufreq
yet.

> I think we have to say that we did not completely understand which one is
> compatible with which type of processor.
> It seems that some CPUs have problems with
> /proc/acpi/processor/CPU0/performance even if they should support SpeedStep. 

i worked on about a dozen different laptops this year and except for one
in january, all their performance states worked with acpi.

> > -> More than providing a monolithic kernel patch, I would suggest to
> > make it more chooseable, which patch to load - or even the handcrafts
> > way - to work more on the "Which patch is good for what" Howto.
> 
> Feel free to write such a how-to! :)

yes, good idea. though hanno already did something like this in the
announcement.

> I think as long as patches do not conflict with each other we do not need to
> provide individual patches.

this problem already exists: swsusp conflicts with xfs (and o1, preempt,
etc.  if i understood hanno correctly). perhaps we should bother the
makers of swsusp to change their patch in order to work with the others.
making the laptopkernel more modular would be great. :) i imagine having
a tarball with this structure:

laptopkernel/
    README          (contains a description where to get this patch, howto
                    install, what patches are included (including location
                    and version) and which patches conflict)
    patchit         (shellscript which does the actual patching)
    patchit.conf    (config which includes a list of patches to apply,
                    which warns about conflicts again)
    patches/        (directory with all patches)


a sample patchit.conf could look like this:

# kernel tree
SRC=/usr/src/linux

# default patches to include
PATCHES="acpi swsusp radeonfb"


# more patches

# xfs CONFLICTS swsusp
#PATCHES="$PATCHES xfs"

# o1 CONFLICTS swsusp
#PATCHES="$PATCHES o1"


patchit could also check for these conflicts (hmm.. now we have three
files to keep conflicts in sync: README, patchit, patchit.conf)


> One can choose in menuconfig which one to use.

exactly, it does not hurt to have them in your kernel tree, as long as
we speak about +- 1 MB or so and they do not conflict. :)

> > > [individual patchsets]
> > > I already thought about that. It is possible, but it would be much > >
> > > more work.
> > Please do that. I can't imagine, that I would be the only one with such
> > a wish.
> 
> Sure, you are not the only one who has such a wish. But for the moment it is
> definitively not the goal of this project. The swsusp project often provides
> patches against the latest acpi and others also do so. One can also collect
> all these single patches and allpy then one after the other. Our goal should
> be to provide one single patch that does all that.

for the user it would not be that much of a difference to either apply
one big patch or use some script like stefan or i proposed. if you need
help, i like to volunteer, since i would do that for my work (and
customers) at xtops.de anyway.

> If you (or someone else) want to do this, it'll be great for some users.

especially for people who often install different laptops. :)

> Please do so and we will support you whereever we can. But our primary goal is
> to make that one patch. A time will come when patches interferre with each
> other, then we have to think about that, sure.

ok, we already have that situation. so if i would make such a tarball as
described above, you would put it as an alternative up on savannah?

> > > To help out, I provided all the sources where the patches came from in
> > > the announcement.
> > Yes, but Bernd once announced on his website, that he had to modify the
> > swsup patch. Bernd is that true?
> 
> Look above. This IS this modified version. But the modifications are kind of
> trivial. (I did not do it, Hanno did :) )

could you please lay out the details, what you modified, hanno?
last time i integrated swsusp in my kernels, i did not have a need for that.

> > >> ACPI: the battery does not give you a discharge rate, so most of the
> > >> tools show no or senseless rest times. Do you have the same results?
> > > I don't know if any laptop does that. Mine also doesn't.
> 
> On my TM800, acpi (with given patch) works out of the box!
> I lately tried Knoppix and I saw that there was battery rate visible from
> /proc/apm!! :)
> I did not ever have any problems with acpi-battery monitoring. But I read
> about that with older Kernels. I started with 2.4.21-pre3 (IIRC).

i did not try your patch so far, but usually battery status works. i can
imagine four reasons why it does not work for stefan:

- battery status is not supported by the hardware: quite unlikely
- battery status is screwed by ACPI: possible, but unlikely
- battery status is screwed by your DSDT: quite likely
- battery status is screwed by your configuration: possible

btw, DSDT is a very important part of the ACPI implementation of your BIOS
which you can override by the OS. most DSDTs in laptops are screwed, my
battery status does not work with the original DSDT of my BIOS.


another thing not yet answered by hanno or bernd:
do you plan to build the patches upon stable kernels in the future or
will you keep building on -pre and -rc releases?

cheers,
 sebastian
-- 
::: sebastian henschel
::: kodeaffe
::: lynx -source http://www.kodeaffe.de/shensche.pub | gpg --import

pgp0YFNan13qb.pgp
Description: PGP signature