add patch-kernel.sh

[korc]

simple script to apply necessary patches and files to vanilla kernel source

[sfjro]

Hello Lauri,

Lauri Korts-P rn:

simple script to apply necessary patches and files to vanilla kernel source

Here are the comments from me.

• As you might know, there are 2 options to apply the patches. One is
  for both of =m and =y, and the other is for =m only.
  Why don't you support both of them?
• It doen't look working with posix shell.
• How do you think about using GIT instead of patching.

J. R. Okajima

[korc]

• What is the actual difference for patching between those two modes? The first option (=m and =y) seems also to cover (=m only) option, so why is the second one necessary? In either way the kernel source needs patching, right?
• There are no bashishms, and it works with debian's /bin/sh, which is actually 'dash'. Please let me know if you see any errors with any other shells.
• If you mean for obtaining kernel, then there are just too arguments against using git. For a non-developer, tar+patch is clearly a better option.
  • Getting the stuff. Downloading a .tar.xz and extracting is way more simpler. Even locating correct git repository URL from hundreds of repos hosted at kernel.org is way too complicated for non-developer.
  • Time, bandwidth and disk resource usage. Test results for linux-4.8.8:
    • .tar.xz: 87MB of traffic in 23 seconds, 753MB data on disk
    • With git clone --depth=1: 174MB traffic in 78 seconds, resulting in 926MB
    • Clone without --depth (probably most common case): 1.1GB network traffic in 380 seconds, resulting in 2.0GB on disk
  • Just having .git directory in kernel source will already screw up local version string.

[sfjro]

Lauri Korts-P rn:

• What is the actual difference for patching between those two modes? The first option (=m and =y) seems also to cover (=m only) option, so why is the second one necessary? In either way the kernel source needs patching, right?

For the method 1, aufs4-standalone.patch is just an option. In other words,
users can choose =y only. On the other hand the method 2 is always =m only.
Aufs provides these two methods just to give users the choice, while
your patch-kernel.sh doesn't.
Of course, the kernel source files always need patching.

• There are no bashishms, and it works with debian's /bin/sh, which is actually 'dash'. Please let me know if you see any errors with any other shells.

I was wrong, sorry.

• If you mean for obtaining kernel, then there are just too arguments against using git. For a non-developer, tar+patch is clearly a better option.
  :::
  • Time, bandwidth and disk resource usage. Test results for linux-4.8.8:
    :::
  • Just having .git directory in kernel source will already screw up local version string.

For the quantity, git-clone is necessary only once. Yes, it requires a
long time, but later git-pull may cost less than tarball I guess.
For the local version string, I don't understand what you are talking
about.

I'd recommend git first,

• run git-clone, and keep the result (full source tree).
• everytime the new kernel is released or whenever you want, run
  git-pull.
• anytime you like, you can get any version by git-checkout.
• additionally, merging aufs source files will be easier. refer to
  README under Documentation/filesystems/aufs/.
• by using git, downloading the tarball for every new kernel and
  patching will be unnecessary.

I believe using git is more flexible and better. But I can understand
that git is not the best tool for non-developers.
So here is my proposal.

• I add a note about your patch-kernel.sh into three README files
  (aufs4-linux.git, aufs4-standalong.git and aufs-util.git).
• you keep the script in your repository, and maintain it if necessary.

How about this?

J. R. Okajima