[CentOS-devel] possibility of an extra-hardware-support SIG

Phil Schaffner Philip.R.Schaffner at NASA.gov
Thu Sep 6 13:09:15 UTC 2007

On Thu, 2007-09-06 at 00:33 +0100, Karanbir Singh wrote:
> Hi Phil,
> Phil Schaffner wrote:
> > Seems that kernels/drivers/modules diverging from the upstream would
> > need to be in [a] separate repo[s], something like Johnny's 100Hz
> > kernels.
> I dont visualise us building complete kernels ( unless we must - and that again 
> is something to be taken up when we come to it ). for drivers and modules, we 
> should be mostly ok to stick things into extras/ however if we need to the plus/ 
> repo is always around. Pesonally, I dont think we would need to do that though.

Agree.  Just meant it as an example of separate repo outside the current
CentOS structure, not to imply that new kernels were necessary for this
purpose; although would not exclude that if it proved expedient.

> btw, the 100Hz kernels are called kernel-vm for this reason, so as to not 
> pollute and cause issues in the kernel-* namespace.

Hummm - doesn't seem to be the case on my VMware CentOS-5 VM:

[root at c5 ~]# rpm -q kernel

But I digress.

If other non-standard kernels were provided, a kernel-xyz naming
convention might be a good a good policy.

        [ Continuing digression: Would also address the issues I have
        encountered with the current naming convention where yum
        considers kernel-2.6.18-8.1.8.el5 to be later than
        http://bugs.centos.org/view.php?id=2189 ]
> > Could get sticky, depending on license issues.  Why not just maintain a
> > set of links to the latest sources from the vendors?
> for drivers and software ( userland stuff, or even firmware ) we should try and 
> make things as easy as possible, for things that we cant - yes, a best case 
> would be docs that make life easier, a worstcase would be a one line saying 
> 'this vendor sux, dont use them'.
> > Overall, your objectives sound great.  The dark-gray territory would be
> > a challenge, but seems like good CentOS value-added if done carefully,
> I am sure you are around to keep us on track :)

You are too kind, sir.  May need a lawyer for that purpose. :-P

> > with appropriate caveats, and (obviously) kept outside the core repos.
> > Just not sure what the advantage of a SIG is over keeping it on
> > centos-devel.  Please elaborate.
> The idea of a SIG is to expose a target that people can hit ( vendors, users and 
> even other developers ). One thing we seem to lack on the centos project at this 
> time is focus and the idea of a target. If things need to get done, few people 
> are really able to isolate specific people / places / resources that they might 
> be able to ping.
> Nothing stops us from using this list and using whatever is in place at the moment.

OK - understood.  Was just afraid of "splintering" or fragmenting the
resource pool if the effort were too separate from core CentOS.  Sounds
like we are on the same page there from the above and another reply in
this thread.

> Also, there is a buildsystem of sorts that I use, to build driver images and 
> also to build kmod's for each release kernel at release + update time. And  I 
> really would like to allow other people access to that as well. Doing so within 
> a smaller group might be easier than mass public access :)

Mass public access to your buildsystem would certainly not make the job
easier.  A common buildsystem for these add-on drivers would probably be
a requirement for the release versions.

> Finally, it would be good to have a role that can handle all issues related to 
> unsupported hardware that are reported on bugs.centos.org - right now they all 
> get assigned to me, and inspite of the fact that I try and look at each and 
> every one, its not humanely possible to do and do justice to them all. Would be 
> nice if there was a group of people who could own and drive these issues.

Understand that you could use help.  OTOH, my experience is that if an
issue or action-item does not have a single stuckee, it does not get
done.  If ownership of a particular issue were adopted by a member of
the "Value-Added Driver SIG" that should work.

Would seem these drivers would be of value to others (i.e. EL, SL) as

> Anyway, I have run it up the flagpost.

Seems at least a few are saluting.  :-)

Will help where I can, but don't have a wide variety of hardware running
CentOS available, nor a lot of time to volunteer.  My "day job" is
research on airborne sensors for aviation safety and CentOS is just one
tool in the toolbox.


More information about the CentOS-devel mailing list