On Fri, May 09, 2014 at 01:56:27PM +0800, Jovi Zhangwei wrote:
> On Fri, May 9, 2014 at 12:10 PM, Greg KH <
gr...@kroah.com> wrote:
> > On Thu, May 08, 2014 at 07:03:38PM -0700, Jovi Zhangwei wrote:
> >>
> >>
> >> On Thursday, May 8, 2014 3:56:15 PM UTC+8, Greg Kroah-Hartman wrote:
> >>
> >> On Thu, May 08, 2014 at 12:16:05AM -0700, Jovi Zhangwei wrote:
> >> > Hi,
> >> >
> >> > I just wondering how to setup custom update server for coreos? this case
> >> might
> >> > be needed because:
> >> >
> >> > - user may need to have custom kernel patches on top of stable kernel, so
> >> it
> >> > can not get update from official coreos public update server.
> >>
> >> What kind of kernel patches do you need/want?
> >>
> >>
> >>
> >> For example, Third-party open sourced kernel patches for some feature
> >> enhancement, or self developed patches for own feature, and more...
> >
> > Any specifics?
> >
> Some patches for debug enhancement, and feature backport, etc.
> (LTSI also have many addition patches on top of LTS? not confirmed)
LTSI is for "consumer" products, and yes, they backport a lot of things,
mostly all new hardware support that is already upstream in newer kernel
releases.
LTSI really isn't relevant for a distro that constantly takes the latest
upstream kernel release.
> >> > - user may need to use old kernel version for a long time for stability.
> >>
> >> Why does an "old" kernel mean "stability"? The idea is that all kernels
> >> should be "stable", and if there is a problem, the roll-back will happen
> >> to the last "stable" one automatically.
> >>
> >>
> >> In many cases, kernel cannot upgrade frequently, and a lot of kernel modules
> >> bind with unique kernel version, it just not easy to update upstream kernel
> >> like coreos doing currently.
> >
> > On the contrary, updating a kernel can be done just fine very rapidly,
> > as you really should not ever be relying on an external kernel module.
> >
>
> In the product which I working now, there have many kernel modules in there,
> for different purposes. Actually those kernel modules is a big
> challenge for kernel
> update when new stable patches and new kernel version come, because
> kernel ABI often break. so they need time to adapt all kernel modules with
> new kernel update.
Why are those modules not merged upstream? Is there anything I can do
to help with that? If they were merged upstream, then there would not
be any issues :)
Also, what do these modules do? Hardware support? Something else?
> I think Enterprise kernel always don't have much kernel modules, but that's
> not the general case for other people.
I don't understand what you mean here.
> > Remember, you want change, as the world changes. If you have a box that
> > just sits in the corner and isn't connect to the internet with no new
> > hardware, then don't update the kernel. Otherwise, in order to have it
> > work properly, you will have to update it.
> >
> I agree, update is the way to forward, we want to update our kernel, my concern
> is how to handle below three issues under current coreos update mode?
>
> - kernel module update
> - addition kernel patch
> - private network
>
> Maybe there have another way to address these issues without setup custom
> update server, that's the reason why the original question raised. :)
If you have custom kernel modules / patches, that's something that would
need to be coordinated with the coreos team, nothing I can do here as a
community member, sorry. But again, I'd strongly urge you not to do
that, and to get your code upstream, so that issue will go away
automatically.
thanks,
greg k-h