Re: [OpenWrt-Devel] SVN to GIT transition

[Steven Barth]

>
> Step 5 is unnecessary, patchwork sends emails on status changes.
Okay, it seems it does this only for the original submitter, right?
I guess it might come in handy to send it to the ML as well, or at
least make that possible in the WebUI.

> I usually copy the mbox link from patchwork and do this: wget -O-  | 
> git am
Yes, I guess that is easier than pwclient. Though it doesn't solve patchsets 
really.


>
>> Compared to Github, Gitlab or Gerrit this is bullshit.
> Even with those, there is some bouncing around in counter-intuitive ways
> if your process includes testing a commit before pushing it.
Yes, this is true and I see that really as the main valid point for criticism.
Ideally you want the "magic merge" only happen to your (local?) branch
and not the main one and then manually send off a batch of staged commits
manually via git push, so that would be the downside of using one of those
tools.

> What would your preferred workflow be? Please list the exact series of
> steps for it.
So to summarize, based on the current workflow:
1. Be able to send mails (and change status) from within patchwork, e.g.
how you can do it in trac, just that it gets send out to the ML and the 
author instead
of being just hidden in some UI.

2. Download a whole set of the patches (e.g. one patch series)
without having to do it for all patches indivdually (e.g. like Github let's 
you download
a whole pull-request as a single patchfile). I'm fine with it even not 
keeping track what
patches belong to which series, but just having e.g. a page with checkboxes 
where
I can tick patches and some where on the bottom click "download series as 
.patch".

3. Have some kind of tool that applies stuff locally (but I guess one could 
write some
handler and associate that with .mbox or .patch and just click on the 
downloaded
patch (serieses) and apply them like that).

4. Ideally have some sort of integration with a bugtracker.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Steven Barth]

Let's face it though: the current workflow wrt. core patches is crappy.

1. Go to patchwork, see if there is a patch
2. If you want to comment, switch to mail client, find thread, write reply.
3. If you want to commit: download patch, go to command line, see if it applies
4. Then manually go back to patchwork and adjust the status of the patch.
5. Upon merging go back to mail and write a mail ala "Patch Accepted".


Sure could use pwclient and ocassionally do, however it does essentially one 
thing
only: save me the download step. Yes, I can also save me the click back to the
browser to hit accept and can do that via CLI (if I remember the cryptic 
switches).
On top of that now I have to deal with an opaque 5 or 6-digit patch id in my 
head.

Compared to Github, Gitlab or Gerrit this is bullshit.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Felix Fietkau]

On 2015-10-12 08:38, Steven Barth wrote:
> Let's face it though: the current workflow wrt. core patches is crappy.
> 
> 1. Go to patchwork, see if there is a patch
> 2. If you want to comment, switch to mail client, find thread, write reply.
> 3. If you want to commit: download patch, go to command line, see if it 
> applies
> 4. Then manually go back to patchwork and adjust the status of the patch.
> 5. Upon merging go back to mail and write a mail ala "Patch Accepted".
Step 5 is unnecessary, patchwork sends emails on status changes.

> Sure could use pwclient and ocassionally do, however it does essentially one 
> thing
> only: save me the download step. Yes, I can also save me the click back to the
> browser to hit accept and can do that via CLI (if I remember the cryptic 
> switches).
> On top of that now I have to deal with an opaque 5 or 6-digit patch id in my 
> head.
I usually copy the mbox link from patchwork and do this:
wget -O-  | git am

> Compared to Github, Gitlab or Gerrit this is bullshit.
Even with those, there is some bouncing around in counter-intuitive ways
if your process includes testing a commit before pushing it.

What would your preferred workflow be? Please list the exact series of
steps for it.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] lldpd: implement a reload hook

[Alexandru Ardelean]

From: Alexandru Ardelean 

Seems the default one is not working as expected.
The way that reload should work is that the 'start' service
call should return 1 (if lldpd is running) and then a normal
restart would be called.

However, for lldpd a reload would mean just clearing all custom TLVs
(if they're configured) and reloading the configuration.

So, this patch adds a reload hook, which would:
 - 'start' lldpd if it's not running (because we return 1 if not running)
 - reload configuration if it is running (also previously 
clearing custom TLVs if present)

Signed-off-by: Alexandru Ardelean 
---
 package/network/services/lldpd/files/lldpd.init | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/package/network/services/lldpd/files/lldpd.init 
b/package/network/services/lldpd/files/lldpd.init
index 3d7d8b9..04e5b8c 100644
--- a/package/network/services/lldpd/files/lldpd.init
+++ b/package/network/services/lldpd/files/lldpd.init
@@ -4,6 +4,8 @@
 START=90
 
 USE_PROCD=1
+LLDPCLI=/usr/sbin/lldpcli
+LLDPSOCKET=/var/run/lldpd.socket
 
 find_release_info()
 {
@@ -71,6 +73,21 @@ start_service() {
procd_close_instance
 }
 
+service_running() {
+   pgrep -x /usr/sbin/lldpd &> /dev/null
+}
+
+reload_service() {
+   running || return 1
+   # Custom TLVs are special and should be
+   # reloaded from config during lldpd reload
+   $LLDPCLI -u $LLDPSOCKET unconfigure lldp custom-tlv &> /dev/null
+   $LLDPCLI -u $LLDPSOCKET -c /etc/lldpd.conf -c /etc/lldpd.d &> /dev/null
+   # Broadcast update over the wire
+   $LLDPCLI -u $LLDPSOCKET update &> /dev/null
+   return 0
+}
+
 stop_service() {
-   rm -f /var/run/lldpd.socket /var/run/lldpd.pid
+   rm -rf /var/run/lldp $LLDPSOCKET
 }
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[John Crispin]

On 12/10/2015 09:07, Steven Barth wrote:
> And don't get me started about having a completely different Issuetracker with
> different credentials etc.

indeed there i this thing called trac which i wonder if people actually
use/look at.

so we really have 3 issues at hand

1) switch the core tree to using git
2) make sure that release branches have a history
3) pull from github trees

1) & 2) are just technical / organizational issues i guess

as for 3), if we move to gihub we have yet another entry point that we
need to look after. ok, we could close trac but that would just move the
"noise" from one place to another. obsoleting the rest of the existing
infra is also a bit quirky i guess as people are using it actively.

there is nothing stopping you right now from setting up a say "network
susbsystem" tree on github that you pull your patches into and once you
have your tree ready you can simply push the changes to the master tree.

John
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Steven Barth]

>> Let's face it though: the current workflow wrt. core patches is crappy.
>>
>> 1. Go to patchwork, see if there is a patch
>> 2. If you want to comment, switch to mail client, find thread, write reply.
>> 3. If you want to commit: download patch, go to command line, see if it 
>> applies
>> 4. Then manually go back to patchwork and adjust the status of the patch.
>> 5. Upon merging go back to mail and write a mail ala "Patch Accepted".
>>
>>
>> Sure could use pwclient and ocassionally do, however it does essentially one 
>> thing
>> only: save me the download step. Yes, I can also save me the click back to 
>> the
>> browser to hit accept and can do that via CLI (if I remember the cryptic 
>> switches).
>> On top of that now I have to deal with an opaque 5 or 6-digit patch id in my 
>> head.
>>
>> Compared to Github, Gitlab or Gerrit this is bullshit.
>>
>
> lets face it, it works very well. if you find it crappy then please
> provide consistent reasons why this is so.
If you find the steps above a sensible workflow,  i.e., I essentially need to 
switch
between 3 different programs having no connection between one another at all
to merge a patch then I don't know what arguments could actually convince you.


> currently having people look at every patch while merging it is very
> usefull and leads to a solid codebase.
So, the assumptions is, because its email everyone reads everything and 
magically
doesn't filter by subject etc. and when you switch to Gitlab or similar people 
suddenly
change?

Tbh. I don't care if its email or some sort of web-based stuff, as long as 
tracking
the patches actually doesn't add more overhead than it delivers value aka. the 
way
we use patchwork.

If we had a patch-tracker that let's me reply (send mail) directly from the gui 
and
optionally doesn't make it a stupid hassle to merge a whole patchset then I 
don't
have a problem with e-mail. I'm sorry that I actually value my free time when 
doing
either volunteer or paid work.

And don't get me started about having a completely different Issuetracker with
different credentials etc.

> having the github "click and merge" stuff will lead to people "clicking
> and merging" and not reviewing it properly.
So, you don't trust the same group of people having push-access if they
would be using a web-interface over the current e-mail approach?

> i understand that some people love to upload their data to us based
> cloud services. but then again i would argue that this is a really illy
> thing to do for a whole number of reasons. first of all our dependence
> on that $corporation
Right, because a self-hosted Gitlab or Gerrit instance will send data to the US.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[John Crispin]

On 12/10/2015 09:36, Felix Fietkau wrote:
>> Sure could use pwclient and ocassionally do, however it does essentially one 
>> thing
>> > only: save me the download step. Yes, I can also save me the click back to 
>> > the
>> > browser to hit accept and can do that via CLI (if I remember the cryptic 
>> > switches).
>> > On top of that now I have to deal with an opaque 5 or 6-digit patch id in 
>> > my head.
> I usually copy the mbox link from patchwork and do this:
> wget -O-  | git am
> 

#!/bin/sh

wget http://patchwork.ozlabs.org/patch/$1/mbox/ -O $1.patch

[ -f $1.patch ] || {
echo "unknown patchwork id"
exit 1
}

git am --3way $1.patch
[ $? = 0 ] || {
mkdir -p fails
cp $1.patch fails/
git am --abort
echo applying $1 FAILED
}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[James Hilliard]

What do you think about using something like Jira for project
management(which is free for open source projects)? I know it was used by
cyanogenmod with decent success. One other potential advantage would be the
possibility of CI testing being tied in more closely.

On Mon, Oct 12, 2015 at 1:46 AM, John Crispin  wrote:

>
>
> On 12/10/2015 08:38, Steven Barth wrote:
> > Let's face it though: the current workflow wrt. core patches is crappy.
> >
> > 1. Go to patchwork, see if there is a patch
> > 2. If you want to comment, switch to mail client, find thread, write
> reply.
> > 3. If you want to commit: download patch, go to command line, see if it
> applies
> > 4. Then manually go back to patchwork and adjust the status of the patch.
> > 5. Upon merging go back to mail and write a mail ala "Patch Accepted".
> >
> >
> > Sure could use pwclient and ocassionally do, however it does essentially
> one thing
> > only: save me the download step. Yes, I can also save me the click back
> to the
> > browser to hit accept and can do that via CLI (if I remember the cryptic
> switches).
> > On top of that now I have to deal with an opaque 5 or 6-digit patch id
> in my head.
> >
> > Compared to Github, Gitlab or Gerrit this is bullshit.
> >
>
>
> lets face it, it works very well. if you find it crappy then please
> provide consistent reasons why this is so.
>
> so far this thread has brought fwd that
>
> * it is crappy
> * Turrit does not work well
> * we think github is better
> * the version history gets lost
>
> the only valid argument i have seen so far is that the history gets
> lost. the rest is just web20 convenient feature requirements.
>
> currently having people look at every patch while merging it is very
> usefull and leads to a solid codebase.
>
> having the github "click and merge" stuff will lead to people "clicking
> and merging" and not reviewing it properly.
>
> i understand that some people love to upload their data to us based
> cloud services. but then again i would argue that this is a really illy
> thing to do for a whole number of reasons. first of all our dependence
> on that $corporation
>
> John
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[John Crispin]

On 12/10/2015 08:38, Steven Barth wrote:
> Let's face it though: the current workflow wrt. core patches is crappy.
> 
> 1. Go to patchwork, see if there is a patch
> 2. If you want to comment, switch to mail client, find thread, write reply.
> 3. If you want to commit: download patch, go to command line, see if it 
> applies
> 4. Then manually go back to patchwork and adjust the status of the patch.
> 5. Upon merging go back to mail and write a mail ala "Patch Accepted".
> 
> 
> Sure could use pwclient and ocassionally do, however it does essentially one 
> thing
> only: save me the download step. Yes, I can also save me the click back to the
> browser to hit accept and can do that via CLI (if I remember the cryptic 
> switches).
> On top of that now I have to deal with an opaque 5 or 6-digit patch id in my 
> head.
> 
> Compared to Github, Gitlab or Gerrit this is bullshit.
> 


lets face it, it works very well. if you find it crappy then please
provide consistent reasons why this is so.

so far this thread has brought fwd that

* it is crappy
* Turrit does not work well
* we think github is better
* the version history gets lost

the only valid argument i have seen so far is that the history gets
lost. the rest is just web20 convenient feature requirements.

currently having people look at every patch while merging it is very
usefull and leads to a solid codebase.

having the github "click and merge" stuff will lead to people "clicking
and merging" and not reviewing it properly.

i understand that some people love to upload their data to us based
cloud services. but then again i would argue that this is a really illy
thing to do for a whole number of reasons. first of all our dependence
on that $corporation

John
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Roman Yeryomin]

On 12 October 2015 at 10:36, Felix Fietkau  wrote:
> On 2015-10-12 08:38, Steven Barth wrote:
>> Let's face it though: the current workflow wrt. core patches is crappy.
>>
>> 1. Go to patchwork, see if there is a patch
>> 2. If you want to comment, switch to mail client, find thread, write reply.
>> 3. If you want to commit: download patch, go to command line, see if it 
>> applies
>> 4. Then manually go back to patchwork and adjust the status of the patch.
>> 5. Upon merging go back to mail and write a mail ala "Patch Accepted".
> Step 5 is unnecessary, patchwork sends emails on status changes.

I think that workflow changes could introduce some pain but those can
be left aside (t.i. kept as is for now) until people get used to git
more and, maybe, develop some new/optimized workflow.
One benefit what git would give, independently from which (main)
workflow is used, is branching, which, IMO, is quite cumbersome right
now.

Regards,
Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Javier Domingo Cansino]

>
> that reminded me to check, and indeed, I only use
> git://git.openwrt.org/openwrt.git anyway :)
>
​
I do use the openwrt mirror github hosts, and I suppose is mirroring that
one.

I think it's already given all the points in Git vs SVN, so I will speak
about self hosting and git interfaces.

I suppose many of you have already worked with Github, Gitlab, gitolite and
gerrit for hosting. I reviewed a book on gitolite a few years ago, I have
been using Github for past 5 years, and made some Gitlab CE self-hosted
instalations.

First of all, I don't like gerrit because of the workflow it imposes and
the limitations compared to Gitlab/Github. gitolite doesn't have a web
interface, is just a git hosting tool, which btw is used for linux dev
since kernel.org was compromised. And gitlab/github are pretty similar.

If you are not willing to change the workflow, nor giving any kind of
enhanced experience, you should probably go with gitolite. It's easy to
manage, and it allows you to manage permissions per-branch, and does even
let you deny pushes depending on the path you modify. Which I have read is
interesting for maintainers. It's a really extensible and complete hosting
tool.

However, I firmly believe that if you are going through any kind of
changing process, you should probably stick with the most accessible tool.

I would propose you installed/hired Gitlab, changed the project to git,
continue with the same workflow, and then decide a proper workflow for your
project while you get accustomed to the new interface. Later, you can
switch to using the gitlab issues / forks / merge requests.

