FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS Development

 
 
LinkBack Thread Tools
 
Old 07-03-2008, 03:36 PM
Ralph Angenendt
 
Default Too many kernels?

Hugo van der Kooij wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Axel Thimm wrote:
> | I start to think whether these kernels are indeed being all used to
> | the extend of justifying full kmdl support. Maybe it would make sense
> | to keep the full last series (2.6.18-92* above) and the highest one
> | from the series before (2.6.18-53.1.21.el5 and 2.6.18-8.1.15.el5).
>
> I would limit the kernels per distro:
> ~ - The one(s) shipped on the media
> ~ - The most recent kernel
> ~ - The one before the most recent kernel

Yepp, sounds sane.

> BTW as far as I can tell there are no -92* kernel modules on ATrpms.

IBTD

nvidia-graphics173.14.09-kmdl-2.6.18-92.1.1.el5-173.14.09-99.el5.x86_64

Ralph
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 07-03-2008, 04:07 PM
Bogdan Costescu
 
Default Too many kernels?

On Thu, 3 Jul 2008, Axel Thimm wrote:


I start to think whether these kernels are indeed being all used to
the extend of justifying full kmdl support. Maybe it would make sense
to keep the full last series (2.6.18-92* above) and the highest one
from the series before (2.6.18-53.1.21.el5 and 2.6.18-8.1.15.el5).


While Red Hat has promised initially a stable ABI within a version
(including all updates), this was not always the case - or maybe it
isn't clear to me what this promise means. However, the breakages are
much more likely to occur when major updates (like RHEL 5.2) come
while the minor kernel updates (like 2.6.18-53.1.19.el5) in between
usually contain only security fixes (please note my usage of "usually"
:-)). So I find it very likely that a module version compiled for one
-8.1.x kernel will work on all other -8.1.x kernels and less likely to
work on a 53.1.x one. Based on this assumption, keeping one kernel
module for each major update and using weak-updates for the minor
updates would probably work in a large percentage of cases.


For CentOS in particular, I can see that older kernels are actually
not available anymore on mirrors, neither as separate packages nor as
part of ISO images. The only way that I can think of to get those
older kernels is to install from ISO images written some time ago on
physical CD/DVDs - but these ISO images are only released for major
updates, so only one kernel version per major update is actually
available for those who choose this installation method and don't want
to update to the latest and greatest. For this case, again, having one
kernel module for each major update seems to be enough.


Disclaimer: I don't have any connection to Red Hat and I'm not a
CentOS developer.


--
Bogdan Costescu

IWR, University of Heidelberg, INF 368, D-69120 Heidelberg, Germany
Phone: +49 6221 54 8869/8240, Fax: +49 6221 54 8868/8850
E-mail: bogdan.costescu@iwr.uni-heidelberg.de
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 07-03-2008, 05:17 PM
Axel Thimm
 
Default Too many kernels?

On Thu, Jul 03, 2008 at 10:50:35AM -0400, Jarod Wilson wrote:
> Red Hat suggests building once for each flavor/arch combo and being done
> with it. As long as the required kernel symbols are present, they'll
> keep working. You make the kernel module deps on the necessary kernel
> symbols, which are provided by the kernel package. For example, the
> packages provided here...
>
> http://rhn.redhat.com/errata/RHBA-2007-0654.html
>
> ...are designed to work with any version-release of a given arch/flavor
> RHEL5 kernel.
>
> But then maybe you already knew that, and don't like that scheme much...
>

I'd love it if it would work

> But that's what's recommended to all ISV's who build kernel modules
> for RHEL5, and so far, its worked out great. Of course, if some out
> of tree driver requires a symbol not on the whitelist (i.e., not in
> the kernel's Provides, you lose, but...

My experience is that there is no guaranteed kernel ABI nor API by
RHEL. Otherwise the kmdl builds would not start to fail between say
the 53 series and the 92 ones. On every quarterly update I have to fix
several kmdl packages for RHEL due to backports. Usually with RHEL4/5
these are wireless updates.

Also at the very least I know of a glibc ABI discrepancy that was
fixed in 62, so I'm quite sure that there is no such stable ABI yet,
and since upstream will never provide one, it is very difficult for a
vendor to provide one (unless in deep maintenance mode where only
severe bugfixes/security issues, but no enhancements are addressed).

But speaking of policies I meant more the "you are required to update
withing XYZ days of an update to have Red Hat support etc.". If a
kernel is not anymore supported by Red Hat or CentOS then no kmdl
should be built for it.
--
Axel.Thimm at ATrpms.net
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 07-03-2008, 06:12 PM
"William L. Maltby"
 
Default Too many kernels?

On Thu, 2008-07-03 at 18:07 +0200, Bogdan Costescu wrote:
> On Thu, 3 Jul 2008, Axel Thimm wrote:
>
> ><snip>

> For CentOS in particular, I can see that older kernels are actually
> not available anymore on mirrors, neither as separate packages nor as
> part of ISO images. The only way that I can think of to get those
> older kernels is to install from ISO images written some time ago on
> physical CD/DVDs - but these ISO images are only released for major
> updates, so only one kernel version per major update is actually
> available for those who choose this installation method and don't want
> to update to the latest and greatest. For this case, again, having one
> kernel module for each major update seems to be enough.

IIRC, older CentOS stuff can be found in archives at the CentOS site. If
so, that's another alternative. But I don't know if that includes
updates between major releases or not.

If not, the number of kernels that are even considered for support are
reduced if one considers that availability of updates between major
upgrades as unavailable and CDs that were created could not have these
either (only major release snapshots should be on CDs).

>
> >snip>

--
Bill

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 07-03-2008, 06:21 PM
Karanbir Singh
 
Default Too many kernels?

Axel Thimm wrote:

But speaking of policies I meant more the "you are required to update
withing XYZ days of an update to have Red Hat support etc.". If a
kernel is not anymore supported by Red Hat or CentOS then no kmdl
should be built for it.


Within CentOS, we only maintain on 'live' repo's the main kernel
released for the media, as well as updates within the present point
release. Everything else goes to vault.centos.org - and the only people
we expect to be using packages from vault are people who know what they
are doing and have reasonable competence with packages in general and
the distro specifically. I am sure they ( vault users ) are also people
who might be expected to rebuild src.rpms if they need.


w.r.t kernel modules and drivers, I would think that supporting the
kernel on media for the current point release ( eg. 5.2 ) and the one on
media for previous one ( 5.1 ), and updates since the present point
release ( 5.2/updates ) - would be enough. Most people doing an install
at this time, will only need the kmdl / kmod / driverdisk for 'current'
and the updates.


- KB
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 

Thread Tools




All times are GMT. The time now is 02:46 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org