Re: [coLinux-devel] [coLinux-users] 2.6.16 for colinux?

[Anders E. C \(KI/EAB\) <and...@er...>]

=20

> On 5/29/06, Anders Eriksson C (KI/EAB) wrote:
>=20
<snip>
>=20
> How'd you make out on the 2.6.16 patch?  Any success? =20
Not really (yet). I've got the patch split:=20
-rw-r--r-- 1 eraaero users 90203 May  3 17:10 base
-rw-r--r-- 1 eraaero users 17018 May  3 17:11 coconsole
-rw-r--r-- 1 eraaero users 80666 May  3 17:11 cofs
-rw-r--r-- 1 eraaero users  7748 May  3 17:11 conet
-rw-r--r-- 1 eraaero users 35937 May  3 17:11 driver
=20
..and started to browse around in the base patch. Real Work has=20
derailed me a bit I'm afraid. I've not given up on it though!

> The size of the
> patch and it's monolithic nature have never stopped other coLinux
> kernel patch submitters in the past.  I have no objections to
> splitting up the patch.  Henry is on vacation, but when he get's back
> I'd be interested in his opinion of splitting this patch up into
> chunks.
>=20
How has this been handled in the past? If I hack away on the monolithic=20
patch I can imagine myself having my own 250 KB patch (for e.g. 2.6.16)
at the end... Would the proper procedure be to send it to the list?
Or get myself a monotone account some where and maybe monotone sorts
things out? (I'm not familiar with monotone).

As I don't really trust myself in these waters, so I'd much like to have
my=20
contrib reviewed by the core delvels before it approaches mainline.
How's
that procedure setup? I've never really seen patch-reviews on the
colinux=20
maillists (as is customary in lkml).


> The build system is already set-up to apply a series of patches, not
> using quilt's series files, but in lexical order I believe. =20
Yep. Noticed that.

> That is
> how the current coLinux kernel patch 'system' currently adds
> third-party patches, such as Knoppix's cloop.  We built it that way to
> allow coLinux to be  base that others modifed as needed.
>=20
Under this philosophy, would my (250KB 2.6.16 diff) contrib apply on top
of the existing 2.6.12 patch? While I can see that the mechanics work
for
the actual build, it doesn't seem to be maneageable for the future as
there's
no incentive for patch consolidation nor patch enhancements.

>=20
>   I can see pluses and minus to that way of doing it.  I don't think
> that getting this merged with the LK proper is something that's going
> to happen any time soon.  For 1 coLinux is way to in 'flux' with
> features and it's core API (to support those features) at the moment
> to be considering going into LK proper.
>=20

I agree that things are rapidly changing in this area, but on the other
hand, even if we'd never merge, wouldn't a one-patch-per-feature be more
maneageable? Virtualization is a hoopt topic in linux right now, and I'd
expect that *some* of the things that gets introduced can be taken
advantage
of in colinux (e.g. the frontends of virtual network interface drivers).


>   Some background on past discussion and the results of them.  The
> kernel version for 'stable' will not change after the initial release
> of that version series (ie the kernel of 0.6.x will always be 2.6.10),
> although we have 'bent' this a little in the recent release, but
> typically only to fix outstanding bugs and make stable, well more
> stable and usable.  This being because we want stable to be stable,
> hopefully devel doesn't get as behind as it has recently.  That is
> what has really hurt us to this point.
>=20
Sounds reasonable. Let's hope we can get traction on the devel side.

Any pointer to established procedured for patch handling would be
appreciated!!

Thanks,

/Anders