There are tools to migrate issues between systems, so if desired,
historical issues could be maintained.

​I would however not use submodules. You can just rip off the kernel and
treat it as another project, which in my opinion is the best way of
handling multiple projects, rather than including submodules for everything.

Anyway, that last bit it's ok if you want to go with it, from my
experience, I really don't like it, but I have seen project do good with it.


-- 
Javier Domingo Cansino
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Holger Levsen]

Hi,

(just a tiny datapoint...)

On Montag, 12. Oktober 2015, Felix Fietkau wrote:
> Which part is cumbersome for you and how exactly would switching the
> main repo to git solve it?

*g*

that reminded me to check, and indeed, I only use 
git://git.openwrt.org/openwrt.git anyway :)

I *guess* most people can base their work on this anyway already, so maybe 
just give the poor souls still using svn some slack, until they find time and 
ressources to migrate? ;-)


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Felix Fietkau]

On 2015-10-12 10:14, Steven Barth wrote:
>> What would your preferred workflow be? Please list the exact series of
>> steps for it.
> So to summarize, based on the current workflow:
> 1. Be able to send mails (and change status) from within patchwork, e.g.
> how you can do it in trac, just that it gets send out to the ML and the 
> author instead
> of being just hidden in some UI.
Maybe you could suggest that to the patchwork author.

> 2. Download a whole set of the patches (e.g. one patch series)
> without having to do it for all patches indivdually (e.g. like Github 
> let's you download
> a whole pull-request as a single patchfile). I'm fine with it even not 
> keeping track what
> patches belong to which series, but just having e.g. a page with 
> checkboxes where
> I can tick patches and some where on the bottom click "download series as 
> .patch".
Just select a bunch of patches, put in a name at the bottom of the page
and click "Create bundle". You can download that bundle as .mbox

> 3. Have some kind of tool that applies stuff locally (but I guess one could 
> write some
> handler and associate that with .mbox or .patch and just click on the 
> downloaded
> patch (serieses) and apply them like that).
> 
> 4. Ideally have some sort of integration with a bugtracker.
What kind of integration and for what purpose?

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Nemesis]

On 10/12/2015 09:44 AM, John Crispin wrote:
> On 12/10/2015 09:07, Steven Barth wrote:
>> > And don't get me started about having a completely different Issuetracker 
>> > with
>> > different credentials etc.
> indeed there i this thing called trac which i wonder if people actually
> use/look at.
>
> so we really have 3 issues at hand
>
> 1) switch the core tree to using git
> 2) make sure that release branches have a history
> 3) pull from github trees
>
> 1) & 2) are just technical / organizational issues i guess
>
> as for 3), if we move to gihub we have yet another entry point that we
> need to look after. ok, we could close trac but that would just move the
> "noise" from one place to another. obsoleting the rest of the existing
> infra is also a bit quirky i guess as people are using it actively.

The Django Framework moved from SVN to github in 2012but they kept their
own bug tracker (which they redesigned with some funding to make it more
usable): https://code.djangoproject.com/

I think they're a good example of an open source community which went
through the process of improving the way people can join the community
and contribute, they also raise funds to pay for hard tasks like
redesigning the website, organizing sprints, periodically hire a
"fellow" which reviews (accepts/closes and occasionally fixes) tickets
and so on.
Since they started doing this django has improved massively.

I understand the desire to self host, so I suggest to take a look at
gitlab community edition.

Federico


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Felix Fietkau]

On 2015-10-12 10:43, Roman Yeryomin wrote:
> On 12 October 2015 at 10:36, Felix Fietkau  wrote:
>> On 2015-10-12 08:38, Steven Barth wrote:
>>> Let's face it though: the current workflow wrt. core patches is crappy.
>>>
>>> 1. Go to patchwork, see if there is a patch
>>> 2. If you want to comment, switch to mail client, find thread, write reply.
>>> 3. If you want to commit: download patch, go to command line, see if it 
>>> applies
>>> 4. Then manually go back to patchwork and adjust the status of the patch.
>>> 5. Upon merging go back to mail and write a mail ala "Patch Accepted".
>> Step 5 is unnecessary, patchwork sends emails on status changes.
> 
> I think that workflow changes could introduce some pain but those can
> be left aside (t.i. kept as is for now) until people get used to git
> more and, maybe, develop some new/optimized workflow.
> One benefit what git would give, independently from which (main)
> workflow is used, is branching, which, IMO, is quite cumbersome right
> now.
Which part is cumbersome for you and how exactly would switching the
main repo to git solve it?

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Steven Barth]

>>> What would your preferred workflow be? Please list the exact series of
>>> steps for it.
>> So to summarize, based on the current workflow:
>> 1. Be able to send mails (and change status) from within patchwork, e.g.
>> how you can do it in trac, just that it gets send out to the ML and the 
>> author instead
>> of being just hidden in some UI.
> Maybe you could suggest that to the patchwork author.
I guess so.


>
>> 2. Download a whole set of the patches (e.g. one patch series)
>> without having to do it for all patches indivdually (e.g. like Github 
>> let's you download
>> a whole pull-request as a single patchfile). I'm fine with it even not 
>> keeping track what
>> patches belong to which series, but just having e.g. a page with 
>> checkboxes where
>> I can tick patches and some where on the bottom click "download series 
>> as .patch".
> Just select a bunch of patches, put in a name at the bottom of the page
> and click "Create bundle". You can download that bundle as .mbox
Yeah using bundles can sort of do that, but it can get cumbersome quickly as 
well.
You first have to select the patches and create a new bundle, then click on 
bundles,
and click download for the new bundle which I guess is somewhat reasonable.

However once you are done, you have to either - remove accepted patches from the
bundle or kill the whole bundle and start over next time, because the bundle 
always gets
you all patches in it, including the ones accepted or rejected. I guess again, 
its a start but
needs some improvements to feel really convenient. Maybe suggesting a second 
button
to the author "download patches needing action" or so, would do it.


>
>> 4. Ideally have some sort of integration with a bugtracker.
> What kind of integration and for what purpose?
It's mainly having some tool that is integrated, i.e., uses same credentials 
and maybe even the
possibility to close related tickets just by accepting the patches. Using 
entirely different tools just
feels a bit unnecessary. I do not consider that to be an essential issue 
really, more like a nice to have
which you get to like when working with more integrated environments.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Roman Yeryomin]

On 12 October 2015 at 12:04, Holger Levsen  wrote:
> Hi,
>
> (just a tiny datapoint...)
>
> On Montag, 12. Oktober 2015, Felix Fietkau wrote:
>> Which part is cumbersome for you and how exactly would switching the
>> main repo to git solve it?
>
> *g*
>
> that reminded me to check, and indeed, I only use
> git://git.openwrt.org/openwrt.git anyway :)
>

Exactly.
Cumbersome is having multiple repositories, which was probably a
workaround to painful (as opposed to git) branching in svn. At least
it looks like that.

Regards,
Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Felix Fietkau]

On 2015-10-12 11:44, Javier Domingo Cansino wrote:
> that reminded me to check, and indeed, I only use
> git://git.openwrt.org/openwrt.git
>  anyway :)
> 
> ​
> I do use the openwrt mirror github hosts, and I suppose is mirroring
> that one.
> 
> I think it's already given all the points in Git vs SVN, so I will speak
> about self hosting and git interfaces.
> 
> I suppose many of you have already worked with Github, Gitlab, gitolite
> and gerrit for hosting. I reviewed a book on gitolite a few years ago, I
> have been using Github for past 5 years, and made some Gitlab CE
> self-hosted instalations.
> 
> First of all, I don't like gerrit because of the workflow it imposes and
> the limitations compared to Gitlab/Github. gitolite doesn't have a web
> interface, is just a git hosting tool, which btw is used for linux dev
> since kernel.org  was compromised. And gitlab/github
> are pretty similar.
> 
> If you are not willing to change the workflow, nor giving any kind of
> enhanced experience, you should probably go with gitolite. It's easy to
> manage, and it allows you to manage permissions per-branch, and does
> even let you deny pushes depending on the path you modify. Which I have
> read is interesting for maintainers. It's a really extensible and
> complete hosting tool.
FYI, we are already using gitolite on git.openwrt.org.

> However, I firmly believe that if you are going through any kind of
> changing process, you should probably stick with the most accessible tool.
> 
> I would propose you installed/hired Gitlab, changed the project to git,
> continue with the same workflow, and then decide a proper workflow for
> your project while you get accustomed to the new interface. Later, you
> can switch to using the gitlab issues / forks / merge requests.
While it works fine for packages, I don't think the pull request stuff
is very usable for OpenWrt core, which has a more centralized
development model.
One reason why we haven't moved the main repo to git yet is that we lose
the advantage of having revision numbers that propagate to the firmware,
even with builds from a forked repository where some commits have been
added on top.
If we do everything in git, we either have to constantly remember to tag
revisions, or we will lose valuable information when users report bugs
with forked repos.
I also happen to like linear history very much, and SVN enforces that ;)

> There are tools to migrate issues between systems, so if desired,
> historical issues could be maintained.
> 
> ​I would however not use submodules. You can just rip off the kernel and
> treat it as another project, which in my opinion is the best way of
> handling multiple projects, rather than including submodules for everything.
I still believe for our maintenance process it's a bad idea to maintain
the kernel as a separate git repository. With generic changes, it's easy
to lose track of what patch has been applied in which branch, and
syncing them can be annoying with rebases.
Also, pulling changes is going to be confusing for users as well, since
we will have to constantly rebase branches.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2 1/3] ramips: Add DTS files for HiWiFi HC5x61 models

[Yousong Zhou]

On 10 October 2015 at 22:04, 康  wrote:
>
> At 2015-09-29 10:10:41, "Yousong Zhou"  wrote:
>>Hi,
>>
>>Previously this year, there were 2 attempts to add support for HC5661
>>and HC5761 to OpenWrt trunk [1,2].  I only had a HC5661 and it was
>>quite a while ago but the issues then should still remain.
>>
>>The first is about how MAC address is to be read.  The
>>"mtd-mac-address" DTS directives apparently won't work.  And if I
>>remember correctly simply reading and setting it for lan and wan also
>>has flaws that the WiFi interface still get the default hardcoded MAC
>>address by the driver.  The best way I can think of to workaround this
>>is to add a directive similar to what "mtd-mac-address" does for
>>binary-encoded MACs.
>>"target/linux/generic/patches-4.1/681-NET-add-of_get_mac_address_mtd.patch"
>>can work as a reference.
>
> Today I implemented the "mtd-mac-address-ascii" function, ethernet address
> works fine, but WiFi mac address remains the hardcoded one. It seems the
> driver read mac  from factory partition, and unfortunately all HiWiFi
> devices has the same mac in factory data...
>

I see and should have thought of that earlier...

I had the following patch (whitespace clean at [1]) in my local tree
at the time when I found mac addresses of those wifi interfaces were
not right.  Surely it's hacky and a cleaner approach has to be crafted
out.  The patch in link [2] tried to work around this by forging
together an eeprom file with correct mac address, still too hacky I
guess.

Another patch to get phy macaddress like what
package/kernel/mac80211/patches/605-rt2x00-load-eeprom-on-SoC-from-a-mtd-device-defines-.patch
does for ralink,mtd-eeprom?

 [1] http://sprunge.us/eKMI
 [2] ramips:Add support for HiWiFi HC5761,
https://lists.openwrt.org/pipermail/openwrt-devel/2015-April/032643.html

diff --git a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
index e6241de..0d41e1f 100644
--- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
+++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
@@ -1,6 +1,9 @@
 #!/bin/sh
 . /lib/netifd/netifd-wireless.sh
 . /lib/netifd/hostapd.sh
+# Needed by mtd_get_mac_ascii
+. /lib/functions.sh
+. /lib/functions/system.sh

 init_wireless_driver "$@"

@@ -330,9 +333,18 @@ mac80211_generate_mac() {
 local phy="$1"
 local id="${macidx:-0}"

-local ref="$(cat /sys/class/ieee80211/${phy}/macaddress)"
 local mask="$(cat /sys/class/ieee80211/${phy}/address_mask)"

+local ref
+case $(cat /tmp/sysinfo/board_name) in
+hiwifi-hc5661)
+ref=$(mtd_get_mac_ascii "bdinfo" "Vfac_mac ")
+;;
+*)
+ref="$(cat /sys/class/ieee80211/${phy}/macaddress)"
+;;
+esac
+
 [ "$mask" = "00:00:00:00:00:00" ] && mask="ff:ff:ff:ff:ff:ff";
 local oIFS="$IFS"; IFS=":"; set -- $mask; IFS="$oIFS"
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Javier Domingo Cansino]

>
> > since kernel.org  was compromised. And gitlab/github
> > are pretty similar.
>

Sure, just giving some background on where gitolite was being used and the
less-known features it has.

While it works fine for packages, I don't think the pull request stuff
> is very usable for OpenWrt core, which has a more centralized
> development model.
> One reason why we haven't moved the main repo to git yet is that we lose
> the advantage of having revision numbers that propagate to the firmware,
> even with builds from a forked repository where some commits have been
> added on top.
> If we do everything in git, we either have to constantly remember to tag
> revisions, or we will lose valuable information when users report bugs
> with forked repos.
> I also happen to like linear history very much, and SVN enforces that ;)
>
You can enforce linear history by denying history rewrites. It's what they
call now protected branches (IIRC), and I think you can really enforce
that. Also, you can create hooks to check for tagging info etc.

I don't fully understand the 'remember to tag revision' thing.

I still believe for our maintenance process it's a bad idea to maintain
> the kernel as a separate git repository. With generic changes, it's easy
> to lose track of what patch has been applied in which branch, and
> syncing them can be annoying with rebases.
> Also, pulling changes is going to be confusing for users as well, since
> we will have to constantly rebase branches.
>

What I had in mind for the kernel consisted on some similar workflow to the
one gitlab uses for their stable branches. You have a branch for each
maintained kernel release, and you have all the commit's cherry-picked from
the master.

Of course, you can always use rebase and apply all the patches in order. It
is possible to have scripts that actually make sure every patch is applied,
letting you substract patch lists, etc.

Making maintainable the support for several different versions of kernel,
each one on it's branch, forking from the official repo.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Sergey Ryazanov]

Too many voices, which blame svn and almost no advocates. So let me
change this situation.

As an occasional patch maker, I am fairly happy with current workflow
based on git+svn mix. I *think* that this is a good solution exactly
in this case and for this project. May be some random project could
not continue growth without full migration to git, but as a random
developer I don't see any benefits for me in this particular case.

And, as I already wrote, I really like linear history and short
revision numbers of SVN :)

-- 
Sergey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Felix Fietkau]

