Den 18.01.2015 23:37, skrev Greg KH:
On Sun, Jan 18, 2015 at 01:00:31PM +0100, Noralf Tronnes wrote:
Den 18.01.2015 03:54, skrev Greg KH:
On Sun, Jan 18, 2015 at 03:26:56AM +0100, Noralf Tronnes wrote:
When I started this rewrite I didn't anticipate fbtft entering the kernel,
and to me it was easier to just start from scratch. However I'd much
rather go with proven practices, so I will do as you suggest.
At least the lcd register abstraction I've worked on, should be more or
less a bolt-on to fbtft.
Great! If you have questions on how to do this, or need help with
making patches, be sure to ask.
I have watched your talk 'Write and Submit your first Linux kernel Patch'
which was instructive. Hopefully that's enough to get me going.
Yes, if you pick the correct branch to work off of.
So if I get this right, this is the tree I'll be basing my work on:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
So what's with the various staging-* branches?
I have 4 branches in that git tree:
master - copy of Linus's tree, used to make patches against.
staging-linus - patches to send to Linus for this -rc series
staging-next - patches to send to Linus for the next -rc series
staging-testing - patches that are being "tested" at the moment,
and will move to staging-next if they pass.
These 28 patches went into staging-testing, and if everything looks ok,
in a day or so will move automatically into staging-next. When the next
kernel is released by Linus (3.19), I will then have him pull from my
staging-next branch during the merge window period (merge windows are
for subsystem maintainers, not normal developers).
Then, after the big merge window is over, I will take bugfixes that need
to get into this kernel release into staging-linus, and stuff for the
next release (new drivers, changes not fixing regressions, etc.) into
the staging-next branch.
staging-next and staging-linus are pulled into the linux-next tree every
day (see Documenatation/development_model/ for more details about all of
this.)
So do your work against staging-testing, and all should be fine.
Does that help?
Yes, thank you, that was enlightning.
What about the umlaut character 'ø' in my name, can I use it in
commit log entries and source code?
I have used: Noralf Tronnes, but it really is: Noralf Trønnes.
Yes please use "Trønnes", it's your name, there is no reason you
shouldn't be allowed to use it, to do otherwise would be rude of us :)
Haha, I was concerned about the machine, that it didn't know what to
do with non-us characters (8-bit ascii), that they would be shown
differently in various parts of the world. I remember DOS code pages.
And because of that there would be a policy against it.
Also I had not seen any non-us characters in the kernel source so far,
until i saw a patch you made yesterday against MAINTAINERS with a 'ø' in it.
Thanks,
Noralf.
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
