update odroidxu4-4.2 to rc6

[paralin]

I've merged Linux 4.2-rc6 to here: https://github.com/paralin/linux/tree/odroidxu4-v4.2-rc6

Suggesting to make a new branch in this repo and pull from mine.

Rc6 fixes a lot of bugs in rc1, including #125

~ Christian

[paralin]

Just tested on an odroid XU4, works as far as I can see.

[paralin]

Tested with docker. The defconfig I have to layer on top of it is as follows:

# docker requirements

# ip nat requirements
CONFIG_NET=y
CONFIG_INET=y
CONFIG_NETFILTER=y
CONFIG_NF_CONNTRACK=m
CONFIG_NF_CONNTRACK_IPV4=m
CONFIG_IP_NF_IPTABLES=y
CONFIG_NF_NAT=m
CONFIG_NF_NAT_IPV4=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_TARGET_MASQUERADE=m

# support multiple instances of devpts
CONFIG_TTY=y
CONFIG_UNIX98_PTYS=y
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y

# cgroup scheduler
CONFIG_CGROUPS=y
CONFIG_CGROUP_SCHED=y

# required for below modules
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
CONFIG_CGROUPS=y
CONFIG_PERF_EVENTS=y

# virtual lan support
CONFIG_MACVLAN=m

# virtual eth
CONFIG_VETH=m

# xt match addrtype
CONFIG_NETFILTER_XTABLES=y
CONFIG_NETFILTER_XT_MATCH_ADDRTYPE=m
# xt match conntrack
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m

# optional docker requirements

# don't enable CONFIG_MEMCG_SWAP because it takes a lot of memory
CONFIG_BLK_CGROUP=y
CONFIG_CGROUP_PERF=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_RT_GROUP_SCHED=y

This might be good to include in the default odroidxu4 defconfig.

[scotte]

4.2-rc7 came out a few days ago. Rebasing this branch on rc7 is trivial, the only conflict is on the RTL8152/RTL8153 driver (r8152.c) which is easily resolved by taking v2.04.0 from the XU4 branch versus v1.08.1 in the official kernel tree.

Here's my rebase of odroidxu4-v4.2-rc1 onto 4.2-rc7: https://github.com/scotte/odroid-linux/commits/odroidxu4-v4.2-rc7

[tobetter]

Scotte, I love your branch since it's not merged branch. Could you let me know the command what you made the branch?

[paralin]

He probably used rebase ? That's not so good since it doesn't keep the same history very well.

But if you want to not have much comparability between the previous version branch and this one, that's fine. It just rewrites commit history in there and invalidates all the signatures. This means he could sneak in some virus code and it would be very hard to notice.

Christian

On Wed, Aug 19, 2015, 10:40 PM Dongjin Kim notifications@github.com wrote:

Scotte, I love your branch since it's not merged branch. Could you let me know the command what you made the branch?

— Reply to this email directly or view it on GitHub https://github.com/hardkernel/linux/issues/126#issuecomment-132860376.

[tobetter]

Thanks for notice. I believe he might use cherry-pick instead of rebase. :)

My point is to put the commits probably SoC specific patches on top of mainline. Because the patches what HK team added on top of v4.2-rc1 are queued for code review in Patchwork or mailing list. These could be merged into mainline sometime or another modified patch could be. My perspective, these patches could make a conflict when the branch is merged with next version. So I prefer to keep these on top of any version of mainline release till major SoC features are merged into mainline. This might be ridiculous or my git skill is too poor. :)

Obviously, many patches are welcoming for XU4.

Dongjin.

[scotte]

Yes, it was a rebase - there are arguments all around on the right way to do these things, but since this is an experimental branch and a rebase into a new topic branch, rewriting history isn't much of an issue for me - although it does change the way those github merges look. There no risk in my fork, because @tobetter would redo it and not use mine anyway.

Note the odroidxu4-v4.2-rc6 branch @paralin has includes some additional commits not in this repository. The HEAD of hardkernel's odroidxu4-v4.2-rc1 branch should be merged with the upstream 4.2-rc7 kernel, then these additional commits from @paralin reapplied.