On 2015-10-12 15:09, Javier Domingo Cansino wrote:
> Right now, the revision number (r) is really useful to figure
> out what particular openwrt version is being used, when people report
> bugs. The commit hash cannot be used as a replacement, since it might be
> one that isn't present in the official repo.
> When using tags as a starting point (via git describe), somebody has to
> create those tags, which is cumbersome (and would mean adding lots of
> useless ones).
> 
> The tags would be the major versions and RCs. I don't believe other tags
> should be used.
> 
> Apart from that, I understand that if someone cloned the SVN repo (full
> svn history), created it's own server, and developed on top of a given
> revision X, the same problem would arise.
I haven't seen a single instance of somebody doing this, and in my
opinion it would be kind of stupid anyway :)
We don't even advertise the SVN server URL to users anymore for a reason.

> I don't find this as a valid argument because that's up to the user.
> Either you fork from official owrt and note down the commit you forked
> in to give as a reference, or you provide full access to your source
> code, where you can actually see when it forked through git merge-base
> --fork-point.
And you think users will actually do that? Based on previous experience,
I really don't. The way it's set up right now, people can fork as they
wish and the scripts automatically determining the OpenWrt base version
will just work.

> And of course, you can always automatically generate with help from
> git-describe a relative revision from the fork-point. Anyway, it would
> be up to the forkers to decide whether they want to rebase their tree or
> merge your tree.
It's not about what you theoretically can do, it's about what users will
end up doing.

> Well, we have per-target kernel patches. Patches from different targets
> might conflict with each other, or might break unrelated targets.
> Dealing with that would mean either carefully reviewing every single
> target patch to avoid negative side effects for other targets, or
> maintaining one branch per target.
> For both variants, the amount of extra work this creates in my opinion
> vastly outweighs the benefits of using git for the kernel tree.
> 
> I believe that we could find a mix between per kernel version patches
> and per target patches. Probably the best would be to treat the openwrt
> kernel as a project forking from linux-stable (I believe it's the
> tarballs you are currently using), and use that owrt kernel as a base to
> apply the per target patches (at the end, each target has it's own
> specific patches).
Wow, now you're making it really confusing for everybody involved. Some
changes live in an external git repo, some changes live as patches, and
whenever the external repo changes we're supposed to update the revision
in the OpenWrt tree?

> I find it as repackaging the same project with different patches to add
> functionality.
> 
> I'm open to changing my mind if I see some compelling arguments, but
> right now I believe the extra maintenance cost vastly outweighs the
> potential benefits.
> 
> My proposal of steps to migrate to git would be.
>  1) openwrt to git, maintaining even the workflow as it is, giving time
> to deal with all the differences to svn (such as the relative revision
> crafting etc).
I haven't seen any proposal that deals with the revision crafting issue
in a practical and useful way. I also haven't seen many compelling
arguments about what the practical benefit of these changes would be.

I see repeated claims that assume that having patches in a git repo will
make it easier to upstream stuff, and I just don't believe those claims
without a proper explanation.

> Once everyone is comfortable with the git based hosting, I would go for
> 2) adapting the workflow to the tools git provides. We would be talking
> there about how merge requests are handled, web interfaces, etc.
> Finally, I would go for step 3) check how we can improve the owrt-kernel
> relationship.
> 
> Of course, the 3rd step, if based in my idea, doesn't need to be done
> before 1/2. Also, steps 1,2 can be done at once.
Before you try to convince us to change the workflow, I would really
like to see a *detailed* explanation of how this would actually help us.
If you really believe that this would be a good fit, then you will have
to be a lot more specific about the potential benefits.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Javier Domingo Cansino]

>
> Right now, the revision number (r) is really useful to figure
> out what particular openwrt version is being used, when people report
> bugs. The commit hash cannot be used as a replacement, since it might be
> one that isn't present in the official repo.
> When using tags as a starting point (via git describe), somebody has to
> create those tags, which is cumbersome (and would mean adding lots of
> useless ones).
>
The tags would be the major versions and RCs. I don't believe other tags
should be used.

Apart from that, I understand that if someone cloned the SVN repo (full svn
history), created it's own server, and developed on top of a given revision
X, the same problem would arise.

I don't find this as a valid argument because that's up to the user. Either
you fork from official owrt and note down the commit you forked in to give
as a reference, or you provide full access to your source code, where you
can actually see when it forked through git merge-base --fork-point.

And of course, you can always automatically generate with help from
git-describe a relative revision from the fork-point. Anyway, it would be
up to the forkers to decide whether they want to rebase their tree or merge
your tree.

Well, we have per-target kernel patches. Patches from different targets
> might conflict with each other, or might break unrelated targets.
> Dealing with that would mean either carefully reviewing every single
> target patch to avoid negative side effects for other targets, or
> maintaining one branch per target.
> For both variants, the amount of extra work this creates in my opinion
> vastly outweighs the benefits of using git for the kernel tree.
>
> I believe that we could find a mix between per kernel version patches and
per target patches. Probably the best would be to treat the openwrt kernel
as a project forking from linux-stable (I believe it's the tarballs you are
currently using), and use that owrt kernel as a base to apply the per
target patches (at the end, each target has it's own specific patches).

I find it as repackaging the same project with different patches to add
functionality.

I'm open to changing my mind if I see some compelling arguments, but
> right now I believe the extra maintenance cost vastly outweighs the
> potential benefits.
>
My proposal of steps to migrate to git would be.
 1) openwrt to git, maintaining even the workflow as it is, giving time to
deal with all the differences to svn (such as the relative revision
crafting etc).
Once everyone is comfortable with the git based hosting, I would go for 2)
adapting the workflow to the tools git provides. We would be talking there
about how merge requests are handled, web interfaces, etc.
Finally, I would go for step 3) check how we can improve the owrt-kernel
relationship.

Of course, the 3rd step, if based in my idea, doesn't need to be done
before 1/2. Also, steps 1,2 can be done at once.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Felix Fietkau]

On 2015-10-12 14:29, Javier Domingo Cansino wrote:
> While it works fine for packages, I don't think the pull request stuff
> is very usable for OpenWrt core, which has a more centralized
> development model.
> One reason why we haven't moved the main repo to git yet is that we lose
> the advantage of having revision numbers that propagate to the firmware,
> even with builds from a forked repository where some commits have been
> added on top.
> If we do everything in git, we either have to constantly remember to tag
> revisions, or we will lose valuable information when users report bugs
> with forked repos.
> I also happen to like linear history very much, and SVN enforces that ;)
> 
> You can enforce linear history by denying history rewrites. It's what
> they call now protected branches (IIRC), and I think you can really
> enforce that. Also, you can create hooks to check for tagging info etc. 
> 
> I don't fully understand the 'remember to tag revision' thing.
Right now, the revision number (r) is really useful to figure
out what particular openwrt version is being used, when people report
bugs. The commit hash cannot be used as a replacement, since it might be
one that isn't present in the official repo.
When using tags as a starting point (via git describe), somebody has to
create those tags, which is cumbersome (and would mean adding lots of
useless ones).

> I still believe for our maintenance process it's a bad idea to maintain
> the kernel as a separate git repository. With generic changes, it's easy
> to lose track of what patch has been applied in which branch, and
> syncing them can be annoying with rebases.
> Also, pulling changes is going to be confusing for users as well, since
> we will have to constantly rebase branches.
> 
>  
> What I had in mind for the kernel consisted on some similar workflow to
> the one gitlab uses for their stable branches. You have a branch for
> each maintained kernel release, and you have all the commit's
> cherry-picked from the master.
Well, we have per-target kernel patches. Patches from different targets
might conflict with each other, or might break unrelated targets.
Dealing with that would mean either carefully reviewing every single
target patch to avoid negative side effects for other targets, or
maintaining one branch per target.
For both variants, the amount of extra work this creates in my opinion
vastly outweighs the benefits of using git for the kernel tree.

> Of course, you can always use rebase and apply all the patches in order.
> It is possible to have scripts that actually make sure every patch is
> applied, letting you substract patch lists, etc.
If we keep rebasing, people get confused when working on the tree and
running git pull.

> Making maintainable the support for several different versions of
> kernel, each one on it's branch, forking from the official repo.
I'm open to changing my mind if I see some compelling arguments, but
right now I believe the extra maintenance cost vastly outweighs the
potential benefits.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Bruno Randolf]

On 10/12/2015 01:43 PM, Felix Fietkau wrote:
> When using tags as a starting point (via git describe), somebody has to
> create those tags, which is cumbersome (and would mean adding lots of
> useless ones).

What's cumbersome? And why would you have to create useless tags?

I would actually take this argument on the reverse and say it's good,
because it forces you to tag revisions which should be tagged (like
"15.05-rc1", "15.05").

bruno
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Sergey Ryazanov]

2015-10-12 15:04 GMT+03:00 Felix Fietkau :
> While it works fine for packages, I don't think the pull request stuff
> is very usable for OpenWrt core, which has a more centralized
> development model.
> One reason why we haven't moved the main repo to git yet is that we lose
> the advantage of having revision numbers that propagate to the firmware,
> even with builds from a forked repository where some commits have been
> added on top.
> If we do everything in git, we either have to constantly remember to tag
> revisions, or we will lose valuable information when users report bugs
> with forked repos.
> I also happen to like linear history very much, and SVN enforces that ;)
>

+1

IMHO, this is the most useful capability of SVN for core of big projects.

-- 
Sergey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Roman Yeryomin]

On 12 October 2015 at 16:34, Felix Fietkau  wrote:
> On 2015-10-12 15:09, Javier Domingo Cansino wrote:
>> Right now, the revision number (r) is really useful to figure
>> out what particular openwrt version is being used, when people report
>> bugs. The commit hash cannot be used as a replacement, since it might be
>> one that isn't present in the official repo.
>> When using tags as a starting point (via git describe), somebody has to
>> create those tags, which is cumbersome (and would mean adding lots of
>> useless ones).
>>
>> The tags would be the major versions and RCs. I don't believe other tags
>> should be used.
>>
>> Apart from that, I understand that if someone cloned the SVN repo (full
>> svn history), created it's own server, and developed on top of a given
>> revision X, the same problem would arise.
> I haven't seen a single instance of somebody doing this, and in my
> opinion it would be kind of stupid anyway :)
> We don't even advertise the SVN server URL to users anymore for a reason.
>

IMO git describe --dirty would work perfectly. You would see a short
hash and if user modified it or not.
For users it would work even better than svn revision.
For devs or users who do commit locally both svn and git "revisions"
can be "spoofed" anyway so it just useless.
oh.. sorry, I forgot that you cannot commit locally with svn...

Regards,
Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Felix Fietkau]

On 2015-10-12 16:11, Roman Yeryomin wrote:
> On 12 October 2015 at 16:34, Felix Fietkau  wrote:
>> On 2015-10-12 15:09, Javier Domingo Cansino wrote:
>>> Right now, the revision number (r) is really useful to figure
>>> out what particular openwrt version is being used, when people report
>>> bugs. The commit hash cannot be used as a replacement, since it might be
>>> one that isn't present in the official repo.
>>> When using tags as a starting point (via git describe), somebody has to
>>> create those tags, which is cumbersome (and would mean adding lots of
>>> useless ones).
>>>
>>> The tags would be the major versions and RCs. I don't believe other tags
>>> should be used.
>>>
>>> Apart from that, I understand that if someone cloned the SVN repo (full
>>> svn history), created it's own server, and developed on top of a given
>>> revision X, the same problem would arise.
>> I haven't seen a single instance of somebody doing this, and in my
>> opinion it would be kind of stupid anyway :)
>> We don't even advertise the SVN server URL to users anymore for a reason.
>>
> 
> IMO git describe --dirty would work perfectly. You would see a short
> hash and if user modified it or not.
If the user made a local commit, the short hash becomes useless.

> For users it would work even better than svn revision.
> For devs or users who do commit locally both svn and git "revisions"
> can be "spoofed" anyway so it just useless.
It's not about whether they can be spoofed or not. Users typically don't
spoof revisions because that would be a stupid and far fetched thing to
do when reporting a bug.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Bruno Randolf]

On 10/11/2015 01:48 PM, John Crispin wrote:
> although i see the point, out of tree fork have never been relevant to
> any core decision makings

I understand that this is not the main concern for core OpenWRT
developers, but on the other hand you must be aware that there exist
several of these "forks" which carry project or vendor specific changes,
stuff that can't be made OpenWRT trunk compatible, or not yet, or only
in parts, etc... and making it easier for these "forks" to merge OpenWRT
releases also makes it easier to merge project specific improvements
back to OpenWRT trunk. Otherwise these "forks" stay real forks, which
branch off at some revision and never merge again. That's why I think it
would be good for OpenWRT to allow easier merging in all directions.

Apart from that of course, the OpenWRT core developers are a pretty
small team, and a centralized model may fit them well, especially if
they don't want to include more people in the process. The decision is
up to the core developers.

bruno
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH procd] cmake: use CMAKE_INSTALL_* variables

[Felix Fietkau]

On 2015-09-17 13:54, Sergiy Kibrik wrote:
> Replace hard-coded installation directories with cmake-provided
> variables, which gives more flexibility on where to install
> final binaries. Great simplification for usage with e.g. BitBake recipes.
> 
> Signed-off-by: Sergiy Kibrik 
Doesn't work for me:

CMake Error at CMakeLists.txt:15 (INSTALL):
  install TARGETS given no LIBRARY DESTINATION for shared library target
  "setlbf".


CMake Error at CMakeLists.txt:41 (INSTALL):
  install TARGETS given no RUNTIME DESTINATION for executable target
"procd".


CMake Error at CMakeLists.txt:49 (INSTALL):
  install TARGETS given no RUNTIME DESTINATION for executable target "init".


CMake Error at CMakeLists.txt:55 (INSTALL):
  install TARGETS given no RUNTIME DESTINATION for executable target
  "udevtrigger".


CMake Error at CMakeLists.txt:61 (INSTALL):
  install TARGETS given no RUNTIME DESTINATION for executable target
  "askfirst".


-- Configuring incomplete, errors occurred!
See also "/Users/nbd/procd/CMakeFiles/CMakeOutput.log".

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Javier Domingo Cansino]

>
> I haven't seen a single instance of somebody doing this, and in my
> opinion it would be kind of stupid anyway :)
> We don't even advertise the SVN server URL to users anymore for a reason.
>

This was a way to demonstrate that the forking point is not actually a
problem SVN solves. Not having a similar revision number that collides with
the one used in official repo is now sustained by the fact that you are the
only ones using SVN.

