[ATrpms-users] Re: ntfs + software suspend

[Axel Thimm]

On Thu, Sep 29, 2005 at 07:10:21PM +0200, Matthias Hensler wrote:
> On Thu, Sep 29, 2005 at 06:25:26PM +0200, Axel Thimm wrote:
> > On Thu, Sep 29, 2005 at 06:33:14PM +0200, Tako Schotanus wrote:
> > > Ok, it has been a while but in the last couple of days I've been
> > > trying out Matthias Hensler's kernels that include software suspend
> > > (http://mhensler.de/swsusp/index_en.php) and they work perfectly for
> > > me.
> > > 
> > > So... maybe I could convince you to take another look at software
> > > suspend support for the AT kernel? :-D
> > > 
> > > The information on the site is quite extensive and there are all
> > > kinds of ready-to-install rpms and such so hopefully it wouldn't be
> > > too much work for you to include it into ATrpms.
> > 
> > Well, "jam with the best", I Cced Matthias, maybe he would be
> > interested in maintaining kernel and other related patched packages
> > within ATrpms. I think that would be the best configuration.
> > 
> > Matthias, would that be something you'd like to do?
> 
> First of all, since I am not subscribed to the atrmps-Mailinglist I
> would like if you could keep me in Cc.
> 
> Regarding your question: I am aware that there are many 3rd party kernel
> modules which are not part of the Fedora standard kernel and will never
> be. In fact I have to compile a lot of stuff for myself with each new
> kernel.

Yes, your kernel would become a supported kernel at ATrpms which means
that all flavour/arch combinations for ia32 and x86_64 would be
supported by the kmlds at ATrpms, too.

> The main problem with software suspend is, that it is not modular (in
> fact it was for some time, but is not any longer), changes a lot in the
> kernel (although it had not break much lately) and needs several things
> to get it running (initrd patching, changes in the kernel commandline
> and several userspace stuff).
> 
> While swsusp1 is part of the vanilla kernel since 2.6, it is disabled in
> the Fedora standard kernels (and will be at least for FC3 and FC4).
> Currently there are some changes regarding this, as rawhide has swsusp1
> enabled kernels since August 2005 and some support in recent
> mkinitrd-packages.
> 
> However, swsusp2 seems to be much more stable today and is working to
> get it integrated into the vanilla kernel tree. I suppose that will take
> some time, and won't likely to show up in the Fedora kernel before FC6.
> 
> At the moment I try my best to provide stable and working kernels for
> FC3, FC4 and rawhide, together with a set of needed packages to make
> setup easier (for most systems it is currently enough to install the
> swsusp2 enabled kernel RPM, with the hibernate, userui and
> swsusp2-mkinitrd RPMs and modify the kernel commandline). However, I do
> not have a build system at the moment which would me allow to build
> anything besides i686 packages. For all other architectures, as well for
> features like Xen-support (not sure if anyone ever tested this with
> swsusp2), the people are on the own to rebuild the RPMs.
> 
> I would happy to see support for swsusp2-kernels in ATrpms, but that
> would need some coordination. As explained above I do not see any other
> possiblity as to spin seperate kernel RPMs at the moment.

Yes, that's the way to go. Some things can't be build externally, then
we need to supply a different kernel and also all kmdl that go along
with it. ATrpms had such kernels for 2.4 including openswan/xfs/v4l2
etc that could not be built separately. For recent FC released kernels
there haven't been many projects that cannot be built externally and
that would be of general interest to justify respinning kernel
packages. swsusp is one of them.

> What I can do, is to rebuild the packages from ATrpms for my kernel
> versions (at least for i686-up) and either provide them on my page,
> or directly at ATrpms, whatever the best solution here is.

Best thing would be at ATrpms, and even by the buildsystem there.

> That would lead to the question about the different architectures. Most
> users are happy with i686-up at the moment, but since there a lot of
> notebooks with hyper threading and 64bit it could make sense to provide
> i686-smp, x86_64 and x86_64-smp as well (I am not totally sure about the
> status of SMP and 64bit, but there were some effords to get it work for
> the upcoming 2.2 release of swsusp2).

Even if there are bugs, it would be nice to habe x86_64 and smp, so
people can test and report to swsusp upstream.

> I should be able to build everything, including the ATrpms kernel
> modules, for i686, but would need help for all the rest.
> 
> I am open for suggestions, so just let me know what you think and how it
> could be done.

How about the following model:

o Development of the packages happen on your box

o When you are happy to release a kernel package you upload the
  src.rpm to the ATrpms build server via rsync+ssh.

o You let the buildserver generate kernels for i386/x86_64 on all
  flavours (including smp and xen) and all subarchs, as well as all
  supporting kmdls.

o Packages get automatically into ATrpms' repo that way, and are
  available for apt/yum/smart etc.

The packages would have to be labeled testing or even experimental at
first, so noone gets burned. Slowly we can increase the stability
level as we get more confident with the user feedback (or not, if it
is negative, of course).

When all goes well, you will get a few envy people from the RHEL4 camp
asking you to weave swsusp into RHEL4 kernels, too. :)
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.atrpms.net/pipermail/atrpms-users/attachments/20050929/1c26ac9a/attachment-0001.bin