The decision also depends on how all the commits to odroidxu4-v4.2-rc1 got there. If they were all direct commits to this branch or cherrypicks from elsewhere (so the SHAs don't match source anyway), then rewriting history is less of an issue. I'm not sure how the Samsung commits (for example) got there.

If there's a master-like origin to the branch, then rewriting history is a problem, especially if it will be merged back in. If this is just a topic branch that will eventually become a master-like branch then rewriting history is often acceptable (and again, this is done in a new branch anyway).

As @tobetter points out, this puts all local branch commits on top of the official kernel tree which makes dealing with those patches that will eventually make their way into mainline Linux kernel a bit easier. That even makes the argument easier, in my mind, because this branch really is just experimental until those SOC/etc changes are in mainline. To clean that up will result in rewriting history eventually regardless of the approach used.

We have to remember this is a fork of the kernel, not the origin - so it's a bit different than commiting back into the official master. I don't know hardkernel's ultimate plans for this repository, and it's branches, or how much of this stuff will end up in mainline versus being just in the hardkernel or XU4 forks. Those decisions tie in to the best way to manage this repository.

If you still want to go down the rebase route, here's the basics on how to do it. In this case rebasing on the main kernel branch means that git unwinds all commits on the local branch until it gets to a common ancestor, then fast-forwards to HEAD of the official kernel. Then, it replays each of the commits to your local branch.

This assumes that a remote tracking repository to https://github.com/torvalds/linux exists and that it's called "upstream". This is from memory, so syntax may not be syntactically correct.

# Sync branches from upstream
$ git fetch upstream

# Checkout the branch that we wish to rebase
$ git checkout odroidxu4-v4.2-rc1

# Make sure git status is clean at this point or bad things will happen
$ git status

# Create our new target branch
$ git checkout -b odroidxu4-v4.2-rc7

# Now we start the rebase from upstream kernel
$ git rebase upstream/master

# Git will now unwind to a common ancestor, fast-forward to HEAD of upstream, then
# start applying each local commit. For conflicts (where git is unable to resolve a merge
# because a file was changed in both branches), that has to be iterated on. In this case,
# there's only one (r8152.c).

# For conflicts, chose a winner. This is somewhat confusing at this stage because "ours"
# mean mainline and "theirs" means the local branch during a rebase. I generally always
# use mergetool with meld, since it gives me a nice graphical way to see which one I want.

$ git mergetool

# For r8152.c, I took the new version from hardkernel's branch, not the one in the upstream kernel.

# Once merged, make sure git status is clean, may require git adding additional artifacts.

$ git status

# Now continue to the next iteration

$ git rebase --continue

# That's it! Except for pushing the new branch up.

# If things go bad, it's no harm since this is on a new branch and it's easy to reset:

$ git rebase --abort

That's the git rebase primer, and again I'll defer to hardkernel on how they wish to manage the repository. There's no one right way with git! :-)

[scotte]

FYI, Linux 4.2 kernel has been released and all patches on this branch rebase/merge cleanly (aside from r8152.c already discussed above).

[tobetter]

Hey, I've uploaded v4.2 kernel for ODROID-XU4 but not on Hardkernel's repository since the kernel is experimental and not stable enough to publish for generic end users. Still there are many missing features on mainline for Exynos5422.

Please visit here, https://github.com/tobetter/linux/tree/odroidxu4-v4.2 I'm expecting to maintain the branch adding upstream patches till v4.3 comes out as well as kernel debian package will be published in Launchpad, https://code.launchpad.net/~tobetter/+junk/odroidxu4-v4.2. I hope I can manage this enough to publish officially.

[eraclitux]

Is it possible to know exactly which features are unavailable (HMP, etc)?

Thanks.

[tobetter]

The build itself is just ok to run headless server, but would not say it has maximum or customized performance. HMP is not there and X11 won't work on it. Performance wise, USB and Micro SD...won't support full functions. What features exactly do you want to know?

[eraclitux]

HMP is what I was looking for. I use it as a server but I was needing some functionality missing in 3.10 to run LXC containers (overlay fs etc). Thanks.

[paralin]

@tobetter What about the defconfig changes? Might be worth bringing in.

[tobetter]

@paralin Ah, yes....worth to bring in. Sorry for delay due to some heavy work. Please kick my ass if it doesn't happen in 24 hours.

[paralin]

It's not critical to me since we merge defconfigs before building with our own custom overrides, but thanks! :)

On Tue, Sep 8, 2015 at 9:08 PM Dongjin Kim notifications@github.com wrote:

@paralin https://github.com/paralin Ah, yes....worth to bring in. Sorry for delay due to some heavy work. Please kick my ass if it doesn't happen in 24 hours.

— Reply to this email directly or view it on GitHub https://github.com/hardkernel/linux/issues/126#issuecomment-138743913.

[paralin]

@tobetter Any plans to merge up to 4.2 official?

[tobetter]

@paralin Have you looked this? https://github.com/tobetter/linux/commits/odroidxu4-v4.2