And you think users will actually do that? Based on previous experience,
> I really don't. The way it's set up right now, people can fork as they
> wish and the scripts automatically determining the OpenWrt base version
> will just work.
>
That's the work that needs to be done, although there are plenty forks over
there with a solution to that. I have seen them at least, but I can't
provide code :(, so if someone has a solution that can share, shall
intervene here.

It's not about what you theoretically can do, it's about what users will
> end up doing.
>
That doesn't affect your workflow. At the end you will have the same
problems as you have now because people is already using git to interact
with openwrt. They provide a forking base, and there you go.


> Wow, now you're making it really confusing for everybody involved. Some
> changes live in an external git repo, some changes live as patches, and
> whenever the external repo changes we're supposed to update the revision
> in the OpenWrt tree?
>

I am really sorry but I haven't worked enough with the kernel part as to
say how maintainable would this solution be. I was just giving another
alternative to submodules.

Just in case, my advice here was not to use submodules. It was just a git
advice rather than an openwrt git based advice.


> I haven't seen any proposal that deals with the revision crafting issue
> in a practical and useful way. I also haven't seen many compelling
> arguments about what the practical benefit of these changes would be.
>
> I see repeated claims that assume that having patches in a git repo will
> make it easier to upstream stuff, and I just don't believe those claims
> without a proper explanation.
>
I find this paragraph confusing because I don't really know if you are
referring to the kernel in openwrt, or to openwrt as a whole.

In the first case, I just want to say that it is possible to work with
submodules, but it costs you brain-cpu to do it correctly most of the
times. That's why my advice against submodules. I can further expand if
someone wants to know which solutions I have seen correctly working.

In the second case, from what I do, I would find much easier to have a git
based openwrt, not for git itself (I am already using it), but for the
tools (step 2) and workflows you can have. I expand this below.


> Before you try to convince us to change the workflow, I would really
> like to see a *detailed* explanation of how this would actually help us.
> If you really believe that this would be a good fit, then you will have
> to be a lot more specific about the potential benefits.
>

The benefits of the openwrt git based developing are the next ones, based
on previous experience, using Github as a model, similar applies to Gitlab:
 - Easier to get started with openwrt trivial contributions. If I find a
typo, I can directly from the web interface fork, change and PR to the main
repo.
 - Easier tracking of the status of my patch, the issues I have submitted
and the pending work. This is mostly because UIs/workflows are pretty
complete.
 - Easier way to update my patch, less noise to the list. I always get it
wrong, and resubmitting when it is just some formatting issues is far less
noisy. With github/gitlab, I just have to checkout the branch I am sending
my patch from and do whatever I need to make it
openwrt-contribution-guidelines compliant.
 - Review of my patches. I can actually track if I have done everything
needed to get my patch accepted. Past day I submitted a simple patch to
libubox and I forgot to reorder variable declarations. Also, more clear,
non mailbox dependant patch review, In a glance I can see my patch, the
comments it has, and the conversation about specific lines, even if I am
not suscribed.
 - More user friendly. I know this might not be important for some people,
but most of the users out there willing to help, although not excelent
devs, may be able to help if they have tons of tutorials on how to use the
web interface.
 - Of course, you still can do everything as you already do, you checkout
the branch from the PR and commit it manually, and github/gitlab will
detect you merged that commit and will close the PR.

As you see, these are mostly user experience improvements. Maybe for you
make no difference at all while core developing, but I find those benefits
really worthy. I have seen others state some of them too.

Just to finish, I think this conversion from svn to git doesn't have as
main objective to make your life as core devs easier although it will

Re: [OpenWrt-Devel] SVN to GIT transition

[Felix Fietkau]

On 2015-10-12 16:20, Javier Domingo Cansino wrote:
> I haven't seen a single instance of somebody doing this, and in my
> opinion it would be kind of stupid anyway :)
> We don't even advertise the SVN server URL to users anymore for a
> reason.
> 
> 
> This was a way to demonstrate that the forking point is not actually a
> problem SVN solves. Not having a similar revision number that collides
> with the one used in official repo is now sustained by the fact that you
> are the only ones using SVN.
Please don't try to argue with me based on unlikely hypothetical
scenarios of what somebody could do (but never does). I'm interested in
stuff that works in practice.

> And you think users will actually do that? Based on previous experience,
> I really don't. The way it's set up right now, people can fork as they
> wish and the scripts automatically determining the OpenWrt base version
> will just work.
> 
> That's the work that needs to be done, although there are plenty forks
> over there with a solution to that. I have seen them at least, but I
> can't provide code :(, so if someone has a solution that can share,
> shall intervene here.
I have yet to see an approach for this that actually works and deals
with all the common scenarios where people fork OpenWrt and make a few
local changes.

> It's not about what you theoretically can do, it's about what users will
> end up doing.
> 
> That doesn't affect your workflow. At the end you will have the same
> problems as you have now because people is already using git to interact
> with openwrt. They provide a forking base, and there you go.
What users end up doing DOES affect our workflow. If asking users to
provide version information from stuff running on their routers gets
more complicated because local commits might obscure the revision hash,
then that creates more work for us devs.

> Wow, now you're making it really confusing for everybody involved. Some
> changes live in an external git repo, some changes live as patches, and
> whenever the external repo changes we're supposed to update the revision
> in the OpenWrt tree?
> 
> 
> I am really sorry but I haven't worked enough with the kernel part as to
> say how maintainable would this solution be. I was just giving another
> alternative to submodules.
> 
> Just in case, my advice here was not to use submodules. It was just a
> git advice rather than an openwrt git based advice. 
And I've actually given much thought to the cost and benefits of our
current workflow vs doing it in git. My main problem is not with the
part of submodules vs external stuff, it's with the workflow of
maintaining our kernel changes in a git repo directly instead of having
patches.

> I haven't seen any proposal that deals with the revision crafting issue
> in a practical and useful way. I also haven't seen many compelling
> arguments about what the practical benefit of these changes would be.
> 
> I see repeated claims that assume that having patches in a git repo will
> make it easier to upstream stuff, and I just don't believe those claims
> without a proper explanation.
> 
> I find this paragraph confusing because I don't really know if you are
> referring to the kernel in openwrt, or to openwrt as a whole.
This was referring to having the openwrt kernel stuff in git.

> In the first case, I just want to say that it is possible to work with
> submodules, but it costs you brain-cpu to do it correctly most of the
> times. That's why my advice against submodules. I can further expand if
> someone wants to know which solutions I have seen correctly working.
> 
> In the second case, from what I do, I would find much easier to have a
> git based openwrt, not for git itself (I am already using it), but for
> the tools (step 2) and workflows you can have. I expand this below.
>  
> 
> Before you try to convince us to change the workflow, I would really
> like to see a *detailed* explanation of how this would actually help us.
> If you really believe that this would be a good fit, then you will have
> to be a lot more specific about the potential benefits.
> 
> 
> The benefits of the openwrt git based developing are the next ones,
> based on previous experience, using Github as a model, similar applies
> to Gitlab:
>  - Easier to get started with openwrt trivial contributions. If I find a
> typo, I can directly from the web interface fork, change and PR to the
> main repo.
Typo fixes are the least relevant changes. Making it easier to do that
kind of change is not a priority, especially if other things are made worse.

>  - Easier tracking of the status of my patch, the issues I have
> submitted and the pending work. This is mostly because UIs/workflows are
> pretty complete.
We have patchwork for tracking submissions, and people get notified when
their patches are accepted or rejected.

>  - Easier way to update my patch, less noise to the 

Re: [OpenWrt-Devel] SVN to GIT transition

[Jonathan Bennett]

On Mon, Oct 12, 2015 at 2:11 PM David Lang  wrote:

> On Mon, 12 Oct 2015, Felix Fietkau wrote:
>
> > On 2015-10-12 16:11, Roman Yeryomin wrote:
> >> On 12 October 2015 at 16:34, Felix Fietkau  wrote:
> >>> On 2015-10-12 15:09, Javier Domingo Cansino wrote:
>  Right now, the revision number (r) is really useful to
> figure
>  out what particular openwrt version is being used, when people
> report
>  bugs. The commit hash cannot be used as a replacement, since it
> might be
>  one that isn't present in the official repo.
>  When using tags as a starting point (via git describe), somebody
> has to
>  create those tags, which is cumbersome (and would mean adding
> lots of
>  useless ones).
> 
>  The tags would be the major versions and RCs. I don't believe other
> tags
>  should be used.
> 
>  Apart from that, I understand that if someone cloned the SVN repo
> (full
>  svn history), created it's own server, and developed on top of a given
>  revision X, the same problem would arise.
> >>> I haven't seen a single instance of somebody doing this, and in my
> >>> opinion it would be kind of stupid anyway :)
> >>> We don't even advertise the SVN server URL to users anymore for a
> reason.
> >>>
> >>
> >> IMO git describe --dirty would work perfectly. You would see a short
> >> hash and if user modified it or not.
> > If the user made a local commit, the short hash becomes useless.
>
> if the user does a SVN checkout and then modifies things, the r is
> also
> not valid (although it does give you an idea where things branched)
>
> David Lang

His point is that users don't ever do an SVN checkout. Because the r number
is baked into the image, it's a really easy and obvious way for an end user
to report the revision in a bug report.  I can see the advantage in this.
If we are to move to git, we would want some way to preserve this feature,
that is a super easy way for a user to report the revision.  We could bake
the short hash into the image, but this would not be useful if any commits
were added locally, whereas the r number would still show some useful
information.

Would it be possible to track the revision number in an automated way even
in a git repo?  So store the r number, and automatically increment on
commits.  Not sure if that's an option, but it seems like it might address
the problem.

--Jonathan Bennett
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Felix Fietkau]

On 2015-10-12 22:06, David Lang wrote:
> On Mon, 12 Oct 2015, Jonathan Bennett wrote:
> 
>> His point is that users don't ever do an SVN checkout. Because the r number
>> is baked into the image, it's a really easy and obvious way for an end user
>> to report the revision in a bug report.  I can see the advantage in this.
>> If we are to move to git, we would want some way to preserve this feature,
>> that is a super easy way for a user to report the revision.  We could bake
>> the short hash into the image, but this would not be useful if any commits
>> were added locally, whereas the r number would still show some useful
>> information.
>>
>> Would it be possible to track the revision number in an automated way even
>> in a git repo?  So store the r number, and automatically increment on
>> commits.  Not sure if that's an option, but it seems like it might address
>> the problem.
> 
> It sounds like what you really want to do is to have the nightly build embed 
> the 
> date of the build in the image and have people report that.
Many people build from source and don't use nightly builds.

> If someone checks out the source and compiles a new copy (with local 
> modifications), reporting a SVN version is as misleading as a git hash.
It may not always be accurate, but the SVN version is actually useful in
most cases, even when modifications are present.

> I know that various projects I work with have the build process embed the 
> date 
> in the package versions, so it should be straightforward to put it into some 
> file in the resulting firmware image. Such a process can also check if it's 
> running on the 'official' tree or in someone else's repo (check repo 
> owner/e-mail) and add the initials of the person compiling it.
What I don't understand is how the script should check if something is
the official tree, e.g. in the simple case of somebody having forked the
OpenWrt mirror on github, cloned it locally, added and pushed a few
commits and then made a build.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[David Lang]

On Mon, 12 Oct 2015, Felix Fietkau wrote:


On 2015-10-12 22:06, David Lang wrote:

On Mon, 12 Oct 2015, Jonathan Bennett wrote:


His point is that users don't ever do an SVN checkout. Because the r number
is baked into the image, it's a really easy and obvious way for an end user
to report the revision in a bug report.  I can see the advantage in this.
If we are to move to git, we would want some way to preserve this feature,
that is a super easy way for a user to report the revision.  We could bake
the short hash into the image, but this would not be useful if any commits
were added locally, whereas the r number would still show some useful
information.

Would it be possible to track the revision number in an automated way even
in a git repo?  So store the r number, and automatically increment on
commits.  Not sure if that's an option, but it seems like it might address
the problem.


It sounds like what you really want to do is to have the nightly build embed the
date of the build in the image and have people report that.

Many people build from source and don't use nightly builds.


If someone checks out the source and compiles a new copy (with local
modifications), reporting a SVN version is as misleading as a git hash.

It may not always be accurate, but the SVN version is actually useful in
most cases, even when modifications are present.


I know that various projects I work with have the build process embed the date
in the package versions, so it should be straightforward to put it into some
file in the resulting firmware image. Such a process can also check if it's
running on the 'official' tree or in someone else's repo (check repo
owner/e-mail) and add the initials of the person compiling it.


What I don't understand is how the script should check if something is
the official tree, e.g. in the simple case of somebody having forked the
OpenWrt mirror on github, cloned it locally, added and pushed a few
commits and then made a build.


git config --get user.name
git config --get user.email

if they are set to the name of the official buildbot, no nothing. If they are 
set to anything else, take some data (initials or something) and make that part 
of the version number.


It's not checking if it's an unmodified tree, just if it's being built on the 
OpenWRT infrastructure.


If someone is building an unmodified tree, the git hash will work for 
identifying what tree it is. And someone else posted a process for trackign 
divergence from the upstream tree if they are modifying it first.


David Lang
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[David Lang]

On Mon, 12 Oct 2015, Felix Fietkau wrote:


On 2015-10-12 22:02, Javier Domingo Cansino wrote:

Would it be possible to track the revision number in an automated
way even in a git repo?  So store the r number, and automatically
increment on commits.  Not sure if that's an option, but it seems
like it might address the problem.


In git you wouldn't need such thing, the way would be to track the
forking point comparing the user history with the upstream master
history, and describing the path. The oneliner I sent before (which I
now realize I split in two), did (or will do) the following.

1) Go back in history and find the latest tag, save it as $tag

We currently don't have any tags for mainline trunk, since we usually
don't directly release from it.


I would put a nightly tag in place (tags are pretty cheap)


2) Find the forking point between upstream and user branch if any, save
current commit if not such fork exists as $parent.

How does the script know which one is the right upstream?


git knows where it was cloned from, so it knows what upstream is for any local 
branch.



3) count how many commits are from $tag commit to $parent commit, save
it as $parent_n
3) If fork exists, count how many commits from $parent to HEAD, save it
as $commit_n
4) If tree is dirty, save $dirty='-dirty', else $dirty=''

compose the build version info as the following:

$tag-$parent_n-$parent-$commit_n-$parent$dirty

If I see such a string, how do I look up the last OpenWrt commit from
that? With the revision number, I simply start git log and search for
@


if you make a nightly/weekly tag it becomes trivial to lookup. you can also use 
the first 6/8 characters of the git commit and look that up (or git log 
12345678..HEAD to show everything between that commit and the current head)


David Lang
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Michael Büsch]

On Mon, 12 Oct 2015 14:04:09 +0200
Felix Fietkau  wrote:

> If we do everything in git, we either have to constantly remember to tag
> revisions,

Only some milestones would have to be tagged on a regular basis. This
could even be done automatically with a daily tag or such.
git describe will do the rest. It will do even more than svn revisions,
because it includes (part of) the hash.

-- 
Michael


pgpnElG2SDkAc.pgp
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Felix Fietkau]

On 2015-10-12 22:28, David Lang wrote:
> On Mon, 12 Oct 2015, Felix Fietkau wrote:
> 
>> On 2015-10-12 22:02, Javier Domingo Cansino wrote:
>>> Would it be possible to track the revision number in an automated
>>> way even in a git repo?  So store the r number, and automatically
>>> increment on commits.  Not sure if that's an option, but it seems
>>> like it might address the problem.
>>>
>>>
>>> In git you wouldn't need such thing, the way would be to track the
>>> forking point comparing the user history with the upstream master
>>> history, and describing the path. The oneliner I sent before (which I
>>> now realize I split in two), did (or will do) the following.
>>>
>>> 1) Go back in history and find the latest tag, save it as $tag
>> We currently don't have any tags for mainline trunk, since we usually
>> don't directly release from it.
> 
> I would put a nightly tag in place (tags are pretty cheap)
Sounds nasty.

>>> 2) Find the forking point between upstream and user branch if any, save
>>> current commit if not such fork exists as $parent.
>> How does the script know which one is the right upstream?
> 
> git knows where it was cloned from, so it knows what upstream is for any 
> local 
> branch.
Yeah, but where it was cloned from might not be OpenWrt upstream.

>>> 3) count how many commits are from $tag commit to $parent commit, save
>>> it as $parent_n
>>> 3) If fork exists, count how many commits from $parent to HEAD, save it
>>> as $commit_n
>>> 4) If tree is dirty, save $dirty='-dirty', else $dirty=''
>>>
>>> compose the build version info as the following:
>>>
>>> $tag-$parent_n-$parent-$commit_n-$parent$dirty
>> If I see such a string, how do I look up the last OpenWrt commit from
>> that? With the revision number, I simply start git log and search for
>> @
> 
> if you make a nightly/weekly tag it becomes trivial to lookup. you can also 
> use 
> the first 6/8 characters of the git commit and look that up (or git log 
> 12345678..HEAD to show everything between that commit and the current head)
The lookup only works if the tags were carried over as well. Not sure if
that's the case when somebody does a github fork of the mirror repo.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Javier Domingo Cansino]

>
> We currently don't have any tags for mainline trunk, since we usually
> don't directly release from it.
>

I would like to know how you usually release. Can you map a commit to a
release, if you can't, then we may use another simpler method.

$parent-$commit$dirty

That would give you info enought to checkout either the $parent, if you
don't have access to $commit, and to know that something was changed in
$commit.


> How does the script know which one is the right upstream?
>
It's hardcoded in the version script. If remote doesn't exist, I can inject
it temporarily, bad thing is that I would need to fetch upstream to be able
to compare AFAIK. If the remote does exist, I can just generate it from
there (don't need to have latest commit to know where they forked)


> If I see such a string, how do I look up the last OpenWrt commit from
> that? With the revision number, I simply start git log and search for
> @
>
The number of commits are just for people that comes from SVN to feel
comfortable. You don't really need them. You can have the number of
previous commits if you wish, but is not needed really (it might be an
indicative on how much work there is)

We could do fancy things like instead of logging the number of commits, log
the number of diff lines.

$parent-$commit-$difflines$dirty.

However I find this rather disturbing and even privacy compromising.

I think I could provide the proper solution if you tell me what you thing
would be useful for you to have.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Felix Fietkau]

On 2015-10-12 22:19, David Lang wrote:
> On Mon, 12 Oct 2015, Felix Fietkau wrote:
> 
>> On 2015-10-12 22:06, David Lang wrote:
>>> On Mon, 12 Oct 2015, Jonathan Bennett wrote:
>>>
 His point is that users don't ever do an SVN checkout. Because the r number
 is baked into the image, it's a really easy and obvious way for an end user
 to report the revision in a bug report.  I can see the advantage in this.
 If we are to move to git, we would want some way to preserve this feature,
 that is a super easy way for a user to report the revision.  We could bake
 the short hash into the image, but this would not be useful if any commits
 were added locally, whereas the r number would still show some useful
 information.

 Would it be possible to track the revision number in an automated way even
 in a git repo?  So store the r number, and automatically increment on
 commits.  Not sure if that's an option, but it seems like it might address
 the problem.
>>>
>>> It sounds like what you really want to do is to have the nightly build 
>>> embed the
>>> date of the build in the image and have people report that.
>> Many people build from source and don't use nightly builds.
>>
>>> If someone checks out the source and compiles a new copy (with local
>>> modifications), reporting a SVN version is as misleading as a git hash.
>> It may not always be accurate, but the SVN version is actually useful in
>> most cases, even when modifications are present.
>>
>>> I know that various projects I work with have the build process embed the 
>>> date
>>> in the package versions, so it should be straightforward to put it into some
>>> file in the resulting firmware image. Such a process can also check if it's
>>> running on the 'official' tree or in someone else's repo (check repo
>>> owner/e-mail) and add the initials of the person compiling it.
>>
>> What I don't understand is how the script should check if something is
>> the official tree, e.g. in the simple case of somebody having forked the
>> OpenWrt mirror on github, cloned it locally, added and pushed a few
>> commits and then made a build.
> 
> git config --get user.name
> git config --get user.email
> 
> if they are set to the name of the official buildbot, no nothing. If they are 
> set to anything else, take some data (initials or something) and make that 
> part 
> of the version number.
> 
> It's not checking if it's an unmodified tree, just if it's being built on the 
> OpenWRT infrastructure.
> 
> If someone is building an unmodified tree, the git hash will work for 
> identifying what tree it is. And someone else posted a process for trackign 
> divergence from the upstream tree if they are modifying it first.
I still have doubts about that process. And why should the version info
be treated differently if things are built on the official infrastructure?

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[David Lang]

On Mon, 12 Oct 2015, Felix Fietkau wrote:


On 2015-10-12 22:28, David Lang wrote:

On Mon, 12 Oct 2015, Felix Fietkau wrote:


On 2015-10-12 22:02, Javier Domingo Cansino wrote:

Would it be possible to track the revision number in an automated
way even in a git repo?  So store the r number, and automatically
increment on commits.  Not sure if that's an option, but it seems
like it might address the problem.


In git you wouldn't need such thing, the way would be to track the
forking point comparing the user history with the upstream master
history, and describing the path. The oneliner I sent before (which I
now realize I split in two), did (or will do) the following.

1) Go back in history and find the latest tag, save it as $tag

We currently don't have any tags for mainline trunk, since we usually
don't directly release from it.


I would put a nightly tag in place (tags are pretty cheap)

Sounds nasty.


why?


2) Find the forking point between upstream and user branch if any, save
current commit if not such fork exists as $parent.

How does the script know which one is the right upstream?


git knows where it was cloned from, so it knows what upstream is for any local
branch.

Yeah, but where it was cloned from might not be OpenWrt upstream.


true, but if you work from tags, it can just look for the difference since the 
most recent tag (or even the most recent tag that matches a specific pattern)



3) count how many commits are from $tag commit to $parent commit, save
it as $parent_n
3) If fork exists, count how many commits from $parent to HEAD, save it
as $commit_n
4) If tree is dirty, save $dirty='-dirty', else $dirty=''

compose the build version info as the following:

$tag-$parent_n-$parent-$commit_n-$parent$dirty

If I see such a string, how do I look up the last OpenWrt commit from
that? With the revision number, I simply start git log and search for
@


if you make a nightly/weekly tag it becomes trivial to lookup. you can also use
the first 6/8 characters of the git commit and look that up (or git log
12345678..HEAD to show everything between that commit and the current head)

The lookup only works if the tags were carried over as well. Not sure if
that's the case when somebody does a github fork of the mirror repo.


tags are carried over in just about all cases (github does so by default, 
while there are manual ways to not get them, that will cause people other 
problems), commit hashes are an intrinsic part of the repo.


David Lang
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Javier Domingo Cansino]

>
> I have yet to see an approach for this that actually works and deals
>
with all the common scenarios where people fork OpenWrt and make a few
> local changes.
>
I see I have not enough information on what are the common use cases. For
me, these are the following:
 - User clones openwrt master, makes some work on it and has an issue.
 - Company uses openwrt release as base.
 - Company uses openwrt random commit as base.

Supposing these are the use cases you want to support, please expand if
needed, I can develop a mini script that would check upstream for the
latest commit, and give you a version information string like the one I
showed. Please tell if you want any more information there.


> And I've actually given much thought to the cost and benefits of our
> current workflow vs doing it in git. My main problem is not with the
> part of submodules vs external stuff, it's with the workflow of
> maintaining our kernel changes in a git repo directly instead of having
> patches.


I have to agree that I find pretty clean the current method, although it
can be difficult to with it develop, I understand makes it easier to
maintain it.

However, I am not willing to discuss whether to change the current kernel
patch system to a git branch releases based one, because I haven't used it
enough.

Typo fixes are the least relevant changes. Making it easier to do that
>
kind of change is not a priority, especially if other things are made worse.
>
Let's hope we don't make things worse but different, which might seem worse
at the beginning in comparison to the workflow you have been long
accustomed to.


> We have patchwork for tracking submissions, and people get notified when
> their patches are accepted or rejected.

The interface is not as clean as the github/gitlab one. And people is more
relaxed with responsive and intuitive interfaces.

Less work for the submitter, but more work for testing before
> commit/push => not a good trade-off on my opinion.
>
Let's not make it worse for the tester/committer.

I personally find the pull request workflow very cumbersome. With what
> we have now, I can just 'git am' the ones that look sane, do a final
> test build + review, and then 'git svn dcommit' the result.
> With pull requests, I'd have to take those in a private branch or
> something, then run git pull on my local machine before being able to
> test stuff. Also, this will spam the repo history with annoying merge
> commits unless I do a rebase myself.
>

I can prepare a tool that just cherry-picks changes from the PR so that you
can test them easily. You can also ask the contributor to change the shape
of the commits, and the tool would then replicate again the changes on top
of HEAD.

For the core repo, I'd rather have higher patch quality instead of more
> contributions.
>
I can't make quality better just with git, but we could introduce travis-ci
for basic testing of PRs, to report basic failures that might have slipped
off the contributor (this would come later).

This way my patch from the other day wouldn't have needed to be reviewed
until check-patch had run on it.


> The main bottleneck in core development is not users submitting patches,
> it's patch review and especially testing. In my opinion your suggestions
> make that part harder.
>
With the tools I can create I hope it will be easier to do this, also
because issues and PRs have unique IDs, we could refer to them and make
testing much more controlled. For example, using travis-ci for PRs.


> The work done by core devs is the main bottleneck, so I care about that
> a lot more than making the life of drive-by contributors easier.
>

I agree that the bottlenecks should be reduced. I think I have spotted some
ways we could make a little better these.

I think gitlab/github is a really good choice because if everything in the
development (the repo and the PRs) is done using the same tool, we can have
nice features to help you reduce the bottleneck.

I would love to sort of arrange a trial period to have experience on how
you feel the tools, what command line helpers you would need and overall
feedback on the process to make the tools more adapted to your need.

I believe we should for now concentrate on steps 1-2), git based main repo,
hosted in a service such as gitlab/github.

I can prepare a sample repo where you could interact with a contributor,
not by means of everyone sending stuff to core through there but just a few
during some days.

If you want, before doing this, I can develop the two command lines I spoke
about, so that you can generate the build version info and the
cherrypick/patch checkout tool.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Javier Domingo Cansino]

>
> Would it be possible to track the revision number in an automated way even
> in a git repo?  So store the r number, and automatically increment on
> commits.  Not sure if that's an option, but it seems like it might address
> the problem.
>

In git you wouldn't need such thing, the way would be to track the forking
point comparing the user history with the upstream master history, and
describing the path. The oneliner I sent before (which I now realize I
split in two), did (or will do) the following.

1) Go back in history and find the latest tag, save it as $tag
2) Find the forking point between upstream and user branch if any, save
current commit if not such fork exists as $parent.
3) count how many commits are from $tag commit to $parent commit, save it
as $parent_n
3) If fork exists, count how many commits from $parent to HEAD, save it as
$commit_n
4) If tree is dirty, save $dirty='-dirty', else $dirty=''

compose the build version info as the following:

$tag-$parent_n-$parent-$commit_n-$parent$dirty
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[David Lang]

On Mon, 12 Oct 2015, Jonathan Bennett wrote:


His point is that users don't ever do an SVN checkout. Because the r number
is baked into the image, it's a really easy and obvious way for an end user
to report the revision in a bug report.  I can see the advantage in this.
If we are to move to git, we would want some way to preserve this feature,
that is a super easy way for a user to report the revision.  We could bake
the short hash into the image, but this would not be useful if any commits
were added locally, whereas the r number would still show some useful
information.

Would it be possible to track the revision number in an automated way even
in a git repo?  So store the r number, and automatically increment on
commits.  Not sure if that's an option, but it seems like it might address
the problem.


It sounds like what you really want to do is to have the nightly build embed the 
date of the build in the image and have people report that.


If someone checks out the source and compiles a new copy (with local 
modifications), reporting a SVN version is as misleading as a git hash.


I know that various projects I work with have the build process embed the date 
in the package versions, so it should be straightforward to put it into some 
file in the resulting firmware image. Such a process can also check if it's 
running on the 'official' tree or in someone else's repo (check repo 
owner/e-mail) and add the initials of the person compiling it.


then something like the -dirty info that was mentioned earlier could also be 
embedded to show the development since it branched from the main OpenWRT repo.


David Lang
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Felix Fietkau]

On 2015-10-12 16:47, Javier Domingo Cansino wrote:
> Many people follow current trunk, and we need to have precise version
> information for that when they report a bug. We don't want to regularly
> tag stuff just to keep reported version information up to date.
> 
> 
> This is already done using --dirty. I generates all the information you
> need.
> 
> You can generate whatever information you wish. For example, if total
> trazability of the user is what you want:
> base=$(git merge-base github/master HEAD)
> echo $(git describe --tags $base)-$(git log --oneline $base..HEAD | wc
> -l)-$(git log --oneline | head -n1 | cut -c-8)
> 
> That would give you v1.0-rc1-5-gd66a89f-4-9f0e84a -> base tag, commit
> count from the base to the forking commit, hash of that commit, number
> of commits since fork, hash of the commit.
> 
> You could even add a -dirty if you wish to to tell you if that 4th
> commit after the fork has been compiled cleanly or not.
But that assumes a specific remote in the git config pointing towards
the main openwrt repo. If somebody forked the OpenWrt mirror on github,
the appropriate remote will not be present automatically, and the above
approach will fail.
What we have now is robust against that sort of thing.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Felix Fietkau]

On 2015-10-12 22:02, Javier Domingo Cansino wrote:
> Would it be possible to track the revision number in an automated
> way even in a git repo?  So store the r number, and automatically
> increment on commits.  Not sure if that's an option, but it seems
> like it might address the problem.
> 
> 
> In git you wouldn't need such thing, the way would be to track the
> forking point comparing the user history with the upstream master
> history, and describing the path. The oneliner I sent before (which I
> now realize I split in two), did (or will do) the following.
> 
> 1) Go back in history and find the latest tag, save it as $tag
We currently don't have any tags for mainline trunk, since we usually
don't directly release from it.

> 2) Find the forking point between upstream and user branch if any, save
> current commit if not such fork exists as $parent.
How does the script know which one is the right upstream?

> 3) count how many commits are from $tag commit to $parent commit, save
> it as $parent_n
> 3) If fork exists, count how many commits from $parent to HEAD, save it
> as $commit_n
> 4) If tree is dirty, save $dirty='-dirty', else $dirty=''
> 
> compose the build version info as the following:
> 
> $tag-$parent_n-$parent-$commit_n-$parent$dirty
If I see such a string, how do I look up the last OpenWrt commit from
that? With the revision number, I simply start git log and search for
@

- felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Javier Domingo Cansino]

So the questions to be answered to provide a build version string are.

- Are you planning to use git tags for something? What are you needs for it?
- What information would you like to have from the build?

Examples: last upstream common commit, current commit, dirtiness,
officialness.

Also, I am looking that you are speaking about nightly tags, I wouldn't
recommend at all having those kind of tags. Nightly tags for build version
string would loose all the meaning, if you intend the build version to be
universal. It all depends on your answers to those two questions
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2 4/4] kernel: add usb-mass-storage-gadget driver package

[Pushpal Sidhu]

This is another useful gadget driver that can allow an OTG port to act as a
mass storage device.

Signed-off-by: Pushpal Sidhu 
---
Changes in v2:
 * None

 package/kernel/linux/modules/usb.mk | 17 +
 1 file changed, 17 insertions(+)

diff --git a/package/kernel/linux/modules/usb.mk 
b/package/kernel/linux/modules/usb.mk
index 986f53f..487a17d 100644
--- a/package/kernel/linux/modules/usb.mk
+++ b/package/kernel/linux/modules/usb.mk
@@ -279,6 +279,23 @@ endef
 
 $(eval $(call KernelPackage,usb-serial-gadget))
 
+define KernelPackage/usb-mass-storage-gadget
+  TITLE:=USB Mass Storage support
+  KCONFIG:=CONFIG_USB_MASS_STORAGE
+  DEPENDS:=+kmod-usb-gadget +kmod-usb-lib-composite
+  FILES:= \
+   $(LINUX_DIR)/drivers/usb/gadget/function/usb_f_mass_storage.ko \
+   $(LINUX_DIR)/drivers/usb/gadget/legacy/g_mass_storage.ko
+  AUTOLOAD:=$(call AutoLoad,52,usb_f_mass_storage g_mass_storage)
+  $(call AddDepends/usb)
+endef
+
+define KernelPackage/usb-mass-storage-gadget/description
+  Kernel support for USB Gadget Mass Storage
+endef
+
+$(eval $(call KernelPackage,usb-mass-storage-gadget))
+
 
 define KernelPackage/usb-uhci
   TITLE:=Support for UHCI controllers
-- 
2.6.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2 3/4] kernel: add mvsw61xx module package

[Pushpal Sidhu]

Adds the package to select the mvsw61xx module present in the 3.18/4.0/4.1
kernels.

Signed-off-by: Pushpal Sidhu 
---
Changes v2:
 * None

 package/kernel/linux/modules/netdevices.mk | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/package/kernel/linux/modules/netdevices.mk 
b/package/kernel/linux/modules/netdevices.mk
index 9efac98..ef3cf85 100644
--- a/package/kernel/linux/modules/netdevices.mk
+++ b/package/kernel/linux/modules/netdevices.mk
@@ -180,6 +180,20 @@ endef
 
 $(eval $(call KernelPackage,swconfig))
 
+define KernelPackage/switch-mvsw61xx
+  SUBMENU:=$(NETWORK_DEVICES_MENU)
+  TITLE:=Marvell 88E61xx switch support
+  DEPENDS:=+kmod-swconfig
+  KCONFIG:=CONFIG_MVSW61XX_PHY
+  FILES:=$(LINUX_DIR)/drivers/net/phy/mvsw61xx.ko
+  AUTOLOAD:=$(call AutoLoad,42,mvsw61xx)
+endef
+
+define KernelPackage/switch-mvsw61xx/description
+ Marvell 88E61xx switch support
+endef
+
+$(eval $(call KernelPackage,switch-mvsw61xx))
 
 define KernelPackage/switch-ip17xx
   SUBMENU:=$(NETWORK_DEVICES_MENU)
-- 
2.6.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] proto 'none' overwriting tun interfaces

[Alexander Couzens]

hi Adam,

I can confirm this bug.
You may open a ticket on dev.openwrt.org

best,
lynxis


pgpLsloA4JMqy.pgp
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2 2/4] kernel: add ath3k module package

[Pushpal Sidhu]

Adds a package for the ath3k kernel module, present in 3.18/4.0/4.1 kernels

Signed-off-by: Pushpal Sidhu 
---
Changes in v2:
 * ath3k now depends on ar3k-firmware

 package/kernel/linux/modules/other.mk | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/package/kernel/linux/modules/other.mk 
b/package/kernel/linux/modules/other.mk
index d438fbe..9ff291d 100644
--- a/package/kernel/linux/modules/other.mk
+++ b/package/kernel/linux/modules/other.mk
@@ -78,6 +78,25 @@ endef
 
 $(eval $(call KernelPackage,bluetooth))
 
+define KernelPackage/ath3k
+  SUBMENU:=$(OTHER_MENU)
+  TITLE:=ATH3K Kernel Module support
+  DEPENDS:=+kmod-bluetooth +ar3k-firmware
+  KCONFIG:= \
+   CONFIG_BT_ATH3K \
+   CONFIG_BT_HCIUART_ATH3K
+  $(call AddDepends/bluetooth)
+  FILES:= \
+   $(LINUX_DIR)/drivers/bluetooth/ath3k.ko
+  AUTOLOAD:=$(call AutoProbe,ath3k)
+endef
+
+define KernelPackage/ath3k/description
+ Kernel support for ATH3K Module
+endef
+
+$(eval $(call KernelPackage,ath3k))
+
 
 define KernelPackage/bluetooth_6lowpan
   SUBMENU:=$(OTHER_MENU)
-- 
2.6.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2 1/4] firmware: linux-firmware: Add ibt-firmware and ar3k-firmware packages

[Pushpal Sidhu]

Some bluetooth devices require firmware. Add intel bluetooth and ar3k for now.

Signed-off-by: Pushpal Sidhu 
---
Changes v2:
 * None

 package/firmware/linux-firmware/Makefile | 40 
 1 file changed, 40 insertions(+)

diff --git a/package/firmware/linux-firmware/Makefile 
b/package/firmware/linux-firmware/Makefile
index 015aff7..fe682ab 100644
--- a/package/firmware/linux-firmware/Makefile
+++ b/package/firmware/linux-firmware/Makefile
@@ -61,3 +61,43 @@ define Package/r8188eu-firmware/install
 endef
 
 $(eval $(call BuildPackage,r8188eu-firmware))
+
+define Package/ibt-firmware
+  SECTION:=firmware
+  CATEGORY:=Firmware
+  URL:=http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git
+  TITLE:=Intel bluetooth firmware
+endef
+
+define Build/Compile
+
+endef
+
+define Package/ibt-firmware/install
+   $(INSTALL_DIR) $(1)/lib/firmware/intel
+   $(CP) \
+   $(PKG_BUILD_DIR)/intel/*.bseq \
+   $(1)/lib/firmware/intel
+endef
+
+$(eval $(call BuildPackage,ibt-firmware))
+
+define Package/ar3k-firmware
+  SECTION:=firmware
+  CATEGORY:=Firmware
+  URL:=http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git
+  TITLE:=ath3k firmware
+endef
+
+define Build/Compile
+
+endef
+
+define Package/ar3k-firmware/install
+   $(INSTALL_DIR) $(1)/lib/firmware/ar3k
+   $(CP) \
+   $(PKG_BUILD_DIR)/ar3k/*.dfu \
+   $(1)/lib/firmware/ar3k
+endef
+
+$(eval $(call BuildPackage,ar3k-firmware))
-- 
2.6.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] proto 'none' overwriting tun interfaces

[openwrt]

Hi all,

I've been compiling OpenWRT builds for my home router (Netgear WNDR3800 and now 
a WD MyNet N750) for a number of years. I just recently encountered a problem 
with the OpenVPN tun interfaces are showing up without IP addresses after a 
reboot. I have the following in my /etc/config/network:

config interface 'vpn_udp'
option ifname 'tun0'
option proto 'none'

config interface 'vpn_tcp'
option ifname 'tun1'
option proto 'none'

Then, my /etc/openvpn/udp.ovpn and /etc/openvpn/tcp.ovpn reference "dev tun0" 
and "dev tun1", respectively. I do it this way so I can link "vpn_udp" and 
"vpn_tcp" into /etc/config/firewall, and other places, like I would any other 
network interface. What I expect is that the tun0 and tun1 interfaces look like 
this after a reboot:

tun0  Link encap:UNSPEC  HWaddr 
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
  inet addr:10.28.10.1  P-t-P:10.28.10.1  Mask:255.255.255.0
  UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:100
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

tun1  Link encap:UNSPEC  HWaddr 
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
  inet addr:10.28.11.1  P-t-P:10.28.11.1  Mask:255.255.255.0
  UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
  RX packets:253526 errors:0 dropped:0 overruns:0 frame:0
  TX packets:356519 errors:0 dropped:834 overruns:0 carrier:0
  collisions:0 txqueuelen:100
  RX bytes:16948392 (16.1 MiB)  TX bytes:451900041 (430.9 MiB)

However the interfaces look like this instead:

tun0  Link encap:UNSPEC  HWaddr 
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
  UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:100
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

tun1  Link encap:UNSPEC  HWaddr 
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
  UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:100
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Note, the IP addresses are missing. Hence, even though the openvpn processes 
are running, traffic won't flow because the tun interfaces have had their IP 
addresses wiped. I have to manually run "/etc/init.d/openvpn restart" to get 
everything back to normal after reboot.

Am I missing something? This is happening on freshly compiled images from both 
the latest trunk and latest 15.05.

Any thoughts and/or suggestions would be most appreciated.

Thanks,
Adam
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] SVN to GIT transition

[Felix Fietkau]

On 2015-10-12 23:18, Bruno Randolf wrote:
> On 10/12/2015 03:22 PM, Felix Fietkau wrote:
 When using tags as a starting point (via git describe), somebody has to
 create those tags, which is cumbersome (and would mean adding lots of
 useless ones).
>>>
>>> What's cumbersome? And why would you have to create useless tags?
>>>
>> Many people follow current trunk, and we need to have precise version
>> information for that when they report a bug. We don't want to regularly
>> tag stuff just to keep reported version information up to date.
> 
> You don't need to. Try this in your OpenWRT trunk git repo:
> 
> git tag -a r 753606a51c979440e10771f0d11494b7b7c1eac2
> 
> (Tagging the very first commit with "r".)
> 
> Now do:
> 
> git describe
> 
> r-35387-g83c5a41
> 
> If you prefer, cut the last part and get "r-35387".
> 
> Looks familiar? Now you even have real linear numbering in each branch,
> without the gaps you get when committing to different branches in SVN +
> the unique hash. Need to look up the commit? Use the hash (g83c5a41).
> 
> Of course "r" is just an example to show the familiarity with SVN
> revisions, you could choose whatever seems fit, for example at this
> moment it would make sense to tag the moment when 15.05 was branched off
> from trunk as "dd", then you'd get "dd-number-hash" in trunk and
> "15.05-66-g66620f5" in the 15.05 branch (you actually do, just need to
> use "git describe --tags" because the tag was not created with -a).
That looks quite interesting. The issue I see with that is if somebody
adds a local commit on top and builds the tree, the number behind 'r' is
misleading and the hash is useless.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] x86: add EPIA subtarget

[Daniel Golle]

x86: add VIA EPIA subtarget

Signed-off-by: Daniel Golle 
---
 include/target.mk|   1 +
 target/linux/x86/Makefile|   2 +-
 target/linux/x86/epia/config-default | 213 +++
 target/linux/x86/epia/target.mk  |  10 ++
 4 files changed, 225 insertions(+), 1 deletion(-)
 create mode 100644 target/linux/x86/epia/config-default
 create mode 100644 target/linux/x86/epia/target.mk

diff --git a/include/target.mk b/include/target.mk
index 3e7f17d..9481e6a 100644
--- a/include/target.mk
+++ b/include/target.mk
@@ -224,6 +224,7 @@ ifeq ($(DUMP),1)
 CPU_CFLAGS_i486 = -march=i486
 CPU_CFLAGS_pentium4 = -march=pentium4
 CPU_CFLAGS_geode = -march=geode -mmmx -m3dnow
+CPU_CFLAGS_c3-2 = -march=c3-2
   endif
   ifneq ($(findstring arm,$(ARCH)),)
 CPU_TYPE ?= xscale
diff --git a/target/linux/x86/Makefile b/target/linux/x86/Makefile
index ba733c0..4f5a60a 100644
--- a/target/linux/x86/Makefile
+++ b/target/linux/x86/Makefile
@@ -10,7 +10,7 @@ ARCH:=i386
 BOARD:=x86
 BOARDNAME:=x86
 FEATURES:=squashfs ext4 vdi vmdk pcmcia targz
-SUBTARGETS=generic xen_domu ep80579 geode kvm_guest rdc 64
+SUBTARGETS=generic xen_domu ep80579 epia geode kvm_guest rdc 64
 MAINTAINER:=Felix Fietkau 
 
 KERNEL_PATCHVER:=3.18
diff --git a/target/linux/x86/epia/config-default 
b/target/linux/x86/epia/config-default
new file mode 100644
index 000..a9bcd2a
--- /dev/null
+++ b/target/linux/x86/epia/config-default
@@ -0,0 +1,213 @@
+# CONFIG_3C515 is not set
+CONFIG_ACPI=y
+CONFIG_ACPI_AC=y
+CONFIG_ACPI_BATTERY=y
+CONFIG_ACPI_BUTTON=y
+# CONFIG_ACPI_CMPC is not set
+# CONFIG_ACPI_CONTAINER is not set
+# CONFIG_ACPI_CUSTOM_DSDT is not set
+# CONFIG_ACPI_DEBUG is not set
+# CONFIG_ACPI_DOCK is not set
+# CONFIG_ACPI_EC_DEBUGFS is not set
+# CONFIG_ACPI_FAN is not set
+# CONFIG_ACPI_I2C_OPREGION is not set
+# CONFIG_ACPI_INITRD_TABLE_OVERRIDE is not set
+CONFIG_ACPI_LEGACY_TABLES_LOOKUP=y
+# CONFIG_ACPI_PCI_SLOT is not set
+CONFIG_ACPI_PROCESSOR=y
+# CONFIG_ACPI_PROCESSOR_AGGREGATOR is not set
+# CONFIG_ACPI_PROCFS_POWER is not set
+# CONFIG_ACPI_REDUCED_HARDWARE_ONLY is not set
+# CONFIG_ACPI_SBS is not set
+CONFIG_ACPI_THERMAL=y
+CONFIG_ACPI_VIDEO=y
+# CONFIG_ACPI_WMI is not set
+CONFIG_AGP=y
+# CONFIG_AGP_ALI is not set
+# CONFIG_AGP_AMD is not set
+# CONFIG_AGP_AMD64 is not set
+# CONFIG_AGP_ATI is not set
+# CONFIG_AGP_EFFICEON is not set
+# CONFIG_AGP_INTEL is not set
+# CONFIG_AGP_NVIDIA is not set
+# CONFIG_AGP_SIS is not set
+# CONFIG_AGP_SWORKS is not set
+CONFIG_AGP_VIA=y
+# CONFIG_APPLE_GMUX is not set
+CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC=y
+# CONFIG_ASUS_LAPTOP is not set
+# CONFIG_BACKLIGHT_ADP8860 is not set
+# CONFIG_BACKLIGHT_ADP8870 is not set
+# CONFIG_BACKLIGHT_APPLE is not set
+CONFIG_BACKLIGHT_CLASS_DEVICE=y
+CONFIG_BACKLIGHT_GENERIC=y
+CONFIG_BACKLIGHT_LCD_SUPPORT=y
+# CONFIG_BACKLIGHT_SAHARA is not set
+CONFIG_BLK_DEV_SR=y
+# CONFIG_BLK_DEV_SR_VENDOR is not set
+CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+CONFIG_CPU_IDLE_GOV_MENU=y
+# CONFIG_DELL_SMO8800 is not set
+CONFIG_DMA_SHARED_BUFFER=y
+CONFIG_DMI=y
+# CONFIG_DMIID is not set
+CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y
+# CONFIG_DMI_SYSFS is not set
+CONFIG_DRM=y
+# CONFIG_DRM_AST is not set
+CONFIG_DRM_BOCHS=y
+# CONFIG_DRM_CIRRUS_QEMU is not set
+# CONFIG_DRM_GMA500 is not set
+# CONFIG_DRM_I2C_CH7006 is not set
+# CONFIG_DRM_I2C_NXP_TDA998X is not set
+# CONFIG_DRM_I2C_SIL164 is not set
+# CONFIG_DRM_I810 is not set
+# CONFIG_DRM_I915 is not set
+# CONFIG_DRM_I915_FBDEV is not set
+# CONFIG_DRM_I915_KMS is not set
+# CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT is not set
+CONFIG_DRM_KMS_FB_HELPER=y
+CONFIG_DRM_KMS_HELPER=y
+# CONFIG_DRM_LOAD_EDID_FIRMWARE is not set
+# CONFIG_DRM_MGA is not set
+# CONFIG_DRM_MGAG200 is not set
+# CONFIG_DRM_NOUVEAU is not set
+# CONFIG_DRM_PTN3460 is not set
+# CONFIG_DRM_QXL is not set
+# CONFIG_DRM_R128 is not set
+# CONFIG_DRM_RADEON is not set
+# CONFIG_DRM_SAVAGE is not set
+# CONFIG_DRM_SIS is not set
+# CONFIG_DRM_TDFX is not set
+# CONFIG_DRM_TTM is not set
+# CONFIG_DRM_UDL is not set
+CONFIG_DRM_VIA=y
+# CONFIG_DRM_VMWGFX is not set
+# CONFIG_EFI is not set
+# CONFIG_EISA is not set
+# CONFIG_EL3 is not set
+CONFIG_FB=y
+CONFIG_FB_CFB_COPYAREA=y
+CONFIG_FB_CFB_FILLRECT=y
+CONFIG_FB_CFB_IMAGEBLIT=y
+CONFIG_FB_CMDLINE=y
+# CONFIG_FB_I810 is not set
+CONFIG_FB_SYS_COPYAREA=y
+CONFIG_FB_SYS_FILLRECT=y
+CONFIG_FB_SYS_IMAGEBLIT=y
+# CONFIG_FB_VESA is not set
+CONFIG_FB_VIA=y
+# CONFIG_FB_VIA_DIRECT_PROCFS is not set
+CONFIG_FB_VIA_X_COMPATIBILITY=y
+# CONFIG_FONTS is not set
+CONFIG_FONT_8x16=y
+CONFIG_FONT_8x8=y
+CONFIG_FONT_SUPPORT=y
+CONFIG_FRAMEBUFFER_CONSOLE=y
+CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
+# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
+# CONFIG_FUJITSU_LAPTOP is not set
+# CONFIG_GEOS is not set
+CONFIG_GPIO_GENERIC_PLATFORM=y
+# CONFIG_GPIO_F7188X is not set
+CONFIG_GPIO_VX855=y
+# CONFIG_GPIO_LYNXPOINT 

[OpenWrt-Devel] [PATCH] kernel: add support for KERNEL_CGROUP_PIDS

[Daniel Golle]

Signed-off-by: Daniel Golle 
---
 config/Config-kernel.in | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/config/Config-kernel.in b/config/Config-kernel.in
index 2572bf4..38d953c 100644
--- a/config/Config-kernel.in
+++ b/config/Config-kernel.in
@@ -265,6 +265,13 @@ if KERNEL_CGROUPS
  Provides a cgroup implementing whitelists for devices which
  a process in the cgroup can mknod or open.
 
+   config KERNEL_CGROUP_PIDS
+   bool "PIDs cgroup subsystem"
+   default y
+   help
+ Provides enforcement of process number limits in the scope of 
a
+ cgroup.
+
config KERNEL_CPUSETS
bool "Cpuset support"
default n
-- 
2.6.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] kernel: add some missing symbols for 4.3

[Daniel Golle]

Signed-off-by: Daniel Golle 
---
 target/linux/generic/config-4.3 | 9 +
 1 file changed, 9 insertions(+)

diff --git a/target/linux/generic/config-4.3 b/target/linux/generic/config-4.3
index 012c57e..b3d47b7 100644
--- a/target/linux/generic/config-4.3
+++ b/target/linux/generic/config-4.3
@@ -96,6 +96,7 @@ CONFIG_AEABI=y
 # CONFIG_AFS_FS is not set
 # CONFIG_AF_RXRPC is not set
 # CONFIG_AGP is not set
+# CONFIG_AHCI_CEVA is not set
 # CONFIG_AHCI_MVEBU is not set
 CONFIG_AIO=y
 # CONFIG_AIRO is not set
@@ -684,6 +685,7 @@ CONFIG_CMDLINE=""
 # CONFIG_CODE_PATCHING_SELFTEST is not set
 # CONFIG_COMEDI is not set
 # CONFIG_COMMON_CLK_CDCE706 is not set
+# CONFIG_COMMON_CLK_CDCE925 is not set
 # CONFIG_COMMON_CLK_DEBUG is not set
 # CONFIG_COMMON_CLK_IPROC is not set
 # CONFIG_COMMON_CLK_PWM is not set
@@ -788,6 +790,7 @@ CONFIG_CRYPTO_BLKCIPHER2=y
 # CONFIG_CRYPTO_HASH is not set
 # CONFIG_CRYPTO_HMAC is not set
 # CONFIG_CRYPTO_HW is not set
+# CONFIG_CRYPTO_JITTERENTROPY is not set
 # CONFIG_CRYPTO_KHAZAD is not set
 # CONFIG_CRYPTO_LRW is not set
 # CONFIG_CRYPTO_LZ4 is not set
@@ -1442,6 +1445,7 @@ CONFIG_HZ_100=y
 # CONFIG_I2C_DIOLAN_U2C is not set
 # CONFIG_I2C_EG20T is not set
 # CONFIG_I2C_ELEKTOR is not set
+# CONFIG_I2C_EMEV2 is not set
 # CONFIG_I2C_GPIO is not set
 # CONFIG_I2C_HELPER_AUTO is not set
 # CONFIG_I2C_HID is not set
@@ -1508,6 +1512,7 @@ CONFIG_HZ_100=y
 # CONFIG_IDE_PROC_FS is not set
 # CONFIG_IDE_TASK_IOCTL is not set
 # CONFIG_IDLE_PAGE_TRACKING is not set
+# CONFIG_IDMA64 is not set
 # CONFIG_IEEE802154 is not set
 # CONFIG_IEEE802154_ATUSB is not set
 # CONFIG_IFB is not set
@@ -2098,6 +2103,7 @@ CONFIG_MESSAGE_LOGLEVEL_DEFAULT=4
 # CONFIG_MFD_DA9052_I2C is not set
 # CONFIG_MFD_DA9052_SPI is not set
 # CONFIG_MFD_DA9055 is not set
+# CONFIG_MFD_DA9062 is not set
 # CONFIG_MFD_DA9063 is not set
 # CONFIG_MFD_DA9150 is not set
 # CONFIG_MFD_DLN2 is not set
@@ -3322,8 +3328,10 @@ CONFIG_RTC_DRV_CMOS=y
 # CONFIG_RTC_DRV_V3020 is not set
 # CONFIG_RTC_DRV_X1205 is not set
 # CONFIG_RTC_DRV_XGENE is not set
+# CONFIG_RTC_DRV_ZYNQMP is not set
 CONFIG_RTC_HCTOSYS=y
 CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
+CONFIG_RTC_SYSTOHC_DEVICE="rtc0"
 CONFIG_RTC_INTF_DEV=y
 # CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
 CONFIG_RTC_INTF_PROC=y
@@ -4077,6 +4085,7 @@ CONFIG_STAGING=y
 # CONFIG_STAGING_MEDIA is not set
 CONFIG_STANDALONE=y
 CONFIG_STDBINUTILS=y
+# CONFIG_STATIC_KEYS_SELFTEST is not set
 # CONFIG_STE10XP is not set
 # CONFIG_STE_MODEM_RPROC is not set
 # CONFIG_STK3310 is not set
-- 
2.6.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] modules: enable crypto hardware modules

[Daniel Golle]

set CONFIG_CRYPTO_HW=y to enable build of crypto-hw modules.

Signed-off-by: Daniel Golle 
---
 package/kernel/linux/modules/crypto.mk | 6 ++
 1 file changed, 6 insertions(+), 0 deletion(-)

diff --git a/package/kernel/linux/modules/crypto.mk 
b/package/kernel/linux/modules/crypto.mk
index c790b58..82d2ca8 100644
--- a/package/kernel/linux/modules/crypto.mk
+++ b/package/kernel/linux/modules/crypto.mk
@@ -140,6 +139,7 @@ define KernelPackage/crypto-hw-talitos
   TITLE:=Freescale integrated security engine (SEC) driver
   DEPENDS:=+kmod-crypto-manager +kmod-crypto-hash +kmod-random-core 
+kmod-crypto-authenc
   KCONFIG:= \
+   CONFIG_CRYPTO_HW=y \
CONFIG_CRYPTO_DEV_TALITOS
   FILES:= \
$(LINUX_DIR)/drivers/crypto/talitos.ko
@@ -154,6 +154,7 @@ define KernelPackage/crypto-hw-padlock
   TITLE:=VIA PadLock ACE with AES/SHA hw crypto module
   DEPENDS:=+kmod-crypto-manager
   KCONFIG:= \
+   CONFIG_CRYPTO_HW=y \
CONFIG_CRYPTO_DEV_PADLOCK \
CONFIG_CRYPTO_DEV_PADLOCK_AES \
CONFIG_CRYPTO_DEV_PADLOCK_SHA
@@ -171,6 +172,7 @@ define KernelPackage/crypto-hw-geode
   TITLE:=AMD Geode hardware crypto module
   DEPENDS:=+kmod-crypto-manager
   KCONFIG:= \
+   CONFIG_CRYPTO_HW=y \
CONFIG_CRYPTO_DEV_GEODE
   FILES:=$(LINUX_DIR)/drivers/crypto/geode-aes.ko
   AUTOLOAD:=$(call AutoLoad,09,geode-aes)
@@ -184,6 +186,7 @@ define KernelPackage/crypto-hw-hifn-795x
   TITLE:=HIFN 795x crypto accelerator
   DEPENDS:=+kmod-random-core +kmod-crypto-manager
   KCONFIG:= \
+   CONFIG_CRYPTO_HW=y \
CONFIG_CRYPTO_DEV_HIFN_795X \
CONFIG_CRYPTO_DEV_HIFN_795X_RNG=y
   FILES:=$(LINUX_DIR)/drivers/crypto/hifn_795x.ko
@@ -198,6 +201,7 @@ define KernelPackage/crypto-hw-ppc4xx
   TITLE:=AMCC PPC4xx hardware crypto module
   DEPENDS:=@TARGET_ppc40x||TARGET_ppc44x
   KCONFIG:= \
+   CONFIG_CRYPTO_HW=y \
CONFIG_CRYPTO_DEV_PPC4XX
   FILES:=$(LINUX_DIR)/drivers/crypto/amcc/crypto4xx.ko
   AUTOLOAD:=$(call AutoLoad,90,crypto4xx)
@@ -215,6 +219,7 @@ define KernelPackage/crypto-hw-omap
   TITLE:=TI OMAP hardware crypto modules
   DEPENDS:=@TARGET_omap
   KCONFIG:= \
+   CONFIG_CRYPTO_HW=y \
CONFIG_CRYPTO_DEV_OMAP_AES \
CONFIG_CRYPTO_DEV_OMAP_DES \
CONFIG_CRYPTO_DEV_OMAP_SHAM
-- 
2.6.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 5/5] oxnas: move gmac soc glue from mach to stmmac driver

[Daniel Golle]

Still a lot of kernel-version ifdef'ery, but imho that's easy to remove
once obsoleted and avoids duplicate code in the meantime.

Signed-off-by: Daniel Golle 
---
 .../oxnas/files/arch/arm/mach-oxnas/mach-ox820.c   | 101 
 .../net/ethernet/stmicro/stmmac/dwmac-oxnas.c  | 172 +
 .../linux/oxnas/patches-4.1/700-oxnas-dwmac.patch  |  25 +++
 3 files changed, 197 insertions(+), 101 deletions(-)
 create mode 100644 
target/linux/oxnas/files/drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
 create mode 100644 target/linux/oxnas/patches-4.1/700-oxnas-dwmac.patch

diff --git a/target/linux/oxnas/files/arch/arm/mach-oxnas/mach-ox820.c 
b/target/linux/oxnas/files/arch/arm/mach-oxnas/mach-ox820.c
index 4b247b6..718bad7 100644
--- a/target/linux/oxnas/files/arch/arm/mach-oxnas/mach-ox820.c
+++ b/target/linux/oxnas/files/arch/arm/mach-oxnas/mach-ox820.c
@@ -5,7 +5,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -57,102 +56,6 @@ void __init ox820_map_common_io(void)
iotable_init(ox820_io_desc, ARRAY_SIZE(ox820_io_desc));
 }
 
-struct plat_gmac_data {
-   struct plat_stmmacenet_data stmmac;
-   struct clk *clk;
-};
-
-void *ox820_gmac_setup(struct platform_device *pdev)
-{
-   struct plat_gmac_data *pdata = pdev->dev.platform_data;
-
-   pdata->clk = clk_get(>dev, "gmac");
-   return (void *) pdata->clk;
-};
-
-int ox820_gmac_init(struct platform_device *pdev, void *priv)
-{
-   int ret;
-   unsigned value;
-
-   ret = device_reset(>dev);
-   if (ret)
-   return ret;
-
-   if (IS_ERR(priv))
-   return PTR_ERR(priv);
-   clk_prepare_enable(priv);
-
-   value = readl(SYS_CTRL_GMAC_CTRL);
-
-   /* Enable GMII_GTXCLK to follow GMII_REFCLK, required for gigabit PHY */
-   value |= BIT(SYS_CTRL_GMAC_CKEN_GTX);
-   /* Use simple mux for 25/125 Mhz clock switching */
-   value |= BIT(SYS_CTRL_GMAC_SIMPLE_MUX);
-   /* set auto switch tx clock source */
-   value |= BIT(SYS_CTRL_GMAC_AUTO_TX_SOURCE);
-   /* enable tx & rx vardelay */
-   value |= BIT(SYS_CTRL_GMAC_CKEN_TX_OUT);
-   value |= BIT(SYS_CTRL_GMAC_CKEN_TXN_OUT);
-   value |= BIT(SYS_CTRL_GMAC_CKEN_TX_IN);
-   value |= BIT(SYS_CTRL_GMAC_CKEN_RX_OUT);
-   value |= BIT(SYS_CTRL_GMAC_CKEN_RXN_OUT);
-   value |= BIT(SYS_CTRL_GMAC_CKEN_RX_IN);
-   writel(value, SYS_CTRL_GMAC_CTRL);
-
-   /* set tx & rx vardelay */
-   value = 0;
-   value |= SYS_CTRL_GMAC_TX_VARDELAY(4);
-   value |= SYS_CTRL_GMAC_TXN_VARDELAY(2);
-   value |= SYS_CTRL_GMAC_RX_VARDELAY(10);
-   value |= SYS_CTRL_GMAC_RXN_VARDELAY(8);
-   writel(value, SYS_CTRL_GMAC_DELAY_CTRL);
-
-   return 0;
-}
-
-void ox820_gmac_exit(struct platform_device *pdev, void *priv)
-{
-   struct reset_control *rstc;
-
-   clk_disable_unprepare(priv);
-   clk_put(priv);
-
-   rstc = reset_control_get(>dev, NULL);
-   if (!IS_ERR(rstc)) {
-   reset_control_assert(rstc);
-   reset_control_put(rstc);
-   }
-}
-
-static int __init ox820_ether_init(void)
-{
-   struct device_node *node;
-   struct platform_device *pdev;
-   struct plat_gmac_data *pdata;
-
-   node = of_find_compatible_node(NULL, NULL, "plxtech,nas782x-gmac");
-   if (!node)
-   return -ENOENT;
-
-   pdev = of_find_device_by_node(node);
-   of_node_put(node);
-
-   if (!pdev)
-   return -EINVAL;
-
-   pdata = kzalloc(sizeof(struct plat_gmac_data), GFP_KERNEL);
-   if (!pdata)
-   return -ENOMEM;
-
-   pdata->stmmac.setup = ox820_gmac_setup;
-   pdata->stmmac.init = ox820_gmac_init;
-   pdata->stmmac.exit = ox820_gmac_exit;
-   pdev->dev.platform_data = pdata;
-
-   return 0;
-}
-
 static void __init ox820_dt_init(void)
 {
int ret;
@@ -165,10 +68,6 @@ static void __init ox820_dt_init(void)
BUG();
}
 
-   ret = ox820_ether_init();
-
-   if (ret)
-   pr_info("ox820_ether_init failed: %d\n", ret);
 }
 
 static void __init ox820_timer_init(void)
diff --git 
a/target/linux/oxnas/files/drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c 
b/target/linux/oxnas/files/drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
new file mode 100644
index 000..07f9f44
--- /dev/null
+++ b/target/linux/oxnas/files/drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
@@ -0,0 +1,172 @@
+/* Copyright OpenWrt.org (C) 2015.
+ * Copyright Altera Corporation (C) 2014. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2,
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS 

[OpenWrt-Devel] [PATCH 1/5] oxnas: remove obsolete __cpuinit

[Daniel Golle]

Signed-off-by: Daniel Golle 
---
 target/linux/oxnas/files/arch/arm/mach-oxnas/platsmp.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/target/linux/oxnas/files/arch/arm/mach-oxnas/platsmp.c 
b/target/linux/oxnas/files/arch/arm/mach-oxnas/platsmp.c
index c41a3d1..8e4e2d8 100644
--- a/target/linux/oxnas/files/arch/arm/mach-oxnas/platsmp.c
+++ b/target/linux/oxnas/files/arch/arm/mach-oxnas/platsmp.c
@@ -60,7 +60,7 @@ static struct fiq_handler fh = {
 
 DEFINE_PER_CPU(struct fiq_req, fiq_data);
 
-static inline void __cpuinit ox820_set_fiq_regs(unsigned int cpu)
+static inline void ox820_set_fiq_regs(unsigned int cpu)
 {
struct pt_regs FIQ_regs;
struct fiq_req *fiq_req = _cpu(fiq_data, !cpu);
@@ -194,7 +194,7 @@ void fiq_flush_kern_dcache_area(void *addr, size_t size)
 
 static DEFINE_SPINLOCK(boot_lock);
 
-void __cpuinit ox820_secondary_init(unsigned int cpu)
+void ox820_secondary_init(unsigned int cpu)
 {
/*
 * Setup Secondary Core FIQ regs
@@ -214,7 +214,7 @@ void __cpuinit ox820_secondary_init(unsigned int cpu)
spin_unlock(_lock);
 }
 
-int __cpuinit ox820_boot_secondary(unsigned int cpu, struct task_struct *idle)
+int ox820_boot_secondary(unsigned int cpu, struct task_struct *idle)
 {
unsigned long timeout;
 
-- 
2.6.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/5] oxnas: fix duplicate include in clk-oxnas

[Daniel Golle]

Signed-off-by: Daniel Golle 
---
 target/linux/oxnas/files/drivers/clk/clk-oxnas.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/oxnas/files/drivers/clk/clk-oxnas.c 
b/target/linux/oxnas/files/drivers/clk/clk-oxnas.c
index 00d0f7a..4dc6c44 100644
--- a/target/linux/oxnas/files/drivers/clk/clk-oxnas.c
+++ b/target/linux/oxnas/files/drivers/clk/clk-oxnas.c
@@ -15,7 +15,7 @@
  * along with this program.  If not, see .
  */
 
-#include 
+#include 
 #include 
 #include 
 #include 
-- 
2.6.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 3/5] oxnas: prepare irqchip driver for kernel >=4.2

[Daniel Golle]

Signed-off-by: Daniel Golle 
---
 target/linux/oxnas/files/drivers/irqchip/irq-rps.c | 23 +++---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/target/linux/oxnas/files/drivers/irqchip/irq-rps.c 
b/target/linux/oxnas/files/drivers/irqchip/irq-rps.c
index 5795406..48b5d68 100644
--- a/target/linux/oxnas/files/drivers/irqchip/irq-rps.c
+++ b/target/linux/oxnas/files/drivers/irqchip/irq-rps.c
@@ -6,8 +6,13 @@
 #include 
 #include 
 #include 
+#include 
 
-#include "irqchip.h"
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4,2,0)
+# include "irqchip.h"
+#else
+# include 
+#endif
 
 struct rps_chip_data {
void __iomem *base;
@@ -73,7 +78,11 @@ static int rps_irq_domain_map(struct irq_domain *d, unsigned 
int irq,
irq_hw_number_t hw)
 {
irq_set_chip_and_handler(irq, _chip, handle_level_irq);
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4,2,0)
set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+#else
+   irq_set_probe(irq);
+#endif
irq_set_chip_data(irq, d->host_data);
return 0;
 }
@@ -83,10 +92,14 @@ const struct irq_domain_ops rps_irq_domain_ops = {
.xlate = rps_irq_domain_xlate,
 };
 
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4,2,0)
 static void rps_handle_cascade_irq(unsigned int irq, struct irq_desc *desc)
+#else
+static void rps_handle_cascade_irq(struct irq_desc *desc)
+#endif
 {
-   struct rps_chip_data *chip_data = irq_get_handler_data(irq);
-   struct irq_chip *chip = irq_get_chip(irq);
+   struct rps_chip_data *chip_data = irq_desc_get_handler_data(desc);
+   struct irq_chip *chip = irq_desc_get_chip(desc);
unsigned int cascade_irq, rps_irq;
u32 status;
 
@@ -97,7 +110,11 @@ static void rps_handle_cascade_irq(unsigned int irq, struct 
irq_desc *desc)
cascade_irq = irq_find_mapping(chip_data->domain, rps_irq);
 
if (unlikely(rps_irq >= RPS_IRQ_COUNT))
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4,2,0)
handle_bad_irq(cascade_irq, desc);
+#else
+   handle_bad_irq(desc);
+#endif
else
generic_handle_irq(cascade_irq);
 
-- 
2.6.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 4/5] oxnas: prepare pinctrl for kernel >=4.2

[Daniel Golle]

Signed-off-by: Daniel Golle 
---
 target/linux/oxnas/files/drivers/pinctrl/pinctrl-oxnas.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/target/linux/oxnas/files/drivers/pinctrl/pinctrl-oxnas.c 
b/target/linux/oxnas/files/drivers/pinctrl/pinctrl-oxnas.c
index fa5f3a9..aa76f40 100644
--- a/target/linux/oxnas/files/drivers/pinctrl/pinctrl-oxnas.c
+++ b/target/linux/oxnas/files/drivers/pinctrl/pinctrl-oxnas.c
@@ -26,6 +26,7 @@
 #include 
 /* Since we request GPIOs from ourself */
 #include 
+#include 
 
 #include "core.h"
 
@@ -1187,7 +1188,11 @@ static struct irq_chip gpio_irqchip = {
.irq_set_type   = gpio_irq_type,
 };
 
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4,2,0)
 static void gpio_irq_handler(unsigned irq, struct irq_desc *desc)
+#else
+static void gpio_irq_handler(struct irq_desc *desc)
+#endif
 {
struct irq_chip *chip = irq_desc_get_chip(desc);
struct irq_data *idata = irq_desc_get_irq_data(desc);
@@ -1228,7 +1233,9 @@ static int oxnas_gpio_irq_map(struct irq_domain *h, 
unsigned int virq,
irq_set_lockdep_class(virq, _lock_class);
 
irq_set_chip_and_handler(virq, _irqchip, handle_edge_irq);
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4,2,0)
set_irq_flags(virq, IRQF_VALID);
+#endif
irq_set_chip_data(virq, oxnas_gpio);
 
return 0;
-- 
2.6.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] modules: package VIA AC97 modules

[Daniel Golle]

Signed-off-by: Daniel Golle 
---
 package/kernel/linux/modules/sound.mk | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/package/kernel/linux/modules/sound.mk 
b/package/kernel/linux/modules/sound.mk
index ab83103..603bb70 100644
--- a/package/kernel/linux/modules/sound.mk
+++ b/package/kernel/linux/modules/sound.mk
@@ -99,6 +99,23 @@ endef
 $(eval $(call KernelPackage,ac97))
 
 
+define KernelPackage/sound-mpu401
+  TITLE:=MPU-401 uart driver
+  KCONFIG:=CONFIG_SND_MPU401_UART
+  FILES:= \
+   $(LINUX_DIR)/sound/drivers/mpu401/snd-mpu401-uart.ko
+  AUTOLOAD:=$(call AutoLoad,35,snd-mpu401-uart)
+  $(call AddDepends/sound)
+endef
+
+define KernelPackage/sound-mpu401/description
+ support for MIDI ports compatible with the Roland MPU-401
+ interface in UART mode.
+endef
+
+$(eval $(call KernelPackage,sound-mpu401))
+
+
 define KernelPackage/sound-seq
   TITLE:=Sequencer support
   FILES:= \
@@ -134,6 +151,23 @@ endef
 $(eval $(call KernelPackage,sound-i8x0))
 
 
+define KernelPackage/sound-via82xx
+  TITLE:=VIA 82xx AC97 Controller
+  DEPENDS:=+kmod-ac97 +kmod-sound-mpu401
+  KCONFIG:=CONFIG_SND_VIA82XX
+  FILES:=$(LINUX_DIR)/sound/pci/snd-via82xx.ko
+  AUTOLOAD:=$(call AutoLoad,36,snd-via82xx)
+  $(call AddDepends/sound)
+endef
+
+define KernelPackage/sound-via82xx/description
+ support for the integrated AC97 sound device on motherboards
+ with VIA chipsets.
+endef
+
+$(eval $(call KernelPackage,sound-via82xx))
+
+
 define KernelPackage/sound-soc-core
   TITLE:=SoC sound support
   DEPENDS:=+kmod-regmap +kmod-ac97
-- 
2.6.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] modules: crypto-rng changes additions for kernel 4.3

[Daniel Golle]

Signed-off-by: Daniel Golle 
---
 package/kernel/linux/modules/crypto.mk | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/package/kernel/linux/modules/crypto.mk 
b/package/kernel/linux/modules/crypto.mk
index 82d2ca8..1179fff 100644
--- a/package/kernel/linux/modules/crypto.mk
+++ b/package/kernel/linux/modules/crypto.mk
@@ -100,15 +100,25 @@ $(eval $(call KernelPackage,crypto-wq))
 define KernelPackage/crypto-rng
   TITLE:=CryptoAPI random number generation
   KCONFIG:=CONFIG_CRYPTO_RNG2
-  FILES:= \
-   $(LINUX_DIR)/crypto/rng.ko \
-   $(LINUX_DIR)/crypto/krng.ko
+  FILES:=$(LINUX_DIR)/crypto/rng.ko
+ifeq ($(strip $(call CompareKernelPatchVer,$(KERNEL_PATCHVER),lt,4.2.0)),1)
+  FILES+=$(LINUX_DIR)/crypto/krng.ko
+endif
   AUTOLOAD:=$(call AutoLoad,09,rng krng)
   $(call AddDepends/crypto)
 endef
 
 $(eval $(call KernelPackage,crypto-rng))
 
+define KernelPackage/crypto-rng-jitterentropy
+  TITLE:=Jitterentropy Non-Deterministic Random Number Generator
+  KCONFIG:=CONFIG_CRYPTO_JITTERENTROPY
+  FILES:= $(LINUX_DIR)/crypto/jitterentropy_rng.ko
+  AUTOLOAD:=$(call AutoLoad,10,jitterentropy-rng)
+  $(call AddDepends/crypto)
+endef
+
+$(eval $(call KernelPackage,crypto-rng-jitterentropy))
 
 define KernelPackage/crypto-iv
   TITLE:=CryptoAPI initialization vectors
-- 
2.6.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 0/5] oxnas: update platform and drivers for kernel 4.3

[Daniel Golle]

Quite some maintainance work was needed to keep oxnas working on more
recent kernels.
Most notably, stmmac was restructured upstream and now enforces SoC
glue to live in platform drivers.

  oxnas: remove obsolete __cpuinit
  oxnas: fix duplicate include in clk-oxnas
  oxnas: prepare irqchip driver for kernel >=4.2
  oxnas: prepare pinctrl for kernel >=4.2
  oxnas: move gmac soc glue from mach to stmmac driver

 .../oxnas/files/arch/arm/mach-oxnas/mach-ox820.c   | 101 
 .../oxnas/files/arch/arm/mach-oxnas/platsmp.c  |   6 +-
 target/linux/oxnas/files/drivers/clk/clk-oxnas.c   |   2 +-
 target/linux/oxnas/files/drivers/irqchip/irq-rps.c |  23 ++-
 .../net/ethernet/stmicro/stmmac/dwmac-oxnas.c  | 172 +
 .../oxnas/files/drivers/pinctrl/pinctrl-oxnas.c|   7 +
 .../linux/oxnas/patches-4.1/700-oxnas-dwmac.patch  |  25 +++
 7 files changed, 228 insertions(+), 108 deletions(-)
 create mode 100644 
target/linux/oxnas/files/drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
 create mode 100644 target/linux/oxnas/patches-4.1/700-oxnas-dwmac.patch

-- 
2.6.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel