Re: [VOTE] New member proposal: Robimarko (Robert Marko)

[Luka Perkov via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Tue, Jan 30, 2024 at 7:17 PM Christian Marangi (Ansuel)
 wrote:
> Robert is active in OpenWrt since 2017 and with some recent stats, he
> has more than 310 commits merged in OpenWrt.
> He also have uncounted Reviewed-by tag on various PR and merged commits
> and generally helps in everything related to IPQ (ipq806x, ipq40xx and
> ipq807x) and some mvebu targets.
>
> He did the conversion of ipq40xx target to DSA and made possible the
> introduction of the ipq807x target by sorting all the QSDK downstream
> patch and pushing them upstream.
>
> With his help, also the ipq60xx is very close on getting merged and
> actually used permitting support of even more device for OpenWrt.
>
> Also he is almost always reachable on IRC openwrt-devel and never had
> a problem in coordinating and collaborating with him.
>
> I think Robert is a good addition to our team and would massively help
> me (Ansuel) in maintaining each IPQ target and review all the related
> PR on github and patchwork.
> I would like to add Robert to the OpenWrt committers team.
>
> The vote shall be concluded within 14 days. (13/02/2024)

+1

Luka

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH packages] rpcd-mod-lxc: add "info" ubus method (similar to the lxc-info)

[Luka Perkov]

> On Nov 7, 2017, at 12:02 PM, Rafał Miłecki <zaj...@gmail.com> wrote:
> 
> From: Rafał Miłecki <ra...@milecki.pl>
> 
> This method allows getting basic info about a queried container. It's
> based on the lxc-info command-line tool.
> 
> Example output:
>> ubus call lxc info '{ "name": "foo" }'
> {
>"name": "foo",
>"state": "RUNNING",
>"pid": 2946,
>    "ips": [
>"192.168.0.124"
>]
> }
> 
> Signed-off-by: Rafał Miłecki <ra...@milecki.pl>

Approved-by: Luka Perkov <l...@openwrt.org>

> ---
> utils/rpcd-mod-lxc/files/lxc.c | 43 ++
> 1 file changed, 43 insertions(+)
> 
> diff --git a/utils/rpcd-mod-lxc/files/lxc.c b/utils/rpcd-mod-lxc/files/lxc.c
> index 0d52f167..6db1b311 100644
> --- a/utils/rpcd-mod-lxc/files/lxc.c
> +++ b/utils/rpcd-mod-lxc/files/lxc.c
> @@ -317,6 +317,48 @@ out:
> }
> 
> static int
> +rpc_lxc_info(struct ubus_context *ctx, struct ubus_object *obj,
> + struct ubus_request_data *req, const char *method,
> + struct blob_attr *msg)
> +{
> +struct blob_attr *tb[__RPC_LXC_RENAME_MAX];
> +struct rpc_lxc *l = NULL;
> +char **addresses;
> +void *k;
> +pid_t initpid;
> +
> +blobmsg_parse(rpc_lxc_min_policy, __RPC_LXC_MAX, tb, blob_data(msg), 
> blob_len(msg));
> +
> +l = rpc_lxc_init(tb);
> +if (!l)
> +return UBUS_STATUS_INVALID_ARGUMENT;
> +blob_buf_init(, 0);
> +
> +blobmsg_add_string(, "name", l->container->name);
> +
> +blobmsg_add_string(, "state", l->container->state(l->container));
> +
> +initpid = l->container->init_pid(l->container);
> +if (initpid >= 0)
> +blobmsg_add_u32(, "pid", initpid);
> +
> +k = blobmsg_open_array(, "ips");
> +addresses = l->container->get_ips(l->container, NULL, NULL, 0);
> +if (addresses) {
> +int i;
> +
> +for (i = 0; addresses[i]; i++)
> +blobmsg_add_string(, "ip", addresses[i]);
> +}
> +blobmsg_close_array(, k);
> +
> +ubus_send_reply(ctx, req, buf.head);
> +rpc_lxc_done(l);
> +
> +return UBUS_STATUS_OK;
> +}
> +
> +static int
> rpc_lxc_rename(struct ubus_context *ctx, struct ubus_object *obj,
>struct ubus_request_data *req, const char *method,
>struct blob_attr *msg)
> @@ -480,6 +522,7 @@ rpc_lxc_api_init(const struct rpc_daemon_ops *o, struct 
> ubus_context *ctx)
>UBUS_METHOD("stop", rpc_lxc_stop, rpc_lxc_min_policy),
>UBUS_METHOD("freeze", rpc_lxc_freeze, rpc_lxc_min_policy),
>UBUS_METHOD("unfreeze", rpc_lxc_unfreeze, rpc_lxc_min_policy),
> +UBUS_METHOD("info", rpc_lxc_info, rpc_lxc_min_policy),
>UBUS_METHOD("rename", rpc_lxc_rename, rpc_lxc_rename_policy),
>UBUS_METHOD("create", rpc_lxc_create, rpc_lxc_create_policy),
>UBUS_METHOD("destroy", rpc_lxc_destroy, rpc_lxc_min_policy),
> -- 
> 2.11.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [LEDE-DEV] rpcd-mod-nosql - prpl funding proposal

[Luka Perkov]

Hi Jo,

can you define the session namespace and how this existing feature can be used?

Thanks,
Luka

On Thu, Nov 10, 2016 at 9:37 AM, Jo-Philipp Wich  wrote:
> Hi Luka,
>
> in rpcd there already is the ability to store arbitrarily nested
> key-value data in the session namespace which is even persistent over
> daemon reloads. Is this not sufficient? And if not, what is missing?
>
> ~ Jo
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] rpcd-mod-nosql - prpl funding proposal

[Luka Perkov]

Hi all!

Over and over again we are running into a situation where we need to
store or cache for a period of time some arbitrary (runtime) data.
Instead of working around these situations by using /tmp/ directory as a
placeholder we propose a tiny "nosql" ubus based mechanism implemented
as a rpcd plugin [1].

More information is available in the official document, feedback is
welcomed!

Regards,
Luka

[1] http://www.sartura.hr/static/pdf/prpl-proposal-rpcd-mod-nosql.pdf
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Why was libwebswocekts bumped in the for-15.05 branch?

[Luka Perkov]

Hi Karl,

thanks for pointing this out. I'm sorry but this commit ended up in the
wrong git repo :(

It is now reverted:

https://github.com/openwrt/packages/commit/b3139cf56c2f3ff80dc29239cccf9c7b6bcb5f9d

Thanks again,
Luka

On Tue, Nov 08, 2016 at 10:12:43AM -, Karl Palsson wrote:
> 
> It seems highly inappropriate to bump a package to a completely
> incompatible version in the stable 15.05 branch. It was always
> beaten into me that the only updates for packages in stable
> branches were for point releases and bugfixes. Bumping
> libwebsockets to the _very_ incompatible 2.x from the 1.3 release
> that had been stable in the 15.05 branch makes no sense to me,
> and I see no emails even complaining about the old version in
> 15.05, let alone asking for a new one.
> 
> Ref:
> https://github.com/openwrt/packages/commit/e245e2b8246d0d25892d3dc2af0d3834ef95a02e
> 
> If this is for some project of your own, please use your own
> private feed instead of trampling over everyone's stable branch.
> If the stable branch is too old, perhaps consider whether a new
> release is due.
> 
> Re ABI compatibility:
> https://libwebsockets.org/abi/timeline/libwebsockets/index.html
> the version you've updated from is so different it's not even
> listed on the page!
> 
> Sincerely,
> Karl Palsson
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH packages] pptpd: run service in foreground for procd compatibility

[Luka Perkov]

Hi Rafał,

On Wed, Sep 28, 2016 at 12:56:27AM +0200, Rafał Miłecki wrote:
> On 28 September 2016 at 00:37, Luka Perkov <l...@openwrt.org> wrote:
> > On Mon, Sep 26, 2016 at 07:59:30AM +0200, Rafał Miłecki wrote:
> >> From: Rafał Miłecki <ra...@milecki.pl>
> >>
> >> To have service working nicely with procd it should be running in the
> >> foreground. Otherwise it's not possible to e.g. stop it with the init.d
> >> script. Luckily for us pptpd has a simple switch that allows it.
> >>
> >> Signed-off-by: Rafał Miłecki <ra...@milecki.pl>
> >> Fixes: 15e7f611afb ("pptpd: convert init script to procd")
> >> ---
> >> Hi Luka,
> >>
> >> This pptpd package with broken procd compatibility has been also backported
> >> to the for-15.05 branch. Can you apply this fix to for-15.05 as well, 
> >> please?
> >
> > Thank you for the patch. We are using for quite a while GitHub pull
> > request workflow for all packages in the feeds. Please take a look at
> > the documentation:
> >
> > https://github.com/openwrt/packages/blob/master/CONTRIBUTING.md
> >
> > That said, can you make a pull request?
> 
> I'm not really comfortable using that proprietary service and its
> terrible UI.

Have you maybe changed your mind since the last time [1] you made commit
there?

> Could you consider accepting this e-mail submitted patch?
> You could trivially apply it with a single command:
> curl https://patchwork.ozlabs.org/patch/674965/mbox/ | git am

In any case I am okay with the patch, feel free to add my Acked-by and
push it in the tree.

Acked-by: Luka Perkov <l...@openwrt.org>

Thanks,
Luka

[1] 
https://github.com/openwrt/packages/commit/2872ed64cc609f8449de3529f3e6db66151aa164
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] openwrt userspace git repo location

[Luka Perkov]

Hi Felix,

it seems there is some divergence from the Git repos hosted on OpenWrt
site and on LEDE:

http://git.openwrt.org/?p=project/ubus.git;a=summary
https://git.lede-project.org/?p=project/ubus.git;a=summary

Do you know why is that?

Speaking of this topic I'd like to propose that we host these repos in a
single location on GitHub under the OpenWrt project here:

https://github.com/openwrt

GitHub proved to be convinient in attracting easier collaboration. I'm
wondering what the community thinks about this proposal. Thoughts?

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

Re: [OpenWrt-Devel] [PATCH packages] pptpd: run service in foreground for procd compatibility

[Luka Perkov]

Hi Rafał,

On Mon, Sep 26, 2016 at 07:59:30AM +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> To have service working nicely with procd it should be running in the
> foreground. Otherwise it's not possible to e.g. stop it with the init.d
> script. Luckily for us pptpd has a simple switch that allows it.
> 
> Signed-off-by: Rafał Miłecki 
> Fixes: 15e7f611afb ("pptpd: convert init script to procd")
> ---
> Hi Luka,
> 
> This pptpd package with broken procd compatibility has been also backported
> to the for-15.05 branch. Can you apply this fix to for-15.05 as well, please?

Thank you for the patch. We are using for quite a while GitHub pull
request workflow for all packages in the feeds. Please take a look at
the documentation:

https://github.com/openwrt/packages/blob/master/CONTRIBUTING.md

That said, can you make a pull request?

Thanks,
Luka

> ---
>  net/pptpd/files/pptpd.init | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/pptpd/files/pptpd.init b/net/pptpd/files/pptpd.init
> index 0d18aa1..294b00f 100644
> --- a/net/pptpd/files/pptpd.init
> +++ b/net/pptpd/files/pptpd.init
> @@ -67,6 +67,6 @@ start_service() {
>   ln -sfn $CHAP_SECRETS /etc/ppp/chap-secrets
>  
>   procd_open_instance
> - procd_set_param command $BIN -c $CONFIG -o $OPTIONS_PPTP
> + procd_set_param command $BIN -c $CONFIG --fg -o $OPTIONS_PPTP
>   procd_close_instance
>  }
> -- 
> 2.9.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] imports from LEDE to OpenWrt github repo

[Luka Perkov]

On Sat, Jun 25, 2016 at 02:10:28PM +0200, John Crispin wrote:
> thanks ! i would not ask for it normally but if you are at it anyhow you
> might aswell. the rest looks good.

It seems that this was oversight in merging commits... However, changing
the Git history will mess up the repo since git force push will be
required due to the fact that the hashes and history will change. I'd
rather that we do not do that in both projects, but if you really insist
so will I [1][2] ;)

I propose that both sides are more careful next time. Also, if the
patches taken from both projects are not 100% mergable that at least in
commit message is mentioned "Based on work from Foo Bar".

Luka

[1] 
https://github.com/openwrt/openwrt/commit/d82186f7bfa93e7f25af266b0bff8030370d7b51
[2] 
https://git.lede-project.org/?p=source.git;a=commitdiff;h=d02f109ee40f534ad8358d89563965f903aa5168
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] OpenWrt main tree moves to GitHub

[Luka Perkov]

Dear OpenWrt developers and users,

As announced previously, we have moved the OpenWrt codebase  to GitHub [1].
Since OpenWrt used SVN before and had a Git mirror hosted, we have
decided to reuse OpenWrt Git mirror tree already hosted on GitHub. That
said, the following points are relevant to the switch:

* Developers can send pull requests for this repository - this is an
  addition over the earlier patchwork-based workflow.
 
* For patches that need further discussion, the openwrt-devel list is
  still open, the patchwork site is still open.
 
* We are going through the current patchwork tickets [2] and pull them
  in if possible. 
 
* buildbots will be pointed to the new code source early next week.

* To file bug tickets, the current trac site (https://dev.openwrt.org)
  is still the preferred way of opening the tickets.

* We will update the documentation on the official OpenWrt sites.

Additionally, we have created a CI feature, tightly integrated with the
new GitHub tree - this will enable developers to have a better view into
the commits. For now this integration is only for the defconfig
settings, kicking off a new build with any new pull request. Further
documentation of this feature can be found here [3].

Furthermore, we are planning to have releases every 6 months preferably
with LTS or LTSI kernel, starting in August.

Let us know your thoughts, feedback and comments are welcome.

Thanks,
The OpenWrt team

[1] https://github.com/openwrt/openwrt
[2] http://patchwork.ozlabs.org/project/openwrt/list/
[3] https://wiki.openwrt.org/about/drone
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [OpenWrt] TR-069 for OpenWrt

[Luka Perkov]

Hi Delbar,

On Thu, May 26, 2016 at 11:43:28PM +, Delbar Jos wrote:
> At Technicolor we have followed with great interest the recent proposals to 
> enhance OpenWrt with an open source solution for TR-069 remote management. As 
> one of the world's largest vendors of modems and routers for carrier 
> applications, making use of OpenWrt in a significant share of our install 
> base, we want to support this initiative in a meaningful way. Concretely, we 
> are willing to open source Technicolor's in-house TR-069 solution and thereby 
> contribute to OpenWrt:
>  * a TR-069 protocol agent,
>  * a data model mapping framework that we use to bridge the world of OpenWrt, 
> UCI, UBUS ... with the world of TR-069, TR-098, TR-181 ... (and by extension 
> with the world of SNMP, MIB, NETCONF, YANG ...),
>  * a set of mappings.
> 
> We are conscious of the fact that together with the proposals made by Felix,
> Luka and Wojtek we are now looking at many "competing" proposals. As a next
> step, we recommend to organize a workshop, at a practical location and time,
> where we put everything on the table and define the most appropriate path
> forward to the benefit of OpenWrt as a whole.
> 
> TR-069 is a complicated remote management system and in order to make this
> initiative a success, we must ensure that the complexity is handled in an
> elegant way and with respect for OpenWrt's core architecture. More than on
> the protocol itself, we believe that we should focus on the architectural
> enhancements required to support remote management in general.
> 
> Looking forward to hearing from you.

Thank you for your proposal and offer. I think this effort and workshop are
great news. I'm also looking forward to see if more companies will decide to
join CWMP/TR-* discussions and more importantly at the end of the day
have a stable and well defined TR-069 stack implemented in OpenWrt!

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

Re: [OpenWrt-Devel] [OpenWrt-Users] [PROPOSAL] move OpenWrt codebase to Git and GitHub

[Luka Perkov]

Thanks for the numbers Jo. The current hello-world setup with drone.io
was done on cheap SSD based VPS. That said, with some "optimizations"
(or hacks if you want) I think it should be possible to have less
powerful servers but more of them to do what is needed.

For example, if one makes pull request for package A. Then for every
target only the core system with package A and it's dependencies should
be built. That said, if pull request is valid it will result with a
successful build. We should avoid situations where somebody makes a patch
for package A and if fails to build because package Z unrelated to
package A is broken.

Luka

On Tue, May 24, 2016 at 10:35:42PM +0200, Jo-Philipp Wich wrote:
> Hi,
> 
> here's a few numbers we gathered with our buildbot setup:
> 
> We currently need roughly 35GB per target when building OpenWrt plus the
> entire package world and currently there are roughly ~70
> target/subtarget combinations in the OpenWrt tree.
> 
> If fast build tests are desired then the only way to do so is by
> implementing incremental building which only works if there's enough
> space to retain all build trees at once which means there need to be
> about 2.5TB of storage available.
> 
> For only building all base systems without package feeds the entire
> required space is around 800GB.
> 
> A base system build currently requires 1 hour and 15 minutes on a
> machine having a Xeon E3-1246 v3 4 core / 8 thread CPU with prepopulated
> dl/, ccache and make -j8.
> 
> A build of all packages from all feeds takes around 70 minutes on a Xeon
> E5-2630 v3 8 core / 16 thread machine with 12GB ram and make -j16.
> 
> HTH,
> Jo
> ___
> 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] [PROPOSAL] move OpenWrt codebase to Git and GitHub

[Luka Perkov]

On Tue, May 24, 2016 at 10:29:30AM -0700, David Lang wrote:
> OpenWRT has already moved to using Git instead of SVN,

No, it has not. To users is exposed the Git frontend while the commits
are made to the SVN repo.

> so why do they need to move from hosting the git repository themselves to
> having it hosted on github?

See the reasons below.

> There can be a mirror of the repo on github (remember that git is a
> Decentralized VCS)

Also, we have discussed of having a mirror on our server and this is something
that we can do. If everything happens on GitHub then I don't see a point in
having clone on GitHub instead of a having the main repo on GitHub and having
clone elsewhere.

> > * GitHub and similar services will allow us to integrate more easily
> > with other projects
> > 
> > Here specifically I mean integration with modern CI. Here is an example
> > of integration with drone.io [3][4]. At the moment this is only in the
> > POC stage but what I'd like to do down the line is to:
> > 
> > - build OpenWrt images for all architectures for every pull request
> > - build OpenWrt package binary for every package pull request for all
> > architectures and make it available for download
> > 
> > - build and host OpenWrt qemu and/or Docker image for every pull request
> 
> the build farm isn't large enough to do this

Current one is not.
 
> It's also not neccessary to move to github to be able to do this, it just
> needs more systems in the build farm to be able to build things fast enough.

With GitHub it will be able to see compile status of each pull request. If it
is not GitHub or simmilar service then this would need to be developed and I
think we have better things to do then that :)

> > This will allow easy review of the work since flags will be shown in the
> > pull request if the build was sucessful or not. Also, this will allow
> > people to test changes without building the image and thus lowering the
> > time that needs to be spent on maintenance work.
> > 
> > If this proposal gets accepted I'll be sending out an email to get
> > access to more build servers so this new build infrastructure can
> > properly support the project in a timely fashion.
> 
> why should providing more build servers be contingent on moving to a
> commercial hosting provider vs running things themselves?

IMO move to GitHub will allow us to manage contributions more easily and handle
them in timely fashion. This, combined with other perks explained in my
previous email is possible today without need to develop the features that
others provide today.

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

Re: [OpenWrt-Devel] [PROPOSAL] move OpenWrt codebase to Git and GitHub

[Luka Perkov]

On Tue, May 24, 2016 at 10:51:46AM -0500, Eric Schultz wrote:
> My free-software side worries about using something non-free like drone.io
> for CI but this is a huge task certainly and I'm not sure a free tool would
> meet everyone's needs (plus there's the huge added burden of maintenance).

The drone.io is actually Apache 2.0 [1] and the example build was
configured on a private machine.

Luka

[1] https://github.com/drone/drone
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PROPOSAL] move OpenWrt codebase to Git and GitHub

[Luka Perkov]

Dear OpenWrt mailing list readers,

as the subject says I'd like to make proposal to move the OpenWrt
codebase to Git. This was already discussed before [1] and now when
there are no blockers [2] for this change I'd like that we as a
community move forward with this switch.

Also, I'd like to propose that we move the project to GitHub and here
are the reasons why I see this as a good decision:

* GitHub will allow people to contribute more easily

The bigger amount of contributions has already happened and can be seen
on the packages feed which is already hosted on GitHub. With this I'm
also hoping to avoid comments regarding invalid patches on the mailing
list.

For now I am proposing that the current development workflow is also
accepted - aka. patches that are sent to the mailing list are also
accepted.

* GitHub and similar services will allow us to integrate more easily
with other projects

Here specifically I mean integration with modern CI. Here is an example
of integration with drone.io [3][4]. At the moment this is only in the
POC stage but what I'd like to do down the line is to:

 - build OpenWrt images for all architectures for every pull request

 - build OpenWrt package binary for every package pull request for all
architectures and make it available for download

 - build and host OpenWrt qemu and/or Docker image for every pull request

This will allow easy review of the work since flags will be shown in the
pull request if the build was sucessful or not. Also, this will allow
people to test changes without building the image and thus lowering the
time that needs to be spent on maintenance work.

If this proposal gets accepted I'll be sending out an email to get
access to more build servers so this new build infrastructure can
properly support the project in a timely fashion.

Please share your thoughts regarding this proposal.

Regards,
Luka

[1] https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036390.html
[2] https://lists.openwrt.org/pipermail/openwrt-devel/2016-May/041329.html
[3] https://github.com/makkrnic/openwrt-qemu-x86
[4] http://sartura-drone.makkrnic.com/makkrnic/openwrt-qemu-x86/5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [OpenWrt] rocket cwmp - open tr-069 client for embedded platforms

[Luka Perkov]

Hi Wojtek,

On Thu, May 19, 2016 at 11:03:28AM +0200, Wojtek MAKOWSKI wrote:
> Luka, Felix and others,
> 
> Regarding the TR069 stack for OpenWrt I would like to propose our own
> (i.e. SoftAtHome's) stack. Today it's a part of our commercial solution
> but we are ready to deliver it (for free, of course) with an open-source
> license. It's biggest advantage is that it already runs in 20M+ boxes of
> several carriers and is fully interoperable with several carrier-grade
> ACSs. 
> 
> What do you think about that?

Thank you for your proposal and offer. These are great news and this is
something that we were aiming to achieve with the Rocket CWMP project -
to build a carrier community. There are technical items on how to
make this happen but these are just details that we can work together
on.

I am also aware of several other solutions and hope that these vendors
and individuals will decide to contribute as well. I'm looking forward
to see this moving forward!

Regards,
Luka

> Best regards,
> Wojtek Makowski
> SoftAtHome
> 
> -Original Message-
> From: openwrt-boun...@lists.prplfoundation.org
> [mailto:openwrt-boun...@lists.prplfoundation.org] On Behalf Of Luka Perkov
> Sent: Thursday, May 19, 2016 1:09 AM
> To: openwrt-propos...@prplfoundation.org
> Cc: open...@lists.prplfoundation.org; OpenWrt Development List;
> lede-...@lists.infradead.org
> Subject: [OpenWrt] rocket cwmp - open tr-069 client for embedded platforms
> 
> Hi all!
> 
> prpl Foundation has made the invitation to propose OpenWrt enhancement
> ideas which may end up funded by the same organization [1]. With this
> email I'm offering to prpl Foundation to fund Rocket CWMP project - which
> is the client implementation of CWMP / TR-069 protocol. Since this is a
> good opportunity to further extend OpenWrt functionality I'm adding
> several other mailing lists in CC and hope to initiate discussions
> regarding this proposal and project.
> 
> CWMP (TR-069) [2] has a very important role both for ISP and for the
> entire ecosystem with manufacturers included. The standard form of CWMP
> was primarily developed for a number of Internet access devices, such as
> modems, set-top boxes, VolP phones and routers. TR-069 standardizes the
> wide area network (WAN) management of CWMP devices and gives Internet
> Service Providers a framework and a common language to remotely provision
> and manage these devices regardless of device type or manufacturer. There
> are around twenty TR-* documents which mostly define new parameters or
> extend the RPC (Remote Procedure Call) methods.
> 
> CWMP (CPE WAN Management Protocol), sometimes called TR-069 (Technical
> Report 069), is a technical specification of a Broadband Forum designed
> for remote governing of CPE (Customer Premises Equipment). Seeing that
> CWMP is a standardized, text based protocol which offers a communication
> between CPE and Auto Configuration Servers (ACS), it can be used between
> different equipment manufacturers. 
> 
> Couple of years back I've authored the first Open Source TR-069 client
> specifically targeting OpenWrt - it was named freecwmp [3]. Since then
> I've learned a lot of lessons and in the company, Sartura, the team has
> started developing new implementation which solves the limitations of the
> old implementation.
> 
> If funded, we are going to use the budget to further improve existing
> codebase and of course to clean it up and prepare for Open Source release.
> In order to make this a success, we will work on the documentation,
> testing infrastructure and make it easy for vendors and hackers to use
> this project when needed.
> 
> I'll be making Rocket CWMP presentation on the prplwrt meeting on May 19
> (tomorrow). [4] These meetings are usually recorded and published on
> YouTube. I hope that will happen with this meeting as well in case
> somebody is interested but is not able to join.
> 
> More information about the proposal can be found on the prpl Wiki [5] and
> in the proposal documentation [6][7]. Comments are welcome!
> 
> Sincerely,
> Luka Perkov
> 
> [1] http://wiki.prplfoundation.org/wiki/OpenWrt_Funding
> [2] https://www.broadband-forum.org/cwmp.php
> [3]
> https://lists.openwrt.org/pipermail/openwrt-devel/2012-June/015655.html
> [4] http://lists.prplfoundation.org/pipermail/openwrt/2016-May/000544.html
> [5] http://wiki.prplfoundation.org/wiki/OpenWrt_Funding/Rocket_CWMP
> [6] http://www.sartura.hr/cwmp/sartura-prpl-rocket-cwmp-public.pdf
> [7] http://www.sartura.hr/cwmp/sartura-prpl-rocket-cwmp-slides-public.pdf
> ___
> OpenWrt mailing list
> open...@lists.prplfoundation.org
> http://lists.prplfoundation.org/cgi-bin/mailman/listinfo/openwrt
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] rocket cwmp - open tr-069 client for embedded platforms

[Luka Perkov]

Hi all!

prpl Foundation has made the invitation to propose OpenWrt enhancement
ideas which may end up funded by the same organization [1]. With this
email I'm offering to prpl Foundation to fund Rocket CWMP project -
which is the client implementation of CWMP / TR-069 protocol. Since this
is a good opportunity to further extend OpenWrt functionality I'm adding
several other mailing lists in CC and hope to initiate discussions
regarding this proposal and project.

CWMP (TR-069) [2] has a very important role both for ISP and for the
entire ecosystem with manufacturers included. The standard form of CWMP
was primarily developed for a number of Internet access devices, such as
modems, set-top boxes, VolP phones and routers. TR-069 standardizes the
wide area network (WAN) management of CWMP devices and gives Internet
Service Providers a framework and a common language to remotely
provision and manage these devices regardless of device type or
manufacturer. There are around twenty TR-* documents which mostly define
new parameters or extend the RPC (Remote Procedure Call) methods.

CWMP (CPE WAN Management Protocol), sometimes called TR-069 (Technical
Report 069), is a technical specification of a Broadband Forum designed
for remote governing of CPE (Customer Premises Equipment). Seeing that
CWMP is a standardized, text based protocol which offers a communication
between CPE and Auto Configuration Servers (ACS), it can be used between
different equipment manufacturers. 

Couple of years back I've authored the first Open Source TR-069 client
specifically targeting OpenWrt - it was named freecwmp [3]. Since then
I've learned a lot of lessons and in the company, Sartura, the team has
started developing new implementation which solves the limitations of
the old implementation.

If funded, we are going to use the budget to further improve existing
codebase and of course to clean it up and prepare for Open Source
release. In order to make this a success, we will work on the
documentation, testing infrastructure and make it easy for vendors and
hackers to use this project when needed.

I'll be making Rocket CWMP presentation on the prplwrt meeting on May 19
(tomorrow). [4] These meetings are usually recorded and published on
YouTube. I hope that will happen with this meeting as well in case
somebody is interested but is not able to join.

More information about the proposal can be found on the prpl Wiki [5]
and in the proposal documentation [6][7]. Comments are welcome!

Sincerely,
Luka Perkov

[1] http://wiki.prplfoundation.org/wiki/OpenWrt_Funding
[2] https://www.broadband-forum.org/cwmp.php
[3] https://lists.openwrt.org/pipermail/openwrt-devel/2012-June/015655.html
[4] http://lists.prplfoundation.org/pipermail/openwrt/2016-May/000544.html
[5] http://wiki.prplfoundation.org/wiki/OpenWrt_Funding/Rocket_CWMP
[6] http://www.sartura.hr/cwmp/sartura-prpl-rocket-cwmp-public.pdf
[7] http://www.sartura.hr/cwmp/sartura-prpl-rocket-cwmp-slides-public.pdf
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] [package] linux: Add new Marvell cryptoengine

[Luka Perkov]

Hi Michal,

On Fri, May 13, 2016 at 11:30:10AM +0200, Michal Hrusecky wrote:
> Adding new Marvell cryptoengine as some device might use the new one and not
> the old one.

I'm assuming that the "New Marvell crypto engine" is taken from mainline
kernel. Since the "Old Marvell crypto engine" is not in mainline I'd
rather that somewhere along the line it gets replaced entirely by the
mainline one. That said, can you send v2 where you remove the "New" from
the Title and make it depend on a newer mainline kernels which have
support for this crypto engine.

Thanks,
Luka
 
> Signed-off-by: Michal Hrusecky 
> ---
>  package/kernel/linux/modules/crypto.mk | 20 +---
>  1 file changed, 17 insertions(+), 3 deletions(-)
> 
> diff --git a/package/kernel/linux/modules/crypto.mk 
> b/package/kernel/linux/modules/crypto.mk
> index 0acc730..0f37a55 100644
> --- a/package/kernel/linux/modules/crypto.mk
> +++ b/package/kernel/linux/modules/crypto.mk
> @@ -711,14 +711,28 @@ endef
>  
>  $(eval $(call KernelPackage,crypto-xts))
>  
> -
>  define KernelPackage/crypto-mv-cesa
> -  TITLE:=Marvell crypto engine
> +  TITLE:=Old Marvell crypto engine
>DEPENDS:=+kmod-crypto-manager @TARGET_kirkwood||TARGET_orion||TARGET_mvebu
> -  KCONFIG:=CONFIG_CRYPTO_DEV_MV_CESA
> +  KCONFIG:= \
> + CONFIG_CRYPTO_DEV_MV_CESA \
> + CONFIG_CRYPTO_HW=y
>FILES:=$(LINUX_DIR)/drivers/crypto/mv_cesa.ko
>AUTOLOAD:=$(call AutoLoad,09,mv_cesa)
>$(call AddDepends/crypto)
>  endef
>  
>  $(eval $(call KernelPackage,crypto-mv-cesa))
> +
> +define KernelPackage/crypto-marvell-cesa
> +  TITLE:=New Marvell crypto engine
> +  DEPENDS:=+kmod-crypto-manager @TARGET_kirkwood||TARGET_orion||TARGET_mvebu
> +  KCONFIG:= \
> + CONFIG_CRYPTO_DEV_MARVELL_CESA \
> + CONFIG_CRYPTO_HW=y
> +  FILES:=$(LINUX_DIR)/drivers/crypto/marvell/marvell-cesa.ko
> +  AUTOLOAD:=$(call AutoLoad,09,marvell-cesa)
> +  $(call AddDepends/crypto)
> +endef
> +
> +$(eval $(call KernelPackage,crypto-marvell-cesa))
> -- 
> 2.8.2
> ___
> 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] [Summit-committee] OpenWrt summit by prpl

[Luka Perkov]

Hi Hauke,

On Fri, May 13, 2016 at 12:44:50AM +0200, Hauke Mehrtens wrote:
> When I use OpenWrt in this mail, I mean OpenWrt and LEDE, I hope we come
> to a solution in the next days on this.

It is strange to see you defining OpenWrt and LEDE as a same project -
especially due to the fact that LEDE is a fork (if you don't believe me
take a look at LEDE commit logs). To make things worse we've witnessed
that LEDE team members have been closing tickets or putting them in
"wontfix" state on official OpenWrt bugtracker - the fixes or
improvements did not land in OpenWrt while at the same time implementing
those changes in LEDE. While I don't mind in LEDE taking it's own
direction I do not approve this kind of behavior. Do you mind
explaining what does LEDE or its developers want to gain from such
actions?

Furthermore, I also find it extremely unprofessional to see you make
claims such as this one, c/p from Kathy's meeting summary: "Hauke
mentioned that some core developers don't like prpl." Who are these
"core" developers who make such claims? Are they even involved anymore
with OpenWrt?

> prpl wants to organize an OpenWrt summit again. Their goal is to bring
> the community, industry and developers together. Currently this is in
> planing and I want to know what should happen so that more developers
> and more members of the community would come to such an event.

I personally support prpl in this efforts due to the fact that last
summit was great and they did a good job with the conference and
organization.

> There are different ideas on how to organize such an event:
> 1. prpl organizes an event co located with the Embedded Linux conference
> this October in Berlin.
> 2. prpl organizes an event co located with Battlemesh next year in May.
> 3. Some people from OpenWrt organize an event in Prague at CZ.NIC.
> CZ.NIC would provide a location and local logistics, prpl could help
> with finance.

I am okay with all options but due to the efforts shown by CZ.NIC I'm
most likely going to give my vote to Prague.
 
> It is also possible to do more than one solution or combine them.
> 
> Are there some people interested in organizing this by themselves with
> the help of CZ.NIC, then we could go with this solution?
> If nobody is interested in organizing this I would like to see it co
> located with the ELCE and the Battlemesh next year.
> 
> No final name for this event was chosen. The current suggestion is
> "OpenWrt summit by prpl" or something similar.

If prpl organizes the event and/or gives funding for it they should be
credited for doing it.

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

Re: [OpenWrt-Devel] Failed to execute /usr/libexec/login.sh

[Luka Perkov]

Hi Alexey,

On Wed, May 11, 2016 at 10:08:55PM +, Alexey Brodkin wrote:
> Hi Daniel,
> 
> Looks like one recent commit:
> ->8-
> commit a1860283b37c7a26f78c7387227a42219e8b4d4d
> Author: luka 
> Date:   Tue May 10 22:36:25 2016 +
> 
> image / basefiles: make console password configurable
> 
> Signed-off-by: Daniel Dickinson 
> Signed-off-by: John Crispin 
> 
> git-svn-id: svn://svn.openwrt.org/openwrt/trunk@49325 
> 3c298f89-4303-0410-b956-a3cf2f4a3e73
> ->8-
> 
> breaks something for my boards (in particular arc770-based boards).
> I'm unable to activate console now. That's what I'm getting
> every time I press ENTER:
> ->8-
> Failed to execute /usr/libexec/login.sh
> Please press Enter to activate this console.
> Failed to execute /usr/libexec/login.sh
> Please press Enter to activate this console.
> ->8-
> 
> If I revert mentioned commit problem goes away.

Thank you for reporting this.

> Any thoughts on what might be wrong here?

Can you please check r49376. I think that should fix it!

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

Re: [OpenWrt-Devel] Introducing the LEDE project

[Luka Perkov]

>On 2016-05-05 20:22, mbm wrote:
>> On 5/5/2016 7:40 AM, Felix Fietkau wrote:
>>> Many of the changes that we previously tried to introduce were often 
>>> squashed by internal disagreements. Resulting discussions often turned 
>>> toxic quickly and led to nothing being done to address the issues. 
>>> Setting up the LEDE project was our way of creating a testbed for 
>>> changes that we believe are important for the survival of the project. 
>>
>> Change is not easy. Discussions need to happen. The problem is simply
>> kicking out people you didn't agree with by starting a new organization
>> in secret; you've created the public perception that we're somehow
>> against you when really we all want the same things.
>
> Years of internal discussion led nowhere. Maybe it helps now that we're
> making the whole issue public.

For the sake of transparency, we've had public discussions, about a number of
things, for example switching to Git:

- https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036390.html
- https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036480.html
- https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036486.html
- https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036500.html

And based on these inputs from you the switch was not made even though several
OpenWrt developers wanted to switch.

Also, server outages can happen to anybody:
- https://lists.openwrt.org/pipermail/openwrt-devel/2016-January/038547.html

However, we do not want to point fingers. What we do want is to make a great
community around OpenWrt and to drive innovation - just like it has been done
for more then a decade now. 

There has been a long history - mostly good, sometimes bad - since the project
started from a garage project, to now having a project used by an awesome
amount of users. This can be seen from the constructive discussions in this
list on a daily basis, and in this very thread. Also, the project is used as
the main SDK by many silicon vendors internally, and by vast number of
companies on the embedded market.

We are open for a discussion and would like to keep the OpenWrt's and it's
community interests in the first place. Splitting the project does not make
sense. Do you agree?

>>> We appreciate your effort to have an open discussion about this, 
>>> however the sudden deletion of our widely published openwrt.org email 
>>> addresses somewhat undermines this. We will not respond in kind and we 
>>> will continue to maintain the critical parts of OpenWrt infrastructure 
>>> that we control.
>>
>> Let's be clear on this subject; no commit access was revoked, you still
>> have full read and write access to the entire OpenWrt tree.
>>
>> Email forwarding was temporarily disabled following the LEDE announcement
>> - LEDE's own rules prohibit project based email addresses
> No, they don't. They state that the LEDE project won't provide project
> email addresses. Interpreting that as meaning that we shouldn't be able
> to access our openwrt.org addresses is more than a bit of a stretch.

In any case, due to the events that happened and the fact that the OpenWrt name
is being used in a manner opposite of the projects best interest, we felt that
these actions were needed in order to avoid the further damages to the project.

>> - It's unclear if LEDE still represents OpenWrt
> So? Asking us to not send any further emails about LEDE from our
> openwrt.org addresses should have been enough.

Actually, this was discussed on #lede-adm.

>> My hope is that this whole LEDE vs OpenWrt situation can be resolved.
> I hope so too.

That is good to hear. Bringing the issue to a more public discussion might
speed up resolving them, but it is in everyone's best interest to get them
resolved.

Since so far there has not been a presented reason why the proposals made could
not be incorporated in main OpenWrt as well it still remains unclear what
benefits brings splitting the project. I propose we work together to come up
with a unified solution that all the community will benefit from.

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

[OpenWrt-Devel] [PATCH v2 2/3] [rpcd] file: handle return output of b64_decode

[Luka Perkov]

Solve this compile warning:

file.c:300:16: error: comparison of unsigned expression < 0 is always false 
[-Werror,-Wtautological-compare]
if (data_len < 0)

Signed-off-by: Luka Perkov <l...@openwrt.org>
---

v1 -> v2:

Chage int to ssize_t.

---
 file.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/file.c b/file.c
index 91a55a1..6ddde32 100644
--- a/file.c
+++ b/file.c
@@ -271,7 +271,7 @@ rpc_file_write(struct ubus_context *ctx, struct ubus_object 
*obj,
mode_t prev_mode, mode = 0666;
int fd, rv = 0;
void *data = NULL;
-   size_t data_len = 0;
+   ssize_t data_len = 0;
 
blobmsg_parse(rpc_file_rw_policy, __RPC_F_RW_MAX, tb,
  blob_data(msg), blob_len(msg));
-- 
2.8.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/3] [rpcd] file: handle return output of b64_decode

[Luka Perkov]

Solve this compile warning:

file.c:300:16: error: comparison of unsigned expression < 0 is always false 
[-Werror,-Wtautological-compare]
if (data_len < 0)

Signed-off-by: Luka Perkov <l...@openwrt.org>
---
 file.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/file.c b/file.c
index 91a55a1..6ddde32 100644
--- a/file.c
+++ b/file.c
@@ -271,7 +271,7 @@ rpc_file_write(struct ubus_context *ctx, struct ubus_object 
*obj,
mode_t prev_mode, mode = 0666;
int fd, rv = 0;
void *data = NULL;
-   size_t data_len = 0;
+   int data_len = 0;
 
blobmsg_parse(rpc_file_rw_policy, __RPC_F_RW_MAX, tb,
  blob_data(msg), blob_len(msg));
-- 
2.8.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 3/3] [rpcd] file: add myself in Copyright header

[Luka Perkov]

Signed-off-by: Luka Perkov <l...@openwrt.org>
---
 file.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/file.c b/file.c
index 6ddde32..1c4d8bc 100644
--- a/file.c
+++ b/file.c
@@ -2,6 +2,7 @@
  * rpcd - UBUS RPC server
  *
  *   Copyright (C) 2013-2014 Jo-Philipp Wich <j...@openwrt.org>
+ *   Copyright (C) 2016 Luka Perkov <l...@openwrt.org>
  *
  * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
-- 
2.8.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/3] [rpcd] file: add append write support

[Luka Perkov]

Signed-off-by: Luka Perkov <l...@openwrt.org>
---
 file.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/file.c b/file.c
index d983518..91a55a1 100644
--- a/file.c
+++ b/file.c
@@ -93,6 +93,7 @@ static const struct blobmsg_policy 
rpc_file_rb_policy[__RPC_F_RB_MAX] = {
 enum {
RPC_F_RW_PATH,
RPC_F_RW_DATA,
+   RPC_F_RW_APPEND,
RPC_F_RW_MODE,
RPC_F_RW_BASE64,
__RPC_F_RW_MAX,
@@ -101,6 +102,7 @@ enum {
 static const struct blobmsg_policy rpc_file_rw_policy[__RPC_F_RW_MAX] = {
[RPC_F_RW_PATH]   = { .name = "path",   .type = BLOBMSG_TYPE_STRING },
[RPC_F_RW_DATA]   = { .name = "data",   .type = BLOBMSG_TYPE_STRING },
+   [RPC_F_RW_APPEND] = { .name = "append", .type = BLOBMSG_TYPE_BOOL  },
[RPC_F_RW_MODE]   = { .name = "mode",   .type = BLOBMSG_TYPE_INT32  },
[RPC_F_RW_BASE64] = { .name = "base64", .type = BLOBMSG_TYPE_BOOL   },
 };
@@ -265,6 +267,7 @@ rpc_file_write(struct ubus_context *ctx, struct ubus_object 
*obj,
struct blob_attr *msg)
 {
struct blob_attr *tb[__RPC_F_RW_MAX];
+   int append = O_TRUNC;
mode_t prev_mode, mode = 0666;
int fd, rv = 0;
void *data = NULL;
@@ -279,11 +282,14 @@ rpc_file_write(struct ubus_context *ctx, struct 
ubus_object *obj,
data = blobmsg_data(tb[RPC_F_RW_DATA]);
data_len = blobmsg_data_len(tb[RPC_F_RW_DATA]) - 1;
 
+   if (tb[RPC_F_RW_APPEND] && blobmsg_get_bool(tb[RPC_F_RW_APPEND]))
+   append = O_APPEND;
+
if (tb[RPC_F_RW_MODE])
mode = blobmsg_get_u32(tb[RPC_F_RW_MODE]);
 
prev_mode = umask(0);
-   fd = open(blobmsg_data(tb[RPC_F_RW_PATH]), O_CREAT | O_WRONLY | 
O_TRUNC, mode);
+   fd = open(blobmsg_data(tb[RPC_F_RW_PATH]), O_CREAT | O_WRONLY | append, 
mode);
umask(prev_mode);
if (fd < 0)
return rpc_errno_status();
-- 
2.8.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] alfa-ap120c ordering and indenting

[Luka Perkov]

Hi John,

On Thu, Mar 24, 2016 at 06:47:31AM +0100, John Crispin wrote:
> The patch has inconsistent ordering and indentation, see inline

Your suggestions are appreciated and the changes are pushed.

Luka
 
>   John
> 
> On 23/03/2016 23:31, openwrt-comm...@openwrt.org wrote:
> > Author: luka
> > Date: 2016-03-23 23:31:38 +0100 (Wed, 23 Mar 2016)
> > New Revision: 49082
> > 
> > Added:
> >trunk/target/linux/ar71xx/files/arch/mips/ath79/mach-alfa-ap120c.c
> > Modified:
> >trunk/target/linux/ar71xx/base-files/etc/board.d/02_network
> >trunk/target/linux/ar71xx/base-files/lib/ar71xx.sh
> >trunk/target/linux/ar71xx/config-4.1
> >trunk/target/linux/ar71xx/config-4.4
> >trunk/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
> >trunk/target/linux/ar71xx/files/arch/mips/ath79/Makefile
> >trunk/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h
> >trunk/target/linux/ar71xx/generic/profiles/alfa.mk
> >trunk/target/linux/ar71xx/image/Makefile
> > Log:
> > ar71xx: add support for ap120c
> > 
> > Signed-off-by: Luka Perkov <l...@openwrt.org>
> > 
> > Modified: trunk/target/linux/ar71xx/base-files/etc/board.d/02_network
> > ===
> > --- trunk/target/linux/ar71xx/base-files/etc/board.d/02_network 
> > 2016-03-23 12:52:50 UTC (rev 49081)
> > +++ trunk/target/linux/ar71xx/base-files/etc/board.d/02_network 
> > 2016-03-23 22:31:38 UTC (rev 49082)
> > @@ -320,6 +320,7 @@
> > ucidef_add_switch_attr "switch0" "enable" "false"
> > ;;
> >  
> > +alfa-ap120c |\
> >  all0305 |\
> >  antminer-s1 |\
> >  antminer-s3 |\
> > 
> > Modified: trunk/target/linux/ar71xx/base-files/lib/ar71xx.sh
> > ===
> > --- trunk/target/linux/ar71xx/base-files/lib/ar71xx.sh  2016-03-23 
> > 12:52:50 UTC (rev 49081)
> > +++ trunk/target/linux/ar71xx/base-files/lib/ar71xx.sh  2016-03-23 
> > 22:31:38 UTC (rev 49082)
> > @@ -351,6 +351,9 @@
> > *"ALFA Network AP96")
> > name="alfa-ap96"
> > ;;
> > +   *"ALFA Network AP120C")
> > +   name="alfa-ap120c"
> > +   ;;
> 
> here is is added after 96
> 
> > *"ALFA Network N2/N5")
> > name="alfa-nx"
> > ;;
> > 
> > Modified: trunk/target/linux/ar71xx/config-4.1
> > ===
> > --- trunk/target/linux/ar71xx/config-4.12016-03-23 12:52:50 UTC (rev 
> > 49081)
> > +++ trunk/target/linux/ar71xx/config-4.12016-03-23 22:31:38 UTC (rev 
> > 49082)
> > @@ -29,6 +29,7 @@
> >  CONFIG_ATH79_DEV_SPI=y
> >  CONFIG_ATH79_DEV_USB=y
> >  CONFIG_ATH79_DEV_WMAC=y
> > +CONFIG_ATH79_MACH_ALFA_AP120C=y
> >  CONFIG_ATH79_MACH_ALFA_AP96=y
> 
> here is is added before 96
> 
> >  CONFIG_ATH79_MACH_ALFA_NX=y
> >  CONFIG_ATH79_MACH_ALL0258N=y
> > @@ -72,7 +73,6 @@
> >  CONFIG_ATH79_MACH_DLAN_PRO_1200_AC=y
> >  CONFIG_ATH79_MACH_DLAN_PRO_500_WP=y
> >  CONFIG_ATH79_MACH_DR344=y
> > -CONFIG_ATH79_MACH_GL_DOMINO=y
> >  CONFIG_ATH79_MACH_DRAGINO2=y
> >  CONFIG_ATH79_MACH_EAP300V2=y
> >  CONFIG_ATH79_MACH_EAP7660D=y
> > @@ -85,6 +85,7 @@
> >  CONFIG_ATH79_MACH_F9K1115V2=y
> >  CONFIG_ATH79_MACH_GL_AR150=y
> >  CONFIG_ATH79_MACH_GL_AR300=y
> > +CONFIG_ATH79_MACH_GL_DOMINO=y
> >  CONFIG_ATH79_MACH_GL_INET=y
> >  CONFIG_ATH79_MACH_GS_MINIBOX_V1=y
> >  CONFIG_ATH79_MACH_GS_OOLITE=y
> > 
> > Modified: trunk/target/linux/ar71xx/config-4.4
> > ===
> > --- trunk/target/linux/ar71xx/config-4.42016-03-23 12:52:50 UTC (rev 
> > 49081)
> > +++ trunk/target/linux/ar71xx/config-4.42016-03-23 22:31:38 UTC (rev 
> > 49082)
> > @@ -32,6 +32,7 @@
> >  CONFIG_ATH79_DEV_SPI=y
> >  CONFIG_ATH79_DEV_USB=y
> >  CONFIG_ATH79_DEV_WMAC=y
> > +CONFIG_ATH79_MACH_ALFA_AP120C=y
> >  CONFIG_ATH79_MACH_ALFA_AP96=y
> 
> here is is added before 96
> 
> >  CONFIG_ATH79_MACH_ALFA_NX=y
> >  CONFIG_ATH79_MACH_ALL0258N=y
> > 
> > Modified: trunk/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
> > ===
> > --- trunk/target/linux/ar71xx/files/arch/mi

Re: [OpenWrt-Devel] LXC is broken on Caos Calmer

[Luka Perkov]

Hi Daniel & Antonio,

> On Feb 11, 2016, at 11:08 AM, Daniel Golle  wrote:
> 
> Hi Antonio,
> 
> thanks for trying all that and reporting back your results!
> 
>> On Thu, Feb 11, 2016 at 12:47:50AM +0200, Antonio Aloisio wrote:
>> Hi there!
>> Here is a few findings about LXC templates available on OpenWRT CC.
>> 
>> Just for reference, here below you can see all the templates available on
>> CC and what works and what does not.
> 
> Maybe we should split-up the templates into individual packages, each
> having its own set of dependencies.

I am ok with that. Feel free to send the patch.

In general I would advise to make the container rootfs outside of OpenWrt. 
Making it in OpenWrt leads to unnecessary overhead.

>> /usr/share/lxc/templates/lxc-oracle <-- BAD ARCHITECTURE. NO ARM
>> /usr/share/lxc/templates/lxc-plamo <-- depends on "flock". It may work. I
>> get Failed to download
> 
> flock is available as a package, you should be able to install it.
> 
>> /usr/share/lxc/templates/lxc-busybox <-- creates the containers, but
>> doesn't start (busybox no statically linked)
> 
> Well, that's odd, but there's not much we can do. Maybe report that
> to LXC and let them know not everybody uses glibc...
> 
>> /usr/share/lxc/templates/lxc-fedora <-- fails to
>> download /releases/20/Fedora/armhfp/os
> 
> Also, please report that upstream (check that it wasn't already fixed
> in more recent versions of LXC)
> 
>> /usr/share/lxc/templates/lxc-sshd <--- fails requires ssh-keygen. is it
>> available on openwrt?
> 
> Installing openssh-keygen, openssh-client and openssh-client-utils may
> help...
> 
>> /usr/share/lxc/templates/lxc-ubuntu-cloud <-- no idea what's broken
>> /usr/share/lxc/templates/lxc-openmandriva
>> /usr/share/lxc/templates/lxc-gentoo <-- requires tar. maybe works >220MB.
>> Ran out of disk on /tmp
> 
> Probably temp directory for LXC should be configurable, so it can
> go to /mnt/tmp or somewhere with enough space on a specific system...
> 
>> /usr/share/lxc/templates/lxc-download <-- no idea what's wrong
> 
> 
>> /usr/share/lxc/templates/lxc-archlinux <-- fails require pacman. not
>> available
> 
> I agree it'd be nice to have, I remember that pacstrap was quite
> painful to get working, I've tried that before...
> 
>> /usr/share/lxc/templates/lxc-cirros <-- require tar. works? some problem
>> still with lxc cgroups
> 
> Did you compile OpenWrt from source?
> I'm asking because LXC depends on CONFIG_LXC_KERNEL_OPTIONS and
> CONFIG_LXC_BUSYBOX_OPTIONS to work properly, and I believe this isn't
> enabled in the binary release of CC.

Right.

>> /usr/share/lxc/templates/lxc-debian <-- requires debootstrap. itäs not a
>> openwrt package
>> /usr/share/lxc/templates/lxc-ubuntu <-- requires debootstrap. itäs not a
>> openwrt package
> 
> You can install debootstrap, it is available, I've just updated it to
> the most recent release.
> 
>> /usr/share/lxc/templates/lxc-centos <-- requires yum. fails container
>> creation
> 
> Hm, nobody ever packaged all the foreign-distribution package managers
> for OpenWrt. It's quite a lot of work...
> 
>> /usr/share/lxc/templates/lxc-altlinux <-- requires apt-get. fails container
>> creation
> 
> Why doesn't the template just you debootstrap...?
> 
>> /usr/share/lxc/templates/lxc-alpine <-- requires sha256sum. is it available?
> 
> Try installing coreutils-sha256sum which provides sha256sum
> 
>> /usr/share/lxc/templates/lxc-opensuse <-- requires zipper. not available
> 
> 
> Cheers
> 
> 
> Daniel
> 
>> 
>> Cheers,
>> Antonio
>> 
>> On Wed, Feb 10, 2016 at 10:03 PM, Daniel Golle 
>> wrote:
>> 
>>> Hi Antonio,
>>> 
 On Wed, Feb 10, 2016 at 09:52:25PM +0200, Antonio Aloisio wrote:
 Hi there,
 I have tried to run lxc on openwrt but it looks to me that those packages
 are broken.
>>> 
>>> I'm actively using LXC, however, I use a custom overlayfs method to
>>> create OpenWrt containerers

Yup. We don't have out of the box containers which are widely available. I 
often make OpenWrt containers from .tar rootfs archives.


 root@Honeypot:/home/gnuton# lxc-create -t download -n xx
 Setting up the GPG keyring
 ERROR: Unable to fetch GPG key from keyserver.
 lxc_container: lxccontainer.c: create_run_template: 1102 container
>>> creation
 template for xx failed
>>> 
>>> I manually use debootstrap to setup Debian rootfs and throwing that at
>>> LXC works great. I once went through the Debian template and believe it
>>> would make sense to fix it up to work on OpenWrt, so LXC becomes more
>>> useable. Do you have gnupg installed? If not or if GPG stuff fails for
>>> some reason, you can try to to modify the Debian template to use
>>> debootstrap having the signature checks disabled (not ideal,
>>> obviously).
>>> 
 I have also installed LXC LuCi web GUI and it doesn't work too.
 The GUI would allow me to create a openwrt based conatainer, but the
>>> truth
 is that there is no such 

[OpenWrt-Devel] [PATCH 3/3] [rpcd] file: be consistent with string termination character

[Luka Perkov]

Signed-off-by: Luka Perkov l...@openwrt.org
---
 file.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/file.c b/file.c
index fe1bc39..64e7c28 100644
--- a/file.c
+++ b/file.c
@@ -247,7 +247,7 @@ rpc_file_read(struct ubus_context *ctx, struct ubus_object 
*obj,
}
}
 
-   *(wbuf + len) = 0;
+   *(wbuf + len) = '\0';
blobmsg_add_string_buffer(buf);
 
ubus_send_reply(ctx, req, buf.head);
-- 
2.4.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/3] [rpcd][v2] file: add support for base64

[Luka Perkov]

Hi Felix,

On Mon, May 11, 2015 at 11:36:46AM +0200, Felix Fietkau wrote:
 On 2015-05-11 00:26, Luka Perkov wrote:
  Signed-off-by: Luka Perkov l...@openwrt.org
  ---
  = changes in v2:
  
  Use new libubox base64 provided API.
  
   file.c | 118 
  +++--
   1 file changed, 107 insertions(+), 11 deletions(-)
  
  diff --git a/file.c b/file.c
  index 9c1b301..c3671bb 100644
  --- a/file.c
  +++ b/file.c
  @@ -182,7 +206,17 @@ rpc_file_read(struct ubus_context *ctx, struct 
  ubus_object *obj,
   
  blob_buf_init(buf, 0);
   
  -   wbuf = blobmsg_alloc_string_buffer(buf, data, s.st_size + 1);
  +   if (tb[RPC_F_RB_BASE64])
  +   base64 = blobmsg_get_bool(tb[RPC_F_RB_BASE64]);
  +
  +   if (base64)
  +   {
  +   wbuf = blobmsg_alloc_string_buffer(buf, data, 
  B64_ENCODE_LEN(s.st_size));
  +   }
  +   else
  +   {
  +   wbuf = blobmsg_alloc_string_buffer(buf, data, s.st_size + 1);
  +   }
 How about using the 'len' variable to avoid duplicating most of the code
 here.

Can you be more specific here please? I don't see how by using 'len' we
can reduce more code here.

 You can also get rid of unnecessary {} lines.

I have fixed this and all other comments below. New series will follow
shortly.

Luka


 
  @@ -196,14 +230,35 @@ rpc_file_read(struct ubus_context *ctx, struct 
  ubus_object *obj,
  goto out;
  }
   
  +   if (base64)
  +   {
  +   uint8_t *data = calloc(B64_ENCODE_LEN(len), sizeof(uint8_t));
  +   if (!data)
  +   {
  +   rv = UBUS_STATUS_UNKNOWN_ERROR;
  +   goto out;
  +   }
 You can reduce allocation/copy size if you copy wbuf to a temporary
 buffer and then use it as output for b64_encode.
 
  +   len = b64_encode(wbuf, len, data, B64_ENCODE_LEN(len));
  +   if (len  0)
  +   {
  +   free(data);
  +   rv = UBUS_STATUS_UNKNOWN_ERROR;
  +   goto out;
  +   }
  +
  +   memcpy(wbuf, data, len);
  +   free(data);
  +   }
  +
  *(wbuf + len) = 0;
  blobmsg_add_string_buffer(buf);
   
  ubus_send_reply(ctx, req, buf.head);
  -   blob_buf_free(buf);
  rv = UBUS_STATUS_OK;
   
   out:
  +   blob_buf_free(buf);
  close(fd);
  return rv;
   }
  @@ -222,18 +282,54 @@ rpc_file_write(struct ubus_context *ctx, struct 
  ubus_object *obj,
  if (!tb[RPC_F_RW_PATH] || !tb[RPC_F_RW_DATA])
  return UBUS_STATUS_INVALID_ARGUMENT;
   
  +   data = blobmsg_data(tb[RPC_F_RW_DATA]);
  +   data_len = blobmsg_data_len(tb[RPC_F_RW_DATA]) - 1;
  +
  if ((fd = open(blobmsg_data(tb[RPC_F_RW_PATH]), O_CREAT | O_TRUNC | 
  O_WRONLY, 0666))  0)
  return rpc_errno_status();
   
  -   if (write(fd, blobmsg_data(tb[RPC_F_RW_DATA]), 
  blobmsg_data_len(tb[RPC_F_RW_DATA]))  0)
  -   return rpc_errno_status();
  +   if (tb[RPC_F_RW_BASE64])
  +   base64 = blobmsg_get_bool(tb[RPC_F_RW_BASE64]);
  +
  +   if (base64)
  +   {
  +   rbuf_len = B64_DECODE_LEN(data_len);
  +   rbuf = calloc(rbuf_len, sizeof(uint8_t));
  +   if (!rbuf)
  +   {
  +   rv = UBUS_STATUS_UNKNOWN_ERROR;
  +   goto out;
  +   }
  +
  +   rbuf_len = b64_decode(data, rbuf, rbuf_len);
  +   if (rbuf_len  0)
  +   {
  +   rv = UBUS_STATUS_UNKNOWN_ERROR;
  +   goto out;
  +   }
  +   }
  +   else
  +   {
  +   rbuf = data;
  +   rbuf_len = data_len;
  +   }
 It is safe to overwrite the data area in this function, as long as you
 don't overstep attribute bounds. This means you can reuse the input
 buffer as output buffer for b64_decode and get rid of the temporary
 allocation.
 
 - Felix
 ___
 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

[OpenWrt-Devel] [PATCH 1/3] file: add support for base64

[Luka Perkov]

Signed-off-by: Luka Perkov l...@openwrt.org
---
= changes in v2:

Use new libubox base64 provided API.

= changes in v3:

* optimize base64 related code in read and write callback

 file.c | 90 ++
 1 file changed, 79 insertions(+), 11 deletions(-)

diff --git a/file.c b/file.c
index 9c1b301..d39dccb 100644
--- a/file.c
+++ b/file.c
@@ -29,6 +29,7 @@
 #include libubox/blobmsg.h
 #include libubox/md5.h
 #include libubox/ustream.h
+#include libubox/utils.h
 
 #include rpcd/plugin.h
 
@@ -79,14 +80,27 @@ static const struct blobmsg_policy 
rpc_file_r_policy[__RPC_F_R_MAX] = {
 };
 
 enum {
+   RPC_F_RB_PATH,
+   RPC_F_RB_BASE64,
+   __RPC_F_RB_MAX,
+};
+
+static const struct blobmsg_policy rpc_file_rb_policy[__RPC_F_RB_MAX] = {
+   [RPC_F_RB_PATH]   = { .name = path,   .type = BLOBMSG_TYPE_STRING },
+   [RPC_F_RB_BASE64] = { .name = base64, .type = BLOBMSG_TYPE_BOOL   },
+};
+
+enum {
RPC_F_RW_PATH,
RPC_F_RW_DATA,
+   RPC_F_RW_BASE64,
__RPC_F_RW_MAX,
 };
 
 static const struct blobmsg_policy rpc_file_rw_policy[__RPC_F_RW_MAX] = {
-   [RPC_F_RW_PATH] = { .name = path, .type = BLOBMSG_TYPE_STRING },
-   [RPC_F_RW_DATA] = { .name = data, .type = BLOBMSG_TYPE_STRING },
+   [RPC_F_RW_PATH]   = { .name = path,   .type = BLOBMSG_TYPE_STRING },
+   [RPC_F_RW_DATA]   = { .name = data,   .type = BLOBMSG_TYPE_STRING },
+   [RPC_F_RW_BASE64] = { .name = base64, .type = BLOBMSG_TYPE_BOOL   },
 };
 
 enum {
@@ -162,12 +176,22 @@ rpc_file_read(struct ubus_context *ctx, struct 
ubus_object *obj,
   struct ubus_request_data *req, const char *method,
   struct blob_attr *msg)
 {
-   int fd, rv, len;
+   static struct blob_attr *tb[__RPC_F_RB_MAX];
+   bool base64 = false;
+   int fd, rv;
+   ssize_t len;
char *path;
struct stat s;
char *wbuf;
 
-   if (!rpc_check_path(msg, path, s))
+   blobmsg_parse(rpc_file_rb_policy, __RPC_F_RB_MAX, tb, blob_data(msg), 
blob_len(msg));
+
+   if (!tb[RPC_F_RB_PATH])
+   return rpc_errno_status();
+
+   path = blobmsg_data(tb[RPC_F_RB_PATH]);
+
+   if (stat(path, s))
return rpc_errno_status();
 
if (s.st_size = RPC_FILE_MAX_SIZE)
@@ -182,7 +206,13 @@ rpc_file_read(struct ubus_context *ctx, struct ubus_object 
*obj,
 
blob_buf_init(buf, 0);
 
-   wbuf = blobmsg_alloc_string_buffer(buf, data, s.st_size + 1);
+   if (tb[RPC_F_RB_BASE64])
+   base64 = blobmsg_get_bool(tb[RPC_F_RB_BASE64]);
+
+   if (base64)
+   wbuf = blobmsg_alloc_string_buffer(buf, data, 
B64_ENCODE_LEN(s.st_size));
+   else
+   wbuf = blobmsg_alloc_string_buffer(buf, data, s.st_size + 1);
 
if (!wbuf)
{
@@ -196,14 +226,33 @@ rpc_file_read(struct ubus_context *ctx, struct 
ubus_object *obj,
goto out;
}
 
+   if (base64)
+   {
+   uint8_t *data = calloc(len, sizeof(uint8_t));
+   if (!data)
+   {
+   rv = UBUS_STATUS_UNKNOWN_ERROR;
+   goto out;
+   }
+   memcpy(data, wbuf, len);
+
+   len = b64_encode(data, len, wbuf, B64_ENCODE_LEN(len));
+   free(data);
+   if (len  0)
+   {
+   rv = UBUS_STATUS_UNKNOWN_ERROR;
+   goto out;
+   }
+   }
+
*(wbuf + len) = 0;
blobmsg_add_string_buffer(buf);
 
ubus_send_reply(ctx, req, buf.head);
-   blob_buf_free(buf);
rv = UBUS_STATUS_OK;
 
 out:
+   blob_buf_free(buf);
close(fd);
return rv;
 }
@@ -213,8 +262,10 @@ rpc_file_write(struct ubus_context *ctx, struct 
ubus_object *obj,
struct ubus_request_data *req, const char *method,
struct blob_attr *msg)
 {
-   int fd;
struct blob_attr *tb[__RPC_F_RW_MAX];
+   int fd, rv = 0;
+   void *data = NULL;
+   size_t data_len = 0;
 
blobmsg_parse(rpc_file_rw_policy, __RPC_F_RW_MAX, tb,
  blob_data(msg), blob_len(msg));
@@ -222,18 +273,35 @@ rpc_file_write(struct ubus_context *ctx, struct 
ubus_object *obj,
if (!tb[RPC_F_RW_PATH] || !tb[RPC_F_RW_DATA])
return UBUS_STATUS_INVALID_ARGUMENT;
 
+   data = blobmsg_data(tb[RPC_F_RW_DATA]);
+   data_len = blobmsg_data_len(tb[RPC_F_RW_DATA]) - 1;
+
if ((fd = open(blobmsg_data(tb[RPC_F_RW_PATH]), O_CREAT | O_TRUNC | 
O_WRONLY, 0666))  0)
return rpc_errno_status();
 
-   if (write(fd, blobmsg_data(tb[RPC_F_RW_DATA]), 
blobmsg_data_len(tb[RPC_F_RW_DATA]))  0)
-   return rpc_errno_status();
+   if (tb[RPC_F_RW_BASE64]  blobmsg_get_bool(tb[RPC_F_RW_BASE64]))
+   {
+   data_len = b64_decode(data, data, data_len

[OpenWrt-Devel] [PATCH 2/3] file: add support for setting mode when writing files

[Luka Perkov]

Signed-off-by: Luka Perkov l...@openwrt.org
---
= changes in v2:

Return umask() to previous value after temporary changing it.

 file.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/file.c b/file.c
index d39dccb..fe1bc39 100644
--- a/file.c
+++ b/file.c
@@ -93,6 +93,7 @@ static const struct blobmsg_policy 
rpc_file_rb_policy[__RPC_F_RB_MAX] = {
 enum {
RPC_F_RW_PATH,
RPC_F_RW_DATA,
+   RPC_F_RW_MODE,
RPC_F_RW_BASE64,
__RPC_F_RW_MAX,
 };
@@ -100,6 +101,7 @@ enum {
 static const struct blobmsg_policy rpc_file_rw_policy[__RPC_F_RW_MAX] = {
[RPC_F_RW_PATH]   = { .name = path,   .type = BLOBMSG_TYPE_STRING },
[RPC_F_RW_DATA]   = { .name = data,   .type = BLOBMSG_TYPE_STRING },
+   [RPC_F_RW_MODE]   = { .name = mode,   .type = BLOBMSG_TYPE_INT32  },
[RPC_F_RW_BASE64] = { .name = base64, .type = BLOBMSG_TYPE_BOOL   },
 };
 
@@ -263,6 +265,7 @@ rpc_file_write(struct ubus_context *ctx, struct ubus_object 
*obj,
struct blob_attr *msg)
 {
struct blob_attr *tb[__RPC_F_RW_MAX];
+   mode_t prev_mode, mode = 0666;
int fd, rv = 0;
void *data = NULL;
size_t data_len = 0;
@@ -276,7 +279,13 @@ rpc_file_write(struct ubus_context *ctx, struct 
ubus_object *obj,
data = blobmsg_data(tb[RPC_F_RW_DATA]);
data_len = blobmsg_data_len(tb[RPC_F_RW_DATA]) - 1;
 
-   if ((fd = open(blobmsg_data(tb[RPC_F_RW_PATH]), O_CREAT | O_TRUNC | 
O_WRONLY, 0666))  0)
+   if (tb[RPC_F_RW_MODE])
+   mode = blobmsg_get_u32(tb[RPC_F_RW_MODE]);
+
+   prev_mode = umask(0);
+   fd = open(blobmsg_data(tb[RPC_F_RW_PATH]), O_CREAT | O_WRONLY | 
O_TRUNC, mode);
+   umask(prev_mode);
+   if (fd  0)
return rpc_errno_status();
 
if (tb[RPC_F_RW_BASE64]  blobmsg_get_bool(tb[RPC_F_RW_BASE64]))
-- 
2.4.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/3][rpcd][v4] file: add support for base64

[Luka Perkov]

Signed-off-by: Luka Perkov l...@openwrt.org
---
= changes in v2:

Use new libubox base64 provided API.

= changes in v3:

* optimize base64 related code in read and write callback

= changes in v4:

* tweak if block in file read function

 file.c | 90 ++
 1 file changed, 79 insertions(+), 11 deletions(-)

diff --git a/file.c b/file.c
index 9c1b301..02fb72e 100644
--- a/file.c
+++ b/file.c
@@ -29,6 +29,7 @@
 #include libubox/blobmsg.h
 #include libubox/md5.h
 #include libubox/ustream.h
+#include libubox/utils.h
 
 #include rpcd/plugin.h
 
@@ -79,14 +80,27 @@ static const struct blobmsg_policy 
rpc_file_r_policy[__RPC_F_R_MAX] = {
 };
 
 enum {
+   RPC_F_RB_PATH,
+   RPC_F_RB_BASE64,
+   __RPC_F_RB_MAX,
+};
+
+static const struct blobmsg_policy rpc_file_rb_policy[__RPC_F_RB_MAX] = {
+   [RPC_F_RB_PATH]   = { .name = path,   .type = BLOBMSG_TYPE_STRING },
+   [RPC_F_RB_BASE64] = { .name = base64, .type = BLOBMSG_TYPE_BOOL   },
+};
+
+enum {
RPC_F_RW_PATH,
RPC_F_RW_DATA,
+   RPC_F_RW_BASE64,
__RPC_F_RW_MAX,
 };
 
 static const struct blobmsg_policy rpc_file_rw_policy[__RPC_F_RW_MAX] = {
-   [RPC_F_RW_PATH] = { .name = path, .type = BLOBMSG_TYPE_STRING },
-   [RPC_F_RW_DATA] = { .name = data, .type = BLOBMSG_TYPE_STRING },
+   [RPC_F_RW_PATH]   = { .name = path,   .type = BLOBMSG_TYPE_STRING },
+   [RPC_F_RW_DATA]   = { .name = data,   .type = BLOBMSG_TYPE_STRING },
+   [RPC_F_RW_BASE64] = { .name = base64, .type = BLOBMSG_TYPE_BOOL   },
 };
 
 enum {
@@ -162,12 +176,22 @@ rpc_file_read(struct ubus_context *ctx, struct 
ubus_object *obj,
   struct ubus_request_data *req, const char *method,
   struct blob_attr *msg)
 {
-   int fd, rv, len;
+   static struct blob_attr *tb[__RPC_F_RB_MAX];
+   bool base64 = false;
+   int fd, rv;
+   ssize_t len;
char *path;
struct stat s;
char *wbuf;
 
-   if (!rpc_check_path(msg, path, s))
+   blobmsg_parse(rpc_file_rb_policy, __RPC_F_RB_MAX, tb, blob_data(msg), 
blob_len(msg));
+
+   if (!tb[RPC_F_RB_PATH])
+   return rpc_errno_status();
+
+   path = blobmsg_data(tb[RPC_F_RB_PATH]);
+
+   if (stat(path, s))
return rpc_errno_status();
 
if (s.st_size = RPC_FILE_MAX_SIZE)
@@ -182,7 +206,13 @@ rpc_file_read(struct ubus_context *ctx, struct ubus_object 
*obj,
 
blob_buf_init(buf, 0);
 
-   wbuf = blobmsg_alloc_string_buffer(buf, data, s.st_size + 1);
+   if (tb[RPC_F_RB_BASE64])
+   base64 = blobmsg_get_bool(tb[RPC_F_RB_BASE64]);
+
+   len = s.st_size + 1;
+   if (base64)
+   len = B64_ENCODE_LEN(s.st_size);
+   wbuf = blobmsg_alloc_string_buffer(buf, data, len);
 
if (!wbuf)
{
@@ -196,14 +226,33 @@ rpc_file_read(struct ubus_context *ctx, struct 
ubus_object *obj,
goto out;
}
 
+   if (base64)
+   {
+   uint8_t *data = calloc(len, sizeof(uint8_t));
+   if (!data)
+   {
+   rv = UBUS_STATUS_UNKNOWN_ERROR;
+   goto out;
+   }
+   memcpy(data, wbuf, len);
+
+   len = b64_encode(data, len, wbuf, B64_ENCODE_LEN(len));
+   free(data);
+   if (len  0)
+   {
+   rv = UBUS_STATUS_UNKNOWN_ERROR;
+   goto out;
+   }
+   }
+
*(wbuf + len) = 0;
blobmsg_add_string_buffer(buf);
 
ubus_send_reply(ctx, req, buf.head);
-   blob_buf_free(buf);
rv = UBUS_STATUS_OK;
 
 out:
+   blob_buf_free(buf);
close(fd);
return rv;
 }
@@ -213,8 +262,10 @@ rpc_file_write(struct ubus_context *ctx, struct 
ubus_object *obj,
struct ubus_request_data *req, const char *method,
struct blob_attr *msg)
 {
-   int fd;
struct blob_attr *tb[__RPC_F_RW_MAX];
+   int fd, rv = 0;
+   void *data = NULL;
+   size_t data_len = 0;
 
blobmsg_parse(rpc_file_rw_policy, __RPC_F_RW_MAX, tb,
  blob_data(msg), blob_len(msg));
@@ -222,18 +273,35 @@ rpc_file_write(struct ubus_context *ctx, struct 
ubus_object *obj,
if (!tb[RPC_F_RW_PATH] || !tb[RPC_F_RW_DATA])
return UBUS_STATUS_INVALID_ARGUMENT;
 
+   data = blobmsg_data(tb[RPC_F_RW_DATA]);
+   data_len = blobmsg_data_len(tb[RPC_F_RW_DATA]) - 1;
+
if ((fd = open(blobmsg_data(tb[RPC_F_RW_PATH]), O_CREAT | O_TRUNC | 
O_WRONLY, 0666))  0)
return rpc_errno_status();
 
-   if (write(fd, blobmsg_data(tb[RPC_F_RW_DATA]), 
blobmsg_data_len(tb[RPC_F_RW_DATA]))  0)
-   return rpc_errno_status();
+   if (tb[RPC_F_RW_BASE64]  blobmsg_get_bool(tb[RPC_F_RW_BASE64]))
+   {
+   data_len = b64_decode(data, data, data_len

[OpenWrt-Devel] [PATCH 3/3] [rpcd] file: be consistent with string termination character

[Luka Perkov]

Signed-off-by: Luka Perkov l...@openwrt.org
---
 file.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/file.c b/file.c
index 86783e0..4c00ae2 100644
--- a/file.c
+++ b/file.c
@@ -253,7 +253,7 @@ rpc_file_read(struct ubus_context *ctx, struct ubus_object 
*obj,
free(data);
}
 
-   *(wbuf + len) = 0;
+   *(wbuf + len) = '\0';
blobmsg_add_string_buffer(buf);
 
ubus_send_reply(ctx, req, buf.head);
-- 
2.4.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/3] [rpcd][v2] file: add support for base64

[Luka Perkov]

Signed-off-by: Luka Perkov l...@openwrt.org
---
= changes in v2:

Use new libubox base64 provided API.

 file.c | 118 +++--
 1 file changed, 107 insertions(+), 11 deletions(-)

diff --git a/file.c b/file.c
index 9c1b301..c3671bb 100644
--- a/file.c
+++ b/file.c
@@ -29,6 +29,7 @@
 #include libubox/blobmsg.h
 #include libubox/md5.h
 #include libubox/ustream.h
+#include libubox/utils.h
 
 #include rpcd/plugin.h
 
@@ -79,14 +80,27 @@ static const struct blobmsg_policy 
rpc_file_r_policy[__RPC_F_R_MAX] = {
 };
 
 enum {
+   RPC_F_RB_PATH,
+   RPC_F_RB_BASE64,
+   __RPC_F_RB_MAX,
+};
+
+static const struct blobmsg_policy rpc_file_rb_policy[__RPC_F_RB_MAX] = {
+   [RPC_F_RB_PATH]   = { .name = path,   .type = BLOBMSG_TYPE_STRING },
+   [RPC_F_RB_BASE64] = { .name = base64, .type = BLOBMSG_TYPE_BOOL   },
+};
+
+enum {
RPC_F_RW_PATH,
RPC_F_RW_DATA,
+   RPC_F_RW_BASE64,
__RPC_F_RW_MAX,
 };
 
 static const struct blobmsg_policy rpc_file_rw_policy[__RPC_F_RW_MAX] = {
-   [RPC_F_RW_PATH] = { .name = path, .type = BLOBMSG_TYPE_STRING },
-   [RPC_F_RW_DATA] = { .name = data, .type = BLOBMSG_TYPE_STRING },
+   [RPC_F_RW_PATH]   = { .name = path,   .type = BLOBMSG_TYPE_STRING },
+   [RPC_F_RW_DATA]   = { .name = data,   .type = BLOBMSG_TYPE_STRING },
+   [RPC_F_RW_BASE64] = { .name = base64, .type = BLOBMSG_TYPE_BOOL   },
 };
 
 enum {
@@ -162,12 +176,22 @@ rpc_file_read(struct ubus_context *ctx, struct 
ubus_object *obj,
   struct ubus_request_data *req, const char *method,
   struct blob_attr *msg)
 {
-   int fd, rv, len;
+   static struct blob_attr *tb[__RPC_F_RB_MAX];
+   bool base64 = false;
+   int fd, rv;
+   ssize_t len;
char *path;
struct stat s;
char *wbuf;
 
-   if (!rpc_check_path(msg, path, s))
+   blobmsg_parse(rpc_file_rb_policy, __RPC_F_RB_MAX, tb, blob_data(msg), 
blob_len(msg));
+
+   if (!tb[RPC_F_RB_PATH])
+   return rpc_errno_status();
+
+   path = blobmsg_data(tb[RPC_F_RB_PATH]);
+
+   if (stat(path, s))
return rpc_errno_status();
 
if (s.st_size = RPC_FILE_MAX_SIZE)
@@ -182,7 +206,17 @@ rpc_file_read(struct ubus_context *ctx, struct ubus_object 
*obj,
 
blob_buf_init(buf, 0);
 
-   wbuf = blobmsg_alloc_string_buffer(buf, data, s.st_size + 1);
+   if (tb[RPC_F_RB_BASE64])
+   base64 = blobmsg_get_bool(tb[RPC_F_RB_BASE64]);
+
+   if (base64)
+   {
+   wbuf = blobmsg_alloc_string_buffer(buf, data, 
B64_ENCODE_LEN(s.st_size));
+   }
+   else
+   {
+   wbuf = blobmsg_alloc_string_buffer(buf, data, s.st_size + 1);
+   }
 
if (!wbuf)
{
@@ -196,14 +230,35 @@ rpc_file_read(struct ubus_context *ctx, struct 
ubus_object *obj,
goto out;
}
 
+   if (base64)
+   {
+   uint8_t *data = calloc(B64_ENCODE_LEN(len), sizeof(uint8_t));
+   if (!data)
+   {
+   rv = UBUS_STATUS_UNKNOWN_ERROR;
+   goto out;
+   }
+
+   len = b64_encode(wbuf, len, data, B64_ENCODE_LEN(len));
+   if (len  0)
+   {
+   free(data);
+   rv = UBUS_STATUS_UNKNOWN_ERROR;
+   goto out;
+   }
+
+   memcpy(wbuf, data, len);
+   free(data);
+   }
+
*(wbuf + len) = 0;
blobmsg_add_string_buffer(buf);
 
ubus_send_reply(ctx, req, buf.head);
-   blob_buf_free(buf);
rv = UBUS_STATUS_OK;
 
 out:
+   blob_buf_free(buf);
close(fd);
return rv;
 }
@@ -213,8 +268,13 @@ rpc_file_write(struct ubus_context *ctx, struct 
ubus_object *obj,
struct ubus_request_data *req, const char *method,
struct blob_attr *msg)
 {
-   int fd;
struct blob_attr *tb[__RPC_F_RW_MAX];
+   bool base64 = false;
+   int fd, rv = 0;
+   void *data = NULL;
+   size_t data_len = 0;
+   void *rbuf = NULL;
+   ssize_t rbuf_len = 0;
 
blobmsg_parse(rpc_file_rw_policy, __RPC_F_RW_MAX, tb,
  blob_data(msg), blob_len(msg));
@@ -222,18 +282,54 @@ rpc_file_write(struct ubus_context *ctx, struct 
ubus_object *obj,
if (!tb[RPC_F_RW_PATH] || !tb[RPC_F_RW_DATA])
return UBUS_STATUS_INVALID_ARGUMENT;
 
+   data = blobmsg_data(tb[RPC_F_RW_DATA]);
+   data_len = blobmsg_data_len(tb[RPC_F_RW_DATA]) - 1;
+
if ((fd = open(blobmsg_data(tb[RPC_F_RW_PATH]), O_CREAT | O_TRUNC | 
O_WRONLY, 0666))  0)
return rpc_errno_status();
 
-   if (write(fd, blobmsg_data(tb[RPC_F_RW_DATA]), 
blobmsg_data_len(tb[RPC_F_RW_DATA]))  0)
-   return rpc_errno_status();
+   if (tb[RPC_F_RW_BASE64])
+   base64

[OpenWrt-Devel] [PATCH 1/4] [ubox] log: remove unused callbacks

[Luka Perkov]

Signed-off-by: Luka Perkov l...@openwrt.org
---
 log/logd.c| 6 --
 log/logread.c | 5 -
 2 files changed, 11 deletions(-)

diff --git a/log/logd.c b/log/logd.c
index 8cebeb8..4a7a746 100644
--- a/log/logd.c
+++ b/log/logd.c
@@ -55,11 +55,6 @@ client_close(struct ustream *s)
free(cl);
 }
 
-static void
-client_notify_write(struct ustream *s, int bytes)
-{
-}
-
 static void client_notify_state(struct ustream *s)
 {
client_close(s);
@@ -88,7 +83,6 @@ read_log(struct ubus_context *ctx, struct ubus_object *obj,
}
ubus_request_set_fd(ctx, req, fds[0]);
cl = calloc(1, sizeof(*cl));
-   cl-s.stream.notify_write = client_notify_write;
cl-s.stream.notify_state = client_notify_state;
cl-fd = fds[1];
ustream_fd_init(cl-s, cl-fd);
diff --git a/log/logread.c b/log/logread.c
index 94b96db..6255408 100644
--- a/log/logread.c
+++ b/log/logread.c
@@ -223,10 +223,6 @@ static void logread_fd_cb(struct ubus_request *req, int fd)
ustream_fd_init(test_fd, fd);
 }
 
-static void logread_complete_cb(struct ubus_request *req, int ret)
-{
-}
-
 int main(int argc, char **argv)
 {
static struct ubus_request req;
@@ -334,7 +330,6 @@ int main(int argc, char **argv)
 
ubus_invoke_async(ctx, id, read, b.head, req);
req.fd_cb = logread_fd_cb;
-   req.complete_cb = logread_complete_cb;
ubus_complete_request_async(ctx, req);
 
uloop_run();
-- 
2.3.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/4] [ubox] log: fix whitespaces

[Luka Perkov]

Signed-off-by: Luka Perkov l...@openwrt.org
---
 log/syslog.c | 2 +-
 log/syslog.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/log/syslog.c b/log/syslog.c
index 4cabb43..f75fed9 100644
--- a/log/syslog.c
+++ b/log/syslog.c
@@ -203,7 +203,7 @@ syslog_open(void)
int fd;
 
unlink(log_dev);
-   fd = usock(USOCK_UNIX | USOCK_UDP |  USOCK_SERVER | USOCK_NONBLOCK, 
log_dev, NULL);
+   fd = usock(USOCK_UNIX | USOCK_UDP | USOCK_SERVER | USOCK_NONBLOCK, 
log_dev, NULL);
if (fd  0) {
fprintf(stderr,Failed to open %s\n, log_dev);
return -1;
diff --git a/log/syslog.h b/log/syslog.h
index b682ced..81a039f 100644
--- a/log/syslog.h
+++ b/log/syslog.h
@@ -26,7 +26,7 @@ struct log_head {
unsigned int id;
int priority;
int source;
-struct timespec ts;
+   struct timespec ts;
char data[];
 };
 
-- 
2.3.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 3/4] [ubox] log: make valgrind less complain by freeing allocated memory

[Luka Perkov]

Signed-off-by: Luka Perkov l...@openwrt.org
---
 log/logd.c   | 5 -
 log/syslog.c | 1 +
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/log/logd.c b/log/logd.c
index 4a7a746..a4335ea 100644
--- a/log/logd.c
+++ b/log/logd.c
@@ -70,6 +70,7 @@ read_log(struct ubus_context *ctx, struct ubus_object *obj,
struct log_head *l;
int count = 0;
int fds[2];
+   int ret;
 
if (msg) {
blobmsg_parse(read_policy, 1, tb, blob_data(msg), 
blob_len(msg));
@@ -96,7 +97,9 @@ read_log(struct ubus_context *ctx, struct ubus_object *obj,
blobmsg_add_u32(b, source, l-source);
blobmsg_add_u64(b, time, l-ts.tv_sec * 1000LL);
l = log_list(count, l);
-   if (ustream_write(cl-s.stream, (void *) b.head, 
blob_len(b.head) + sizeof(struct blob_attr), false) = 0)
+   ret = ustream_write(cl-s.stream, (void *) b.head, 
blob_len(b.head) + sizeof(struct blob_attr), false);
+   blob_buf_free(b);
+   if (ret  0)
break;
}
return 0;
diff --git a/log/syslog.c b/log/syslog.c
index f75fed9..a596b48 100644
--- a/log/syslog.c
+++ b/log/syslog.c
@@ -299,4 +299,5 @@ log_shutdown(void)
ustream_free(klog.stream);
close(slog.fd.fd);
close(klog.fd.fd);
+   free(log);
 }
-- 
2.3.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 4/4] [ubox] logd: optimize notify function

[Luka Perkov]

No need to construct every time the same blob_buf for each client in the list.

Signed-off-by: Luka Perkov l...@openwrt.org
---
 log/logd.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/log/logd.c b/log/logd.c
index a4335ea..27d3cac 100644
--- a/log/logd.c
+++ b/log/logd.c
@@ -147,15 +147,17 @@ ubus_notify_log(struct log_head *l)
if (list_empty(clients))
return;
 
-   list_for_each_entry(c, clients, list) {
-   blob_buf_init(b, 0);
-   blobmsg_add_string(b, msg, l-data);
-   blobmsg_add_u32(b, id, l-id);
-   blobmsg_add_u32(b, priority, l-priority);
-   blobmsg_add_u32(b, source, l-source);
-   blobmsg_add_u64(b, time, (((__u64) l-ts.tv_sec) * 1000) + 
(l-ts.tv_nsec / 100));
+   blob_buf_init(b, 0);
+   blobmsg_add_string(b, msg, l-data);
+   blobmsg_add_u32(b, id, l-id);
+   blobmsg_add_u32(b, priority, l-priority);
+   blobmsg_add_u32(b, source, l-source);
+   blobmsg_add_u64(b, time, (((__u64) l-ts.tv_sec) * 1000) + 
(l-ts.tv_nsec / 100));
+
+   list_for_each_entry(c, clients, list)
ustream_write(c-s.stream, (void *) b.head, blob_len(b.head) + 
sizeof(struct blob_attr), false);
-   }
+
+   blob_buf_free(b);
 }
 
 static void
-- 
2.3.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] [libubox][v5] b64: add base64 support

[Luka Perkov]

The base code has been taken from zstream project which was
written by Steven Barth.

Signed-off-by: Luka Perkov l...@openwrt.org
CC: Steven Barth ste...@midlink.org
---
= changes in v2:

Use new API:

size_t b64decode(void **out, const char *in, size_t len);
size_t b64encode(char **out, const void *in, size_t len);

= changes in v3:

Use new API:

static inline int b64_decode_size(const void *in, size_t len);
static inline int b64_encode_size(size_t len);

size_t b64decode(void *out, const void *in, size_t len);
size_t b64encode(void *out, const void *in, size_t len);

In this set a few corner cases of invalid writes in b64decode() were fixed.
Furthermore, b64decode() works fine when in == out.

= changes in v4:

Use new API:

static inline int b64_decode_size(size_t len)
static inline int b64_encode_size(size_t len)

size_t b64decode(void *out, const void *in, size_t len);
size_t b64encode(void *out, const void *in, size_t len);

Add NULL terminating buffer in make changes reported by Jonas, John and Felix.

= changes in v5:

Use new API:

static inline int b64_decode_size(size_t len)
static inline int b64_encode_size(size_t len)

int b64decode(void *out, const void *in, size_t len);
int b64encode(void *out, const void *in, size_t len);

And do not use b64_encode_size() in b64encode().
---
 CMakeLists.txt |   2 +-
 b64.c  | 116 +
 b64.h  |  53 ++
 3 files changed, 170 insertions(+), 1 deletion(-)
 create mode 100644 b64.c
 create mode 100644 b64.h

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 58381da..77f4842 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -14,7 +14,7 @@ IF(JSONC_FOUND)
   INCLUDE_DIRECTORIES(${JSONC_INCLUDE_DIRS})
 ENDIF()
 
-SET(SOURCES avl.c avl-cmp.c blob.c blobmsg.c uloop.c usock.c ustream.c 
ustream-fd.c vlist.c utils.c safe_list.c runqueue.c md5.c kvlist.c ulog.c)
+SET(SOURCES avl.c avl-cmp.c blob.c blobmsg.c uloop.c usock.c ustream.c 
ustream-fd.c vlist.c utils.c safe_list.c runqueue.c md5.c kvlist.c ulog.c b64.c)
 
 ADD_LIBRARY(ubox SHARED ${SOURCES})
 ADD_LIBRARY(ubox-static STATIC ${SOURCES})
diff --git a/b64.c b/b64.c
new file mode 100644
index 000..ac8a805
--- /dev/null
+++ b/b64.c
@@ -0,0 +1,116 @@
+/*
+ * Copyright (C) 2011 Steven Barth ste...@midlink.org
+ * Copyright (C) 2015 Luka Perkov l...@openwrt.org
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include stdint.h
+#include stdlib.h
+
+#include b64.h
+
+static const uint8_t b64decode_tbl[] = {
+   0x3e, 0xff, 0xff, 0xff, 0x3f, 0x34, 0x35, 0x36,
+   0x37, 0x38, 0x39, 0x3a, 0x3b, 0x3c, 0x3d, 0xff,
+   0xff, 0xff, 0x00, 0xff, 0xff, 0xff, 0x00, 0x01,
+   0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09,
+   0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11,
+   0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19,
+   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x1a, 0x1b,
+   0x1c, 0x1d, 0x1e, 0x1f, 0x20, 0x21, 0x22, 0x23,
+   0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2a, 0x2b,
+   0x2c, 0x2d, 0x2e, 0x2f, 0x30, 0x31, 0x32, 0x33
+};
+
+int b64decode(void *out, const void *in, size_t len)
+{
+   uint8_t *o = (uint8_t *) out;
+   const uint8_t *data = (const uint8_t *) in;
+   size_t lenout, i, j;
+   uint32_t cv = 0;
+
+   lenout = b64_decode_size(len);
+   if (!lenout)
+   return -1;
+
+   o[--lenout] = '\0';
+
+   for (i = 0; i  len; i += 4) {
+   cv = 0;
+   for (j = 0; j  4; j++) {
+   uint8_t c = data[i + j] - 43;
+   if (c  79 || (c = b64decode_tbl[c]) == 0xff)
+   return -1;
+
+   cv |= c;
+   if (j != 3)
+   cv = 6;
+   }
+
+   o[2] = (uint8_t)(cv  0xff);
+   o[1] = (uint8_t)((cv  8)  0xff);
+   o[0] = (uint8_t)((cv  16)  0xff);
+   o += 3;
+   }
+
+   for (i = 1; i = 2; i++) {
+   if (data[len - i] == '=') {
+   o[-i] = '\0';
+   lenout--;
+   } else
+   break;
+   }
+
+   return lenout;
+}
+
+static const uint8_t b64encode_tbl

Re: [OpenWrt-Devel] [PATCH] [libubox][v4] b64: add base64 support

[Luka Perkov]

On Fri, Apr 17, 2015 at 02:14:14AM +0200, Felix Fietkau wrote:
  +size_t b64decode(void *out, const void *in, size_t len)
  +{
  +   uint8_t *o = (uint8_t *) out;
  +   const uint8_t *data = (const uint8_t *) in;
  +   size_t lenout, i, j;
  +   uint32_t cv = 0;
  +
  +   lenout = b64_decode_size(len);
  +   if (!lenout)
  +   return 0;
  +
  +   o[--lenout] = '\0';
  +
  +   for (i = 0; i  len; i += 4) {
  +   cv = 0;
  +   for (j = 0; j  4; j++) {
  +   uint8_t c = data[i + j] - 43;
  +   if (c  79 || (c = b64decode_tbl[c]) == 0xff)
  +   return 0;
  +
  +   cv |= c;
  +   if (j != 3)
  +   cv = 6;
  +   }
  +
  +   o[2] = (uint8_t)(cv  0xff);
  +   o[1] = (uint8_t)((cv  8)  0xff);
  +   o[0] = (uint8_t)((cv  16)  0xff);
  +   o += 3;
  +   }
  +
  +   for (i = 1; i = 2; i++) {
  +   if (data[len - i] == '=') {
  +   o[-i] = '\0';
  +   lenout--;
  +   } else
  +   break;
  +   }
 I think this function should match the capabilities and return code of
 b64_pton from BSD.
 It should return an int (or ssize_t) instead of size_t, and return -1 on
 errors. It should also be able to skip whitespaces.

I've chaned API as requested but there is no easy way of adding support
for whitespaces current b64decode() function. So if you really want
support for whitespaces as well as the same capabilities and return
codes I am proposing that we take in function from BSD instead of this
one. Please let me know.

  +static const uint8_t b64encode_tbl[] =
  +   ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/;
  +
  +size_t b64encode(void *out, const void *in, size_t len)
  +{
  +   uint8_t *o = (uint8_t *) out;
  +   const uint8_t *data = (const uint8_t *) in;
  +   size_t lenout, pad, i;
  +   uint32_t cv;
  +
  +   lenout = b64_encode_size(len);
  +   if (!lenout)
  +   return 0;
 Why call b64_encode_size instead of just setting *o = 0 at the end of
 the function?

Fixed in v5 which I've sent few moments ago.

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

[OpenWrt-Devel] [PATCH] [libubox][v4] b64: add base64 support

[Luka Perkov]

The base code has been taken from zstream project which was
written by Steven Barth.

Signed-off-by: Luka Perkov l...@openwrt.org
CC: Steven Barth ste...@midlink.org
---
= changes in v2:

Use new API:

size_t b64decode(void **out, const char *in, size_t len);
size_t b64encode(char **out, const void *in, size_t len);

= changes in v3:

Use new API:

static inline int b64_decode_size(const void *in, size_t len);
static inline int b64_encode_size(size_t len);

size_t b64decode(void *out, const void *in, size_t len);
size_t b64encode(void *out, const void *in, size_t len);

In this set a few corner cases of invalid writes in b64decode were fixed.
Furthermore, b64decode() works fine when in == out.

= changes in v4:

Use new API:

static inline int b64_decode_size(size_t len)
static inline int b64_encode_size(size_t len)

size_t b64decode(void *out, const void *in, size_t len);
size_t b64encode(void *out, const void *in, size_t len);

Add terminating NULL byte and make changes reported by Jonas, John and Felix.
---
 CMakeLists.txt |   2 +-
 b64.c  | 117 +
 b64.h  |  53 ++
 3 files changed, 171 insertions(+), 1 deletion(-)
 create mode 100644 b64.c
 create mode 100644 b64.h

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 58381da..77f4842 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -14,7 +14,7 @@ IF(JSONC_FOUND)
   INCLUDE_DIRECTORIES(${JSONC_INCLUDE_DIRS})
 ENDIF()
 
-SET(SOURCES avl.c avl-cmp.c blob.c blobmsg.c uloop.c usock.c ustream.c 
ustream-fd.c vlist.c utils.c safe_list.c runqueue.c md5.c kvlist.c ulog.c)
+SET(SOURCES avl.c avl-cmp.c blob.c blobmsg.c uloop.c usock.c ustream.c 
ustream-fd.c vlist.c utils.c safe_list.c runqueue.c md5.c kvlist.c ulog.c b64.c)
 
 ADD_LIBRARY(ubox SHARED ${SOURCES})
 ADD_LIBRARY(ubox-static STATIC ${SOURCES})
diff --git a/b64.c b/b64.c
new file mode 100644
index 000..b16b42d
--- /dev/null
+++ b/b64.c
@@ -0,0 +1,117 @@
+/*
+ * Copyright (C) 2011 Steven Barth ste...@midlink.org
+ * Copyright (C) 2015 Luka Perkov l...@openwrt.org
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include stdint.h
+#include stdlib.h
+
+#include b64.h
+
+static const uint8_t b64decode_tbl[] = {
+   0x3e, 0xff, 0xff, 0xff, 0x3f, 0x34, 0x35, 0x36,
+   0x37, 0x38, 0x39, 0x3a, 0x3b, 0x3c, 0x3d, 0xff,
+   0xff, 0xff, 0x00, 0xff, 0xff, 0xff, 0x00, 0x01,
+   0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09,
+   0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11,
+   0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19,
+   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x1a, 0x1b,
+   0x1c, 0x1d, 0x1e, 0x1f, 0x20, 0x21, 0x22, 0x23,
+   0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2a, 0x2b,
+   0x2c, 0x2d, 0x2e, 0x2f, 0x30, 0x31, 0x32, 0x33
+};
+
+size_t b64decode(void *out, const void *in, size_t len)
+{
+   uint8_t *o = (uint8_t *) out;
+   const uint8_t *data = (const uint8_t *) in;
+   size_t lenout, i, j;
+   uint32_t cv = 0;
+
+   lenout = b64_decode_size(len);
+   if (!lenout)
+   return 0;
+
+   o[--lenout] = '\0';
+
+   for (i = 0; i  len; i += 4) {
+   cv = 0;
+   for (j = 0; j  4; j++) {
+   uint8_t c = data[i + j] - 43;
+   if (c  79 || (c = b64decode_tbl[c]) == 0xff)
+   return 0;
+
+   cv |= c;
+   if (j != 3)
+   cv = 6;
+   }
+
+   o[2] = (uint8_t)(cv  0xff);
+   o[1] = (uint8_t)((cv  8)  0xff);
+   o[0] = (uint8_t)((cv  16)  0xff);
+   o += 3;
+   }
+
+   for (i = 1; i = 2; i++) {
+   if (data[len - i] == '=') {
+   o[-i] = '\0';
+   lenout--;
+   } else
+   break;
+   }
+
+   return lenout;
+}
+
+static const uint8_t b64encode_tbl[] =
+   ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/;
+
+size_t b64encode(void *out, const void *in, size_t len)
+{
+   uint8_t *o = (uint8_t *) out;
+   const uint8_t *data = (const uint8_t *) in;
+   size_t lenout, pad, i;
+   uint32_t cv;
+
+   lenout

Re: [OpenWrt-Devel] [PATCH] [libubox][v3] b64: add base64 support

[Luka Perkov]

Hi,

On Tue, Apr 14, 2015 at 06:00:32PM +0200, Felix Fietkau wrote:
  +  if (data[len - 1] == '=')
  +  ret--;
  +
  +  if (data[len - 2] == '=')
  +  ret--;
  
  the 2 if clauses look redundant and i guess you could solve it with a loop

Ok. I'll fix it.

 I'd prefer not passing in the input buffer here at all - a tiny
 overestimation of the decode size doesn't hurt.

I don't think that is a good idea since we do not have NULL terminating
output buffer in b64decode(). If you really want a function without
input buffer we can make another one called:

static inline int b64_decode_size_approx(size_t len);

The overestimation is likely going to cause problems in cases like this:

buf = malloc(b64_decode_size(data, data_len));
if (!buf)
return -1

buf_len = b64decode(rbuf, data, data_len);
if (!buf_len)
return -1

write(fd, buf, buf_len);

In this case end of buf could be foobared and because of that extra
bytes could be written.

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

[OpenWrt-Devel] [PATCH] [libubox][v3] b64: add base64 support

[Luka Perkov]

The base code has been taken from zstream project which was
written by Steven Barth.

Signed-off-by: Luka Perkov l...@openwrt.org
CC: Steven Barth ste...@midlink.org
---
= changes in v2:

Use new API:

size_t b64decode(void **out, const char *in, size_t len);
size_t b64encode(char **out, const void *in, size_t len);

= changes in v3:

Use new API:

static inline int b64_decode_size(const void *in, size_t len);
static inline int b64_encode_size(size_t len);

size_t b64decode(void *out, const void *in, size_t len);
size_t b64encode(void *out, const void *in, size_t len);

In this set a few corner cases of invalid writes in b64decode were fixed.
Furthermore, b64decode() works fine when in == out.

 CMakeLists.txt |   2 +-
 b64.c  | 112 +
 b64.h  |  60 +++
 3 files changed, 173 insertions(+), 1 deletion(-)
 create mode 100644 b64.c
 create mode 100644 b64.h

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 58381da..77f4842 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -14,7 +14,7 @@ IF(JSONC_FOUND)
   INCLUDE_DIRECTORIES(${JSONC_INCLUDE_DIRS})
 ENDIF()
 
-SET(SOURCES avl.c avl-cmp.c blob.c blobmsg.c uloop.c usock.c ustream.c 
ustream-fd.c vlist.c utils.c safe_list.c runqueue.c md5.c kvlist.c ulog.c)
+SET(SOURCES avl.c avl-cmp.c blob.c blobmsg.c uloop.c usock.c ustream.c 
ustream-fd.c vlist.c utils.c safe_list.c runqueue.c md5.c kvlist.c ulog.c b64.c)
 
 ADD_LIBRARY(ubox SHARED ${SOURCES})
 ADD_LIBRARY(ubox-static STATIC ${SOURCES})
diff --git a/b64.c b/b64.c
new file mode 100644
index 000..007fb91
--- /dev/null
+++ b/b64.c
@@ -0,0 +1,112 @@
+/*
+ * Copyright (C) 2011 Steven Barth ste...@midlink.org
+ * Copyright (C) 2015 Luka Perkov l...@openwrt.org
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include stdint.h
+#include stdlib.h
+
+#include b64.h
+
+static const uint8_t b64decode_tbl[] = {
+   0x3e, 0xff, 0xff, 0xff, 0x3f, 0x34, 0x35, 0x36,
+   0x37, 0x38, 0x39, 0x3a, 0x3b, 0x3c, 0x3d, 0xff,
+   0xff, 0xff, 0x00, 0xff, 0xff, 0xff, 0x00, 0x01,
+   0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09,
+   0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11,
+   0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19,
+   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x1a, 0x1b,
+   0x1c, 0x1d, 0x1e, 0x1f, 0x20, 0x21, 0x22, 0x23,
+   0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2a, 0x2b,
+   0x2c, 0x2d, 0x2e, 0x2f, 0x30, 0x31, 0x32, 0x33
+};
+
+size_t b64decode(void *out, const void *in, size_t len)
+{
+   uint8_t *o = (uint8_t *) out;
+   const uint8_t *data = (const uint8_t *) in;
+   size_t lenout, i, j;
+
+   lenout = b64_decode_size(in, len);
+   if (!lenout)
+   return 0;
+
+   uint32_t cv = 0;
+   for (i = 0; i  (len - 4); i += 4) {
+   cv = 0;
+   for (j = 0; j  4; j++) {
+   uint8_t c = data[i + j] - 43;
+   if (c  79 || (c = b64decode_tbl[c]) == 0xff)
+   return 0;
+
+   cv |= c;
+   if (j != 3)
+   cv = 6;
+   }
+
+   o[2] = (uint8_t)(cv  0xff);
+   o[1] = (uint8_t)((cv  8)  0xff);
+   o[0] = (uint8_t)((cv  16)  0xff);
+   o += 3;
+   }
+
+   if (data[len - 1] != '=')
+   o[2] = (uint8_t)(cv  0xff);
+
+   if (data[len - 1] != '=')
+   o[1] = (uint8_t)((cv  8)  0xff);
+
+   o[0] = (uint8_t)((cv  16)  0xff);
+
+   return lenout;
+}
+
+static const uint8_t b64encode_tbl[] =
+   ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/;
+
+size_t b64encode(void *out, const void *in, size_t len)
+{
+   uint8_t *o = (uint8_t *) out;
+   const uint8_t *data = (const uint8_t *) in;
+   size_t lenout, pad, i;
+
+   lenout = b64_encode_size(len);
+   if (!lenout)
+   return 0;
+
+   for (i = 0; i  len; i += 3) {
+   uint32_t cv = (data[i]  16) | (data[i + 1]  8) | data[i + 
2];
+   o[3] = b64encode_tbl[cv  0x3f];
+   o[2] = b64encode_tbl[(cv  6)  0x3f];
+   o[1] = b64encode_tbl[(cv  12)  0x3f];
+   o[0

[OpenWrt-Devel] [PATCH] [ustream-ssl][v2] polarssl: fix long writes

[Luka Perkov]

Enable to write more data then defined in SSL_MAX_CONTENT_LEN.

Signed-off-by: Luka Perkov l...@openwrt.org
---
changes in v2:
* fix return value

 ustream-polarssl.c | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/ustream-polarssl.c b/ustream-polarssl.c
index cbf24cb..66718f1 100644
--- a/ustream-polarssl.c
+++ b/ustream-polarssl.c
@@ -232,17 +232,23 @@ __hidden enum ssl_conn_status 
__ustream_ssl_connect(struct ustream_ssl *us)
 __hidden int __ustream_ssl_write(struct ustream_ssl *us, const char *buf, int 
len)
 {
void *ssl = us-ssl;
-   int ret = ssl_write(ssl, (const unsigned char *) buf, len);
+   int done = 0, ret = 0;
 
-   if (ret  0) {
-   if (ssl_do_wait(ret))
-   return 0;
+   while (done != len) {
+   ret = ssl_write(ssl, (const unsigned char *) buf + done, len - 
done);
 
-   ustream_ssl_error(us, ret);
-   return -1;
+   if (ret  0) {
+   if (ssl_do_wait(ret))
+   return 0;
+
+   ustream_ssl_error(us, ret);
+   return -1;
+   }
+
+   done += ret;
}
 
-   return ret;
+   return done;
 }
 
 __hidden int __ustream_ssl_read(struct ustream_ssl *us, char *buf, int len)
-- 
2.3.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] [ustream-ssl][v3] polarssl: fix long writes

[Luka Perkov]

Enable to write more data then defined in SSL_MAX_CONTENT_LEN.

Signed-off-by: Luka Perkov l...@openwrt.org
---
changes in v2:
* fix return value at the end

changes in v3:
* fix another return value

 ustream-polarssl.c | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/ustream-polarssl.c b/ustream-polarssl.c
index cbf24cb..615ac2d 100644
--- a/ustream-polarssl.c
+++ b/ustream-polarssl.c
@@ -232,17 +232,23 @@ __hidden enum ssl_conn_status 
__ustream_ssl_connect(struct ustream_ssl *us)
 __hidden int __ustream_ssl_write(struct ustream_ssl *us, const char *buf, int 
len)
 {
void *ssl = us-ssl;
-   int ret = ssl_write(ssl, (const unsigned char *) buf, len);
+   int done = 0, ret = 0;
 
-   if (ret  0) {
-   if (ssl_do_wait(ret))
-   return 0;
+   while (done != len) {
+   ret = ssl_write(ssl, (const unsigned char *) buf + done, len - 
done);
 
-   ustream_ssl_error(us, ret);
-   return -1;
+   if (ret  0) {
+   if (ssl_do_wait(ret))
+   return done;
+
+   ustream_ssl_error(us, ret);
+   return -1;
+   }
+
+   done += ret;
}
 
-   return ret;
+   return done;
 }
 
 __hidden int __ustream_ssl_read(struct ustream_ssl *us, char *buf, int len)
-- 
2.3.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] [ustream-ssl] polarssl: fix long writes

[Luka Perkov]

Enable to write more data then defined in SSL_MAX_CONTENT_LEN.

Signed-off-by: Luka Perkov l...@openwrt.org
---
 ustream-polarssl.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/ustream-polarssl.c b/ustream-polarssl.c
index cbf24cb..ce9b164 100644
--- a/ustream-polarssl.c
+++ b/ustream-polarssl.c
@@ -232,14 +232,20 @@ __hidden enum ssl_conn_status 
__ustream_ssl_connect(struct ustream_ssl *us)
 __hidden int __ustream_ssl_write(struct ustream_ssl *us, const char *buf, int 
len)
 {
void *ssl = us-ssl;
-   int ret = ssl_write(ssl, (const unsigned char *) buf, len);
+   int done = 0, ret = 0;
 
-   if (ret  0) {
-   if (ssl_do_wait(ret))
-   return 0;
+   while (done != len) {
+   ret = ssl_write(ssl, (const unsigned char *) buf + done, len - 
done);
 
-   ustream_ssl_error(us, ret);
-   return -1;
+   if (ret  0) {
+   if (ssl_do_wait(ret))
+   return 0;
+
+   ustream_ssl_error(us, ret);
+   return -1;
+   }
+
+   done += ret;
}
 
return ret;
-- 
2.3.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] [ustream-ssl] polarssl: fix long writes

[Luka Perkov]

On Sat, Apr 11, 2015 at 11:36:14PM +0200, Felix Fietkau wrote:
 On 2015-04-11 23:23, Luka Perkov wrote:
  Enable to write more data then defined in SSL_MAX_CONTENT_LEN.
  
  Signed-off-by: Luka Perkov l...@openwrt.org
  ---
   ustream-polarssl.c | 18 --
   1 file changed, 12 insertions(+), 6 deletions(-)
  
  diff --git a/ustream-polarssl.c b/ustream-polarssl.c
  index cbf24cb..ce9b164 100644
  --- a/ustream-polarssl.c
  +++ b/ustream-polarssl.c
  @@ -232,14 +232,20 @@ __hidden enum ssl_conn_status 
  __ustream_ssl_connect(struct ustream_ssl *us)
   __hidden int __ustream_ssl_write(struct ustream_ssl *us, const char *buf, 
  int len)
   {
  void *ssl = us-ssl;
  -   int ret = ssl_write(ssl, (const unsigned char *) buf, len);
  +   int done = 0, ret = 0;
   
  -   if (ret  0) {
  -   if (ssl_do_wait(ret))
  -   return 0;
  +   while (done != len) {
  +   ret = ssl_write(ssl, (const unsigned char *) buf + done, len - 
  done);
   
  -   ustream_ssl_error(us, ret);
  -   return -1;
  +   if (ret  0) {
  +   if (ssl_do_wait(ret))
  +   return 0;
 This does not look right. I think it should be 'return done', otherwise
 plaintext data will be duplicated if the first write succeeds but the
 second doesn't.

Yes, this one too... I've sent v2 with other return fixed. Going to send
v3 in a bit.

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

[OpenWrt-Devel] [PATCH] [libubox][v2] b64: add base64 support

[Luka Perkov]

The base code has been taken from zstream project which was
written by Steven Barth.

Signed-off-by: Luka Perkov l...@openwrt.org
CC: Steven Barth ste...@midlink.org
---
changes in v2:

Use new API:

size_t b64decode(void **out, const char *in, size_t len);
size_t b64encode(char **out, const void *in, size_t len);

 CMakeLists.txt |   2 +-
 b64.c  | 154 +
 b64.h  |  26 ++
 3 files changed, 181 insertions(+), 1 deletion(-)
 create mode 100644 b64.c
 create mode 100644 b64.h

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 58381da..77f4842 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -14,7 +14,7 @@ IF(JSONC_FOUND)
   INCLUDE_DIRECTORIES(${JSONC_INCLUDE_DIRS})
 ENDIF()
 
-SET(SOURCES avl.c avl-cmp.c blob.c blobmsg.c uloop.c usock.c ustream.c 
ustream-fd.c vlist.c utils.c safe_list.c runqueue.c md5.c kvlist.c ulog.c)
+SET(SOURCES avl.c avl-cmp.c blob.c blobmsg.c uloop.c usock.c ustream.c 
ustream-fd.c vlist.c utils.c safe_list.c runqueue.c md5.c kvlist.c ulog.c b64.c)
 
 ADD_LIBRARY(ubox SHARED ${SOURCES})
 ADD_LIBRARY(ubox-static STATIC ${SOURCES})
diff --git a/b64.c b/b64.c
new file mode 100644
index 000..86593d2
--- /dev/null
+++ b/b64.c
@@ -0,0 +1,154 @@
+/*
+ * Copyright (C) 2011 Steven Barth ste...@midlink.org
+ * Copyright (C) 2015 Luka Perkov l...@openwrt.org
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include stdint.h
+#include stdlib.h
+
+#include b64.h
+
+static const unsigned char b64decode_tbl[] = {
+   0x3e, 0xff, 0xff, 0xff, 0x3f, 0x34, 0x35, 0x36,
+   0x37, 0x38, 0x39, 0x3a, 0x3b, 0x3c, 0x3d, 0xff,
+   0xff, 0xff, 0x00, 0xff, 0xff, 0xff, 0x00, 0x01,
+   0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09,
+   0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11,
+   0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19,
+   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x1a, 0x1b,
+   0x1c, 0x1d, 0x1e, 0x1f, 0x20, 0x21, 0x22, 0x23,
+   0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2a, 0x2b,
+   0x2c, 0x2d, 0x2e, 0x2f, 0x30, 0x31, 0x32, 0x33
+};
+
+static inline size_t b64_decode_size(const char *in, size_t len)
+{
+   size_t ret;
+
+   if ((len == 0) || (len % 4))
+   return 0;
+
+   ret = len / 4 * 3;
+
+   if (in[(int) len - 1] == '=')
+   ret--;
+
+   if (in[(int) len - 2] == '=')
+   ret--;
+
+   return ret;
+}
+
+size_t b64decode(void **out, const char *in, size_t len)
+{
+   size_t lenout, i, j;
+   unsigned char *o;
+
+   lenout = b64_decode_size(in, len);
+   if (!lenout) {
+   *out = NULL;
+   return 0;
+   }
+
+   *out = calloc(lenout, sizeof(char));
+   if (!(*out))
+   return 0;
+
+   o = (unsigned char *) *out;
+   for (i = 0; i  len; i += 4) {
+   uint32_t cv = 0;
+   for (j = 0; j  4; j++) {
+   unsigned char c = in[i + j] - 43;
+   if (c  79 || (c = b64decode_tbl[c]) == 0xff) {
+   free(*out);
+   *out = NULL;
+   return 0;
+   }
+
+   cv |= c;
+   if (j != 3) {
+   cv = 6;
+   }
+   }
+
+   o[2] = (unsigned char)( cv 0xff);
+   o[1] = (unsigned char)((cv   8)  0xff);
+   o[0] = (unsigned char)((cv  16)  0xff);
+   o += 3;
+   }
+
+   return lenout;
+}
+
+static const unsigned char b64encode_tbl[] =
+   ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/;
+
+static inline size_t b64_encode_size(size_t len)
+{
+   size_t ret;
+
+   if (len == 0)
+   return 0;
+
+   ret = len / 3;
+   ret *= 4;
+
+   if (len % 3)
+   ret += 4;
+
+   return ret;
+}
+
+size_t b64encode(char **out, const void *in, size_t len)
+{
+   size_t lenout, pad, i;
+   const uint8_t *data = (const uint8_t *) in;
+   uint8_t *o;
+
+   lenout = b64_encode_size(len);
+   if (!lenout) {
+   *out = NULL;
+   return 0;
+   }
+
+   *out = calloc(lenout

[OpenWrt-Devel] [PATCH] [rpcd][v2] file: add md5sum support

[Luka Perkov]

Signed-off-by: Luka Perkov l...@openwrt.org
---
changes in v2:

* no need to null-terminate string after sprintf()

 file.c | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/file.c b/file.c
index 3831c54..9c1b301 100644
--- a/file.c
+++ b/file.c
@@ -27,6 +27,7 @@
 #include sys/wait.h
 #include libubus.h
 #include libubox/blobmsg.h
+#include libubox/md5.h
 #include libubox/ustream.h
 
 #include rpcd/plugin.h
@@ -237,6 +238,39 @@ rpc_file_write(struct ubus_context *ctx, struct 
ubus_object *obj,
 }
 
 static int
+rpc_file_md5(struct ubus_context *ctx, struct ubus_object *obj,
+ struct ubus_request_data *req, const char *method,
+ struct blob_attr *msg)
+{ 
+   int rv, i;
+   char *path;
+   struct stat s;
+   uint8_t md5[16];
+   char *wbuf;
+
+   if (!rpc_check_path(msg, path, s))
+   return rpc_errno_status();
+
+   if (!S_ISREG(s.st_mode))
+   return UBUS_STATUS_NOT_SUPPORTED;
+
+   if ((rv = md5sum(path, md5)) = 0)
+   return rpc_errno_status();
+
+   blob_buf_init(buf, 0);
+   wbuf = blobmsg_alloc_string_buffer(buf, md5, 33);
+
+   for (i = 0; i  16; i++)
+   sprintf(wbuf + (i * 2), %02x, (uint8_t) md5[i]);
+
+   blobmsg_add_string_buffer(buf);
+   ubus_send_reply(ctx, req, buf.head);
+   blob_buf_free(buf);
+
+   return UBUS_STATUS_OK;
+}
+
+static int
 rpc_file_list(struct ubus_context *ctx, struct ubus_object *obj,
   struct ubus_request_data *req, const char *method,
   struct blob_attr *msg)
@@ -611,6 +645,7 @@ rpc_file_api_init(const struct rpc_daemon_ops *o, struct 
ubus_context *ctx)
UBUS_METHOD(write,   rpc_file_write, rpc_file_rw_policy),
UBUS_METHOD(list,rpc_file_list,  rpc_file_r_policy),
UBUS_METHOD(stat,rpc_file_stat,  rpc_file_r_policy),
+   UBUS_METHOD(md5, rpc_file_md5,   rpc_file_r_policy),
UBUS_METHOD(exec,rpc_file_exec,  rpc_exec_policy),
};
 
-- 
2.3.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] adding seccomp and service jailing to procd

[Luka Perkov]

Hi John,

On Fri, Mar 27, 2015 at 07:58:46PM +0100, John Crispin wrote:
 On 27/03/2015 19:56, Luka Perkov wrote:
  Hi John,
  
  On Fri, Mar 27, 2015 at 03:37:33PM +0100, John Crispin wrote:
  Also i would love to hear the pro and cons of extending ubus
  vs switching to kdbus (i'm not trying to start a debate, and i
  really have no idea of the work involved, just curious)
  
  we need to discuss this internally. i have already started
  thinking about it.bu have no opinion yet
  
  It would be better that such invasive changes that were done or
  are planned are communicated and explained before the actual push
  and not after. In this specific case a patch to either public or
  internal mailing list would not hurt. The breakage for some targets
  could have been easily avoided that way.
  
  Luka
 
 i communicated this to lots of people ahead and sent a mail to the
 internal list 1 day in advance,

Ah, I see, I should be grateful that we had a full day.

 there was next to zero damaged caused by this. you should spend your time
 fixing up imx6,

What is broken in imx6? The target is just not bumped to 3.18.

 rather than criticizing other for adding cool features.

I did not say the features are not cool. Actually, I think they are cool. After
my trip I'll take a closer look at the new features and I am really looking
forward to making contributions!

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

Re: [OpenWrt-Devel] adding seccomp and service jailing to procd

[Luka Perkov]

Hi John,

On Fri, Mar 27, 2015 at 03:37:33PM +0100, John Crispin wrote:
  Also i would love to hear the pro and cons of extending ubus vs
  switching to kdbus
  (i'm not trying to start a debate, and i really have no idea of the work
  involved, just curious)
 
 we need to discuss this internally. i have already started thinking
 about it.bu have no opinion yet

It would be better that such invasive changes that were done or are
planned are communicated and explained before the actual push and not
after. In this specific case a patch to either public or internal
mailing list would not hurt. The breakage for some targets could have
been easily avoided that way.

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

Re: [OpenWrt-Devel] [PATCH 3/3] [rpcd] file: add support for setting mode when writing files

[Luka Perkov]

Hi John,

On Sun, Mar 15, 2015 at 10:27:49PM +0100, John Crispin wrote:
  +   umask(0);
 
 setting umask to 0 and then not resetting it to the old value afterwards
 seems wrong.
 
 - main.c:   umask(0077);

Good catch. Will send v2.

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

[OpenWrt-Devel] [PATCH] [libubox] b64: add base64 support

[Luka Perkov]

The code has been taken from zstream project which
was written by Steven Barth.

Signed-off-by: Luka Perkov l...@openwrt.org
CC: Steven Barth ste...@midlink.org
CC: John Crispin blo...@openwrt.org
---
 CMakeLists.txt |   2 +-
 b64.c  | 136 +
 b64.h  |  25 +++
 3 files changed, 162 insertions(+), 1 deletion(-)
 create mode 100644 b64.c
 create mode 100644 b64.h

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 58381da..77f4842 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -14,7 +14,7 @@ IF(JSONC_FOUND)
   INCLUDE_DIRECTORIES(${JSONC_INCLUDE_DIRS})
 ENDIF()
 
-SET(SOURCES avl.c avl-cmp.c blob.c blobmsg.c uloop.c usock.c ustream.c 
ustream-fd.c vlist.c utils.c safe_list.c runqueue.c md5.c kvlist.c ulog.c)
+SET(SOURCES avl.c avl-cmp.c blob.c blobmsg.c uloop.c usock.c ustream.c 
ustream-fd.c vlist.c utils.c safe_list.c runqueue.c md5.c kvlist.c ulog.c b64.c)
 
 ADD_LIBRARY(ubox SHARED ${SOURCES})
 ADD_LIBRARY(ubox-static STATIC ${SOURCES})
diff --git a/b64.c b/b64.c
new file mode 100644
index 000..9b6defe
--- /dev/null
+++ b/b64.c
@@ -0,0 +1,136 @@
+/*
+ * Copyright (C) 2011 Steven Barth ste...@midlink.org
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include errno.h
+#include stdint.h
+#include stdlib.h
+#include string.h
+
+#include b64.h
+
+static const unsigned char b64encode_tbl[] =
+   ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/;
+
+char *b64encode(const void *in, size_t *len)
+{
+   size_t lenout, pad, i;
+   const uint8_t *data = (const uint8_t *) in;
+   uint8_t *o;
+   char *out;
+
+   lenout = *len / 3;
+   lenout *= 4;
+   pad = *len % 3;
+
+   if (*len == 0)
+   return strdup();
+   else if (pad)
+   lenout += 4;
+
+   out = calloc(lenout + 1, sizeof(char));
+   if (!out)
+   return NULL;
+
+   o = (uint8_t *) out;
+   for (i = 0; i  *len; i += 3) {
+   uint32_t cv = (data[i]  16) | (data[i + 1]  8) | data[i + 
2];
+   o[3] = b64encode_tbl[ cv 0x3f];
+   o[2] = b64encode_tbl[(cv  6)   0x3f];
+   o[1] = b64encode_tbl[(cv  12)  0x3f];
+   o[0] = b64encode_tbl[(cv  18)  0x3f];
+   o += 4;
+   }
+
+   if (pad) {
+   uint32_t cv = data[*len - pad]  16;
+   o[-1] = '=';
+   o[-2] = '=';
+   if (pad == 2) {
+   cv |= data[*len - pad + 1]  8;
+   o[-2] = b64encode_tbl[(cv  6)  0x3f];
+   }
+   o[-3] = b64encode_tbl[(cv  12)  0x3f];
+   o[-4] = b64encode_tbl[(cv  18)  0x3f];
+   }
+
+   out[lenout] = '\0';
+   *len = lenout;
+   return out;
+}
+
+static const unsigned char b64decode_tbl[] = {
+   0x3e, 0xff, 0xff, 0xff, 0x3f, 0x34, 0x35, 0x36,
+   0x37, 0x38, 0x39, 0x3a, 0x3b, 0x3c, 0x3d, 0xff,
+   0xff, 0xff, 0x00, 0xff, 0xff, 0xff, 0x00, 0x01,
+   0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09,
+   0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11,
+   0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19,
+   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x1a, 0x1b,
+   0x1c, 0x1d, 0x1e, 0x1f, 0x20, 0x21, 0x22, 0x23,
+   0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2a, 0x2b,
+   0x2c, 0x2d, 0x2e, 0x2f, 0x30, 0x31, 0x32, 0x33
+};
+
+void *b64decode(const char *in, size_t *len)
+{
+   size_t lenout, i, j;
+   unsigned char *out, *o;
+
+   if (*len == 0) {
+   return strdup();
+   } else if (*len % 4) {
+   errno = EINVAL;
+   return NULL;
+   }
+
+   lenout = *len / 4 * 3;
+
+   out = calloc(lenout + 1, sizeof(char));
+   if (!out)
+   return NULL;
+
+   o = out;
+   for (i = 0; i  *len; i += 4) {
+   uint32_t cv = 0;
+   for (j = 0; j  4; j++) {
+   unsigned char c = in[i + j] - 43;
+   if (c  79 || (c = b64decode_tbl[c]) == 0xff) {
+   free(out);
+   errno = EINVAL;
+   return NULL;
+   }
+
+   cv |= c

Re: [OpenWrt-Devel] [PATCH 1/3] [rpcd] file: add md5sum support

[Luka Perkov]

Hi John,

On Sun, Mar 15, 2015 at 10:21:27PM +0100, John Crispin wrote:
 On 15/03/2015 22:00, Luka Perkov wrote:
  wbuf = blobmsg_alloc_string_buffer(buf, md5, 33);
  +
  +   for (i = 0; i  16; i++)
  +   sprintf((wbuf + (i * 2)), %02x, (uint8_t) md5[i]);
 
 there is a set of brackets too many here

Ok. I've fixed it locally.

  +   *(wbuf + 33) = 0;
 
 is this not off by 1 ?

No.

 if we want to be pedantic it should also be '\0'
 
 i think wbuf[32] = '\0'; is a saner syntax

Ok. I've queued this for v2 which I will send after libubox base64
patch.

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

Re: [OpenWrt-Devel] [PATCH 2/3] [rpcd] file: add support for base64

[Luka Perkov]

Hi John,

On Sun, Mar 15, 2015 at 10:26:26PM +0100, John Crispin wrote:
 On 15/03/2015 22:00, Luka Perkov wrote:
  b64encode and b64decode functions were taken from zstream project which was
  written by Steven Barth and John Crispin.
 
 i did not write this :)

You were in (C) headers from where the code was taken and that is why I
put your name here as well :)

I'm going to send base64 libubox patch and after that is sorted out I
will send v2 of this patch.

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

[OpenWrt-Devel] [PATCH 1/3] [rpcd] file: add md5sum support

[Luka Perkov]

Signed-off-by: Luka Perkov l...@openwrt.org
---
 file.c | 37 +
 1 file changed, 37 insertions(+)

diff --git a/file.c b/file.c
index 31a937d..9e87a10 100644
--- a/file.c
+++ b/file.c
@@ -27,6 +27,7 @@
 #include sys/wait.h
 #include libubus.h
 #include libubox/blobmsg.h
+#include libubox/md5.h
 #include libubox/ustream.h
 
 #include rpcd/plugin.h
@@ -237,6 +238,41 @@ rpc_file_write(struct ubus_context *ctx, struct 
ubus_object *obj,
 }
 
 static int
+rpc_file_md5(struct ubus_context *ctx, struct ubus_object *obj,
+ struct ubus_request_data *req, const char *method,
+ struct blob_attr *msg)
+{ 
+   int rv, i;
+   char *path;
+   struct stat s;
+   uint8_t md5[16];
+   char *wbuf;
+
+   if (!rpc_check_path(msg, path, s))
+   return rpc_errno_status();
+
+   if (!S_ISREG(s.st_mode))
+   return UBUS_STATUS_NOT_SUPPORTED;
+
+   if ((rv = md5sum(path, md5)) = 0)
+   return rpc_errno_status();
+
+   blob_buf_init(buf, 0);
+   wbuf = blobmsg_alloc_string_buffer(buf, md5, 33);
+
+   for (i = 0; i  16; i++)
+   sprintf((wbuf + (i * 2)), %02x, (uint8_t) md5[i]);
+
+   *(wbuf + 33) = 0;
+
+   blobmsg_add_string_buffer(buf);
+   ubus_send_reply(ctx, req, buf.head);
+   blob_buf_free(buf);
+
+   return UBUS_STATUS_OK;
+}
+
+static int
 rpc_file_list(struct ubus_context *ctx, struct ubus_object *obj,
   struct ubus_request_data *req, const char *method,
   struct blob_attr *msg)
@@ -611,6 +647,7 @@ rpc_file_api_init(const struct rpc_daemon_ops *o, struct 
ubus_context *ctx)
UBUS_METHOD(write,   rpc_file_write, rpc_file_rw_policy),
UBUS_METHOD(list,rpc_file_list,  rpc_file_r_policy),
UBUS_METHOD(stat,rpc_file_stat,  rpc_file_r_policy),
+   UBUS_METHOD(md5, rpc_file_md5,   rpc_file_r_policy),
UBUS_METHOD(exec,rpc_file_exec,  rpc_exec_policy),
};
 
-- 
2.3.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/3] [rpcd] file: add support for base64

[Luka Perkov]

b64encode and b64decode functions were taken from zstream project which was
written by Steven Barth and John Crispin.

Signed-off-by: Luka Perkov l...@openwrt.org
---
 file.c | 197 +
 1 file changed, 187 insertions(+), 10 deletions(-)

diff --git a/file.c b/file.c
index 9e87a10..54f5d8a 100644
--- a/file.c
+++ b/file.c
@@ -79,14 +79,27 @@ static const struct blobmsg_policy 
rpc_file_r_policy[__RPC_F_R_MAX] = {
 };
 
 enum {
+   RPC_F_RB_PATH,
+   RPC_F_RB_BASE64,
+   __RPC_F_RB_MAX,
+};
+
+static const struct blobmsg_policy rpc_file_rb_policy[__RPC_F_RB_MAX] = {
+   [RPC_F_RB_PATH]   = { .name = path,   .type = BLOBMSG_TYPE_STRING },
+   [RPC_F_RB_BASE64] = { .name = base64, .type = BLOBMSG_TYPE_BOOL   },
+};
+
+enum {
RPC_F_RW_PATH,
RPC_F_RW_DATA,
+   RPC_F_RW_BASE64,
__RPC_F_RW_MAX,
 };
 
 static const struct blobmsg_policy rpc_file_rw_policy[__RPC_F_RW_MAX] = {
-   [RPC_F_RW_PATH] = { .name = path, .type = BLOBMSG_TYPE_STRING },
-   [RPC_F_RW_DATA] = { .name = data, .type = BLOBMSG_TYPE_STRING },
+   [RPC_F_RW_PATH]   = { .name = path,   .type = BLOBMSG_TYPE_STRING },
+   [RPC_F_RW_DATA]   = { .name = data,   .type = BLOBMSG_TYPE_STRING },
+   [RPC_F_RW_BASE64] = { .name = base64, .type = BLOBMSG_TYPE_BOOL   },
 };
 
 enum {
@@ -114,6 +127,122 @@ static const char *d_types[] = {
 };
 
 
+static const unsigned char b64encode_tbl[] =
+   ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/;
+
+static char
+*b64encode(const void *in, size_t *len)
+{
+   size_t lenout, pad, i;
+   const uint8_t *data = (const uint8_t *) in;
+
+   lenout = *len / 3;
+   lenout *= 4;
+   pad = *len % 3;
+
+   if (*len == 0) {
+   return strdup();
+   } else if (pad) {
+   lenout += 4;
+   }
+
+   char *out = calloc(lenout + 1, sizeof(char));
+   if (!out)
+   return NULL;
+
+   uint8_t *o = (uint8_t*)out;
+   for (i = 0; i  *len; i += 3) {
+   uint32_t cv = (data[i]  16) | (data[i+1]  8) | data[i+2];
+   *(o+3) = b64encode_tbl[ cv 0x3f];
+   *(o+2) = b64encode_tbl[(cv  6)   0x3f];
+   *(o+1) = b64encode_tbl[(cv  12)  0x3f];
+   *o = b64encode_tbl[(cv  18)  0x3f];
+   o += 4;
+   }
+
+   if (pad) {
+   uint32_t cv = data[*len-pad]  16;
+   *(o-1) = '=';
+   *(o-2) = '=';
+   if (pad == 2) {
+   cv |= data[*len-pad+1]  8;
+   *(o-2) = b64encode_tbl[(cv  6)  0x3f];
+   }
+   *(o-3) = b64encode_tbl[(cv  12)  0x3f];
+   *(o-4) = b64encode_tbl[(cv  18)  0x3f];
+   }
+
+   out[lenout] = 0;
+   *len = lenout;
+   return out;
+}
+
+static const unsigned char b64decode_tbl[] = {
+   0x3e, 0xff, 0xff, 0xff, 0x3f, 0x34, 0x35, 0x36,
+   0x37, 0x38, 0x39, 0x3a, 0x3b, 0x3c, 0x3d, 0xff,
+   0xff, 0xff, 0x00, 0xff, 0xff, 0xff, 0x00, 0x01,
+   0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09,
+   0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x11,
+   0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19,
+   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x1a, 0x1b,
+   0x1c, 0x1d, 0x1e, 0x1f, 0x20, 0x21, 0x22, 0x23,
+   0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2a, 0x2b,
+   0x2c, 0x2d, 0x2e, 0x2f, 0x30, 0x31, 0x32, 0x33
+};
+
+static void
+*b64decode(const char *in, size_t *len)
+{
+   size_t lenout, i;
+
+   if (*len == 0) {
+   return strdup();
+   } else if (*len % 4) {
+   errno = EINVAL;
+   return NULL;
+   }
+
+   lenout = *len / 4 * 3;
+
+   unsigned char *out = calloc(lenout + 1, sizeof(char));
+   if (!out)
+   return NULL;
+
+   unsigned char *o = out;
+   for (i = 0; i  *len; i += 4) {
+   uint32_t cv = 0;
+   for (int j = 0; j  4; j++) {
+   unsigned char c = in[i + j] - 43;
+   if (c  79 || (c = b64decode_tbl[c]) == 0xff) {
+   free(out);
+   errno = EINVAL;
+   return NULL;
+   }
+
+   cv |= c;
+   if (j != 3) {
+   cv = 6;
+   }
+   }
+
+   *(o+2) = (unsigned char)(cv  0xff);
+   *(o+1) = (unsigned char)((cv   8)  0xff);
+   *o = (unsigned char)((cv  16)  0xff);
+   o += 3;
+   }
+
+   if (in[*len-1] == '=') {
+   lenout--;
+   }
+
+   if (in[*len-2] == '=') {
+   lenout--;
+   }
+
+   *len = lenout;
+   return out;
+}
+
 static int
 rpc_errno_status(void)
 {
@@ -162,12 +291,22 @@ rpc_file_read(struct

[OpenWrt-Devel] [PATCH 3/3] [rpcd] file: add support for setting mode when writing files

[Luka Perkov]

Signed-off-by: Luka Perkov l...@openwrt.org
---
 file.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/file.c b/file.c
index 54f5d8a..95dd4d4 100644
--- a/file.c
+++ b/file.c
@@ -92,6 +92,7 @@ static const struct blobmsg_policy 
rpc_file_rb_policy[__RPC_F_RB_MAX] = {
 enum {
RPC_F_RW_PATH,
RPC_F_RW_DATA,
+   RPC_F_RW_MODE,
RPC_F_RW_BASE64,
__RPC_F_RW_MAX,
 };
@@ -99,6 +100,7 @@ enum {
 static const struct blobmsg_policy rpc_file_rw_policy[__RPC_F_RW_MAX] = {
[RPC_F_RW_PATH]   = { .name = path,   .type = BLOBMSG_TYPE_STRING },
[RPC_F_RW_DATA]   = { .name = data,   .type = BLOBMSG_TYPE_STRING },
+   [RPC_F_RW_MODE]   = { .name = mode,   .type = BLOBMSG_TYPE_INT32  },
[RPC_F_RW_BASE64] = { .name = base64, .type = BLOBMSG_TYPE_BOOL   },
 };
 
@@ -372,6 +374,7 @@ rpc_file_write(struct ubus_context *ctx, struct ubus_object 
*obj,
 {
struct blob_attr *tb[__RPC_F_RW_MAX];
bool base64 = false;
+   mode_t mode = 0644;
int fd, rv = 0;
void *rbuf;
size_t rbuf_len;
@@ -382,12 +385,16 @@ rpc_file_write(struct ubus_context *ctx, struct 
ubus_object *obj,
if (!tb[RPC_F_RW_PATH] || !tb[RPC_F_RW_DATA])
return UBUS_STATUS_INVALID_ARGUMENT;
 
-   if ((fd = open(blobmsg_data(tb[RPC_F_RW_PATH]), O_CREAT | O_WRONLY | 
O_TRUNC))  0)
-   return rpc_errno_status();
+   if (tb[RPC_F_RW_MODE])
+   mode = blobmsg_get_u32(tb[RPC_F_RW_MODE]);
 
if (tb[RPC_F_RW_BASE64])
base64 = blobmsg_get_bool(tb[RPC_F_RW_BASE64]);
 
+   umask(0);
+   if ((fd = open(blobmsg_data(tb[RPC_F_RW_PATH]), O_CREAT | O_WRONLY | 
O_TRUNC, mode))  0)
+   return rpc_errno_status();
+
if (base64) {
rbuf_len = blobmsg_data_len(tb[RPC_F_RW_DATA]) - 1;
rbuf = b64decode(blobmsg_data(tb[RPC_F_RW_DATA]), rbuf_len);
-- 
2.3.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ARV752DPW22: enable netconsole in u-boot if 192.168.1.2 is reachable

[Luka Perkov]

Hi Tobias,

On Sat, Mar 07, 2015 at 05:59:36PM +0100, Tobias Göbel wrote:
 just added netconsole support to ARV752DPW22 (should work on the other
 lantiq devices too).
 The device boot's and tries to ping the ip set in $serverip if this
 works, all input / output and errors are displayed on the netconsole.
 If it didn't work serial will be used to display everything.
 
 It's mainly addopted from some dockstar guides, but works without any
 problems. u-boot is slightly bigger, but works without problems (188984
 Bytes here).
 
 Hopefully it'll be addopted to the trunk, as this let's you maintain
 (and update) your openwrt without opening the box and adding a serial
 console.

Please send pull request for this patch to uboot git repo that Daniel
has on github [1].

How much this change increases the size of the binary?

Luka

[1] https://github.com/danielschwierzeck/u-boot-lantiq
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 3/3] [rpcd] file: free memory after opendir()

[Luka Perkov]

Signed-off-by: Luka Perkov l...@openwrt.org
---
 file.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/file.c b/file.c
index 9a3dfd8..31a937d 100644
--- a/file.c
+++ b/file.c
@@ -267,6 +267,8 @@ rpc_file_list(struct ubus_context *ctx, struct ubus_object 
*obj,
blobmsg_close_table(buf, d);
}
 
+   closedir(fd);
+
blobmsg_close_array(buf, c);
ubus_send_reply(ctx, req, buf.head);
blob_buf_free(buf);
-- 
2.3.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/3] [rpcd] file: show data ubus parameter only when used

[Luka Perkov]

The ubus calls for file read, list and stat do not use data parameter, so lets
remove them to avoid confusion.

Signed-off-by: Luka Perkov l...@openwrt.org
---
 file.c | 47 ---
 1 file changed, 28 insertions(+), 19 deletions(-)

diff --git a/file.c b/file.c
index e4c957e..fdc6396 100644
--- a/file.c
+++ b/file.c
@@ -69,14 +69,23 @@ struct rpc_file_exec_context {
 static struct blob_buf buf;
 
 enum {
-   RPC_F_PATH,
-   RPC_F_DATA,
-   __RPC_F_MAX,
+   RPC_F_R_PATH,
+   __RPC_F_R_MAX,
 };
 
-static const struct blobmsg_policy rpc_file_policy[__RPC_F_MAX] = {
-   [RPC_F_PATH] = { .name = path, .type = BLOBMSG_TYPE_STRING },
-   [RPC_F_DATA] = { .name = data, .type = BLOBMSG_TYPE_STRING },
+static const struct blobmsg_policy rpc_file_r_policy[__RPC_F_R_MAX] = {
+   [RPC_F_R_PATH] = { .name = path, .type = BLOBMSG_TYPE_STRING },
+};
+
+enum {
+   RPC_F_RW_PATH,
+   RPC_F_RW_DATA,
+   __RPC_F_RW_MAX,
+};
+
+static const struct blobmsg_policy rpc_file_rw_policy[__RPC_F_RW_MAX] = {
+   [RPC_F_RW_PATH] = { .name = path, .type = BLOBMSG_TYPE_STRING },
+   [RPC_F_RW_DATA] = { .name = data, .type = BLOBMSG_TYPE_STRING },
 };
 
 enum {
@@ -129,17 +138,17 @@ rpc_errno_status(void)
 static struct blob_attr **
 rpc_check_path(struct blob_attr *msg, char **path, struct stat *s)
 {
-   static struct blob_attr *tb[__RPC_F_MAX];
+   static struct blob_attr *tb[__RPC_F_R_MAX];
 
-   blobmsg_parse(rpc_file_policy, __RPC_F_MAX, tb, blob_data(msg), 
blob_len(msg));
+   blobmsg_parse(rpc_file_r_policy, __RPC_F_R_MAX, tb, blob_data(msg), 
blob_len(msg));
 
-   if (!tb[RPC_F_PATH])
+   if (!tb[RPC_F_R_PATH])
{
errno = EINVAL;
return NULL;
}
 
-   *path = blobmsg_data(tb[RPC_F_PATH]);
+   *path = blobmsg_data(tb[RPC_F_R_PATH]);
 
if (stat(*path, s))
return NULL;
@@ -203,18 +212,18 @@ rpc_file_write(struct ubus_context *ctx, struct 
ubus_object *obj,
struct blob_attr *msg)
 {
int fd;
-   struct blob_attr *tb[__RPC_F_MAX];
+   struct blob_attr *tb[__RPC_F_RW_MAX];
 
-   blobmsg_parse(rpc_file_policy, __RPC_F_MAX, tb,
+   blobmsg_parse(rpc_file_rw_policy, __RPC_F_RW_MAX, tb,
  blob_data(msg), blob_len(msg));
 
-   if (!tb[RPC_F_PATH] || !tb[RPC_F_DATA])
+   if (!tb[RPC_F_RW_PATH] || !tb[RPC_F_RW_DATA])
return UBUS_STATUS_INVALID_ARGUMENT;
 
-   if ((fd = open(blobmsg_data(tb[RPC_F_PATH]), O_CREAT | O_TRUNC | 
O_WRONLY))  0)
+   if ((fd = open(blobmsg_data(tb[RPC_F_RW_PATH]), O_CREAT | O_TRUNC | 
O_WRONLY))  0)
return rpc_errno_status();
 
-   if (write(fd, blobmsg_data(tb[RPC_F_DATA]), 
blobmsg_data_len(tb[RPC_F_DATA]))  0)
+   if (write(fd, blobmsg_data(tb[RPC_F_RW_DATA]), 
blobmsg_data_len(tb[RPC_F_RW_DATA]))  0)
return rpc_errno_status();
 
if (fsync(fd)  0)
@@ -592,10 +601,10 @@ static int
 rpc_file_api_init(const struct rpc_daemon_ops *o, struct ubus_context *ctx)
 {
static const struct ubus_method file_methods[] = {
-   UBUS_METHOD(read,rpc_file_read,  rpc_file_policy),
-   UBUS_METHOD(write,   rpc_file_write, rpc_file_policy),
-   UBUS_METHOD(list,rpc_file_list,  rpc_file_policy),
-   UBUS_METHOD(stat,rpc_file_stat,  rpc_file_policy),
+   UBUS_METHOD(read,rpc_file_read,  rpc_file_r_policy),
+   UBUS_METHOD(write,   rpc_file_write, rpc_file_rw_policy),
+   UBUS_METHOD(list,rpc_file_list,  rpc_file_r_policy),
+   UBUS_METHOD(stat,rpc_file_stat,  rpc_file_r_policy),
UBUS_METHOD(exec,rpc_file_exec,  rpc_exec_policy),
};
 
-- 
2.3.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/3] [rpcd] file: use blob_buf_free()

[Luka Perkov]

Signed-off-by: Luka Perkov l...@openwrt.org
---
 file.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/file.c b/file.c
index fdc6396..9a3dfd8 100644
--- a/file.c
+++ b/file.c
@@ -199,6 +199,7 @@ rpc_file_read(struct ubus_context *ctx, struct ubus_object 
*obj,
blobmsg_add_string_buffer(buf);
 
ubus_send_reply(ctx, req, buf.head);
+   blob_buf_free(buf);
rv = UBUS_STATUS_OK;
 
 out:
@@ -268,6 +269,7 @@ rpc_file_list(struct ubus_context *ctx, struct ubus_object 
*obj,
 
blobmsg_close_array(buf, c);
ubus_send_reply(ctx, req, buf.head);
+   blob_buf_free(buf);
 
return 0;
 }
@@ -307,6 +309,7 @@ rpc_file_stat(struct ubus_context *ctx, struct ubus_object 
*obj,
blobmsg_add_u32(buf, gid,   s.st_gid);
 
ubus_send_reply(ctx, req, buf.head);
+   blob_buf_free(buf);
 
return 0;
 }
@@ -393,6 +396,7 @@ rpc_file_exec_reply(struct rpc_file_exec_context *c, int rv)
rpc_ustream_to_blobmsg(c-epipe.stream, stderr);
 
ubus_send_reply(c-context, c-request, buf.head);
+   blob_buf_free(buf);
}
 
ubus_complete_deferred_request(c-context, c-request, rv);
-- 
2.3.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 3/3] sunxi: add support for Linux 3.19

[Luka Perkov]

Hi Daniel,

On Wed, Feb 11, 2015 at 12:13:13AM +0100, Daniel Golle wrote:
 On Tue, Feb 10, 2015 at 10:46:53PM +0100, John Crispin wrote:
  zoltan maintains the sunxi target. he might already have done work on
  this and might have some updates or whatever that he plans to
  incorporate. bumping a kernel maintained actively always has the risk
  of duplicating work and / or doing superfluous work
 
 Well, yes, that's why I put Zoltan on CC for that patch (you can't
 see that as the list server apparently removes CC's if the receiver
 is among the list subscribers).
 
 And sure, he might already have it ready himself or do things as he
 likes to, e.g. more testing on all boards before pushing the commit.
 I did this bump to 3.19 this morning because I was impatient to see if
 framebuffer works as it was promissed for 3.19 on sun7i. And it does.
 I was happy to see that and felt that it may make sense to publish my
 results.
 
 Note that my motivation when porting the patches was my own curiosity
 and it was fun doing it -- no matter, if any picks them up or not.
 Just in case Zoltan starts working on 3.19 tomorrow, he'll already have
 a reference point to start with.
 If he already got it ready and just wants to do more testing before
 pushing the commit -- fine, this might have been a waste of time when
 looking at it from an economic point of view. Just that my motiviation
 was self-education rather than just using my time as efficient as I can.
 
 Is there anything wrong with that?
 Or did anyone feel offended by that?

Not at all. Please continue with good work. I only wish I've seen your
patch sooner ;)

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

Re: [OpenWrt-Devel] [PATCH 1/3] kernel: 3.19 was released

[Luka Perkov]

Hi Daniel,

On Tue, Feb 10, 2015 at 03:04:16PM +0100, Daniel Golle wrote:
 Signed-off-by: Daniel Golle dan...@makrotopia.org
 ---
  include/kernel-version.mk | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

I already started working on this on my own... I've added your SoB in
the commit message. The bump has been pushed in r44381. Thanks!

Luka

PS. I did not merge 3/3. I'll leave that to platform maintainer.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] kirkwood: add wpad-mini to guruplug profile

[Luka Perkov]

Hi Nathan,

On Fri, Jan 23, 2015 at 09:20:01PM -0800, Nathan Hintz wrote:
 Signed-off-by: Nathan Hintz nlhi...@hotmail.com
 ---
  target/linux/kirkwood/profiles/120-plug.mk | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

Applied in r44125. Thank you!

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

Re: [OpenWrt-Devel] [PATCH 3/3] kirkwood: enable swconfig by default on EA3500

[Luka Perkov]

Hi Claudio,

On Fri, Jan 23, 2015 at 08:27:44PM -0500, Claudio Leite wrote:
 Signed-off-by: Claudio Leite lei...@staticky.com
 ---
  target/linux/kirkwood/profiles/115-router.mk | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

Applied in r44124. Thank you!

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

Re: [OpenWrt-Devel] [PATCH 1/3] kirkwood: drop port-based VLAN setup

[Luka Perkov]

Hi Claudio,

On Fri, Jan 23, 2015 at 08:27:42PM -0500, Claudio Leite wrote:
 Using port-based VLANs depends on a non-standard
 swconfig parameter, which compilcates things like
 LuCI that don't know about it. This patch changes
 the default to use 802.1q VLANs internally in the
 switch, but without tagging packets since we have
 two Ethernet ports.
 
 iperf3 tests indicate no difference in performance
 versus port-based VLANs when the CPU port is not
 using tags.
 
 Signed-off-by: Claudio Leite lei...@staticky.com
 ---
  .../base-files/etc/uci-defaults/02_network | 25 
 ++
  1 file changed, 6 insertions(+), 19 deletions(-)

Applied in r44122. Thank you.

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

Re: [OpenWrt-Devel] [PATCH 2/3] kirkwood: fix EA3500 ubi options

[Luka Perkov]

Hi Claudio,

On Fri, Jan 23, 2015 at 08:27:43PM -0500, Claudio Leite wrote:
 Previous options resulted in a nonfunctional image.
 
 Signed-off-by: Claudio Leite lei...@staticky.com
 ---
  target/linux/kirkwood/profiles/115-router.mk | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

Applied in r44123. Thank you!

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

Re: [OpenWrt-Devel] [PATCH 2/2] package: add timer led function

[Luka Perkov]

Hi Gerald,

On Tue, Jan 20, 2015 at 02:20:09PM +0100, drEagle wrote:
 Same with this another patch.
 Is it missed or lost ?
 I do not find any trace at patchworks.
 
 Do you need that I resubmit it ?

Both patches have been merged. Please re-sync your tree.

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

Re: [OpenWrt-Devel] [PATCH 2/2] kirkwood: enable switch on Linksys EA3500

[Luka Perkov]

On Sun, Jan 18, 2015 at 10:33:51AM -0500, Claudio Leite wrote:
 Signed-off-by: Claudio Leite lei...@staticky.com
 ---
  .../linux/kirkwood/base-files/etc/uci-defaults/02_network |3 +++
  target/linux/kirkwood/patches-3.14/170-ea3500.patch   |   13 
 -
  target/linux/kirkwood/patches-3.18/170-ea3500.patch   |   13 
 -
  3 files changed, 27 insertions(+), 2 deletions(-)

Applied in r44036. Thank you.

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

Re: [OpenWrt-Devel] [PATCH 1/2] uboot-envtools: fix Linksys EA3500 env size

[Luka Perkov]

On Sun, Jan 18, 2015 at 10:33:50AM -0500, Claudio Leite wrote:
 Signed-off-by: Claudio Leite lei...@staticky.com
 ---
  package/boot/uboot-envtools/files/kirkwood |4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

Applied in r44037. Thank you.

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

Re: [OpenWrt-Devel] [PATCH] mdns: install uci package as config

[Luka Perkov]

On Wed, Jan 14, 2015 at 10:56:02AM +0100, Alexander Couzens wrote:
 Signed-off-by: Alexander Couzens lyn...@fe80.eu
 ---
  package/network/services/mdns/Makefile | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

Applied in r43967. Thanks!

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

Re: [OpenWrt-Devel] [PATCH 1/4] mvsw6171: rename to 'mvsw61xx'

[Luka Perkov]

Hi Claudio,

On Fri, Jan 09, 2015 at 12:12:47PM -0500, Claudio Leite wrote:
 In preparation for properly supporting switches
 beyond the 88E6171.
 
 Signed-off-by: Claudio Leite lei...@staticky.com
 ---

Series applied in r43935-r43938. I added minor modifications to mvebu
target in the first patch. Thank you!

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

Re: [OpenWrt-Devel] [PATCH] [mvebu] use mvsw61xx

[Luka Perkov]

Hi Mark,

On Fri, Jan 09, 2015 at 04:21:10PM -0700, Mark Milburn wrote:
 Use Claudio's renamed mvsw6171 driver.
 Depends upon https://patchwork.ozlabs.org/patch/427183/ patchset.
 
 Signed-off-by: Mark Milburn mark.a.milb...@gmail.com
 ---
  target/linux/mvebu/config-3.14 | 2 +-
  target/linux/mvebu/config-3.18 | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

Applied as a part of r43938. Thank you!

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

Re: [OpenWrt-Devel] [PATCH RESEND 2/2] kirkwood: Iomega ix2-200: use all remaining MTD space for rootfs

[Luka Perkov]

On Wed, Dec 10, 2014 at 11:30:24AM +0100, John Crispin wrote:
  The second one won't be accepted upstream because it is OpenWrt
  specific, while the first one can and should be sent upstream.
 
 for trivial stuff we never had a upstream first policy. maybe it was
 decided to put one in place and i missed it. in general it is much
 better to ask people to send it upstream in parallel.
 
 consider the case where contributor might not know how to do so or runs
 into some other problem. this would result in the feature not hitting
 openwrt.
 
 personally i merge ask for upstream and when i bump the next time i see
 if it happened or i will do so myself.

Sounds reasonable. Lets give Richard a day or two to reply.

I still need to finish kirkwood 3.18 bump and will put the patch there
too...

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

Re: [OpenWrt-Devel] [PATCH RESEND 1/2] kirkwood: Iomega ix2-200: wire up the GPIO poweroff driver in the DTS file

[Luka Perkov]

Hi Richard,

On Mon, Dec 08, 2014 at 10:41:28PM +0100, Richard Kunze wrote:
 Signed-off-by: Richard Kunze richard.ku...@web.de
 ---
  .../linux/kirkwood/patches-3.14/171-ix2_200_poweroff.patch  | 13 
 +
  1 file changed, 13 insertions(+)
  create mode 100644 
 target/linux/kirkwood/patches-3.14/171-ix2_200_poweroff.patch

Did you send this to linux kernel arm mailing list? If not please do
that and ping me after. Thanks.

Luka

 diff --git a/target/linux/kirkwood/patches-3.14/171-ix2_200_poweroff.patch 
 b/target/linux/kirkwood/patches-3.14/171-ix2_200_poweroff.patch
 new file mode 100644
 index 000..62f244c
 --- /dev/null
 +++ b/target/linux/kirkwood/patches-3.14/171-ix2_200_poweroff.patch
 @@ -0,0 +1,13 @@
 +--- a/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts
  b/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts
 +@@ -168,6 +168,10 @@
 + gpios = gpio1 3 GPIO_ACTIVE_LOW;
 + };
 + };
 ++gpio-poweroff {
 ++compatible = gpio-poweroff;
 ++gpios = gpio0 17 GPIO_ACTIVE_LOW;
 ++};
 + };
 + 
 + nand {
 -- 
 1.9.1
 ___
 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] [PATCH RESEND 2/2] kirkwood: Iomega ix2-200: use all remaining MTD space for rootfs

[Luka Perkov]

Hi Richard,

On Mon, Dec 08, 2014 at 10:41:29PM +0100, Richard Kunze wrote:
 Signed-off-by: Richard Kunze richard.ku...@web.de
 ---
  .../kirkwood/patches-3.14/172-ix2_200-fix-mtd-layout.patch  | 13 
 +
  1 file changed, 13 insertions(+)
  create mode 100644 
 target/linux/kirkwood/patches-3.14/172-ix2_200-fix-mtd-layout.patch

Applied with minor changes in r43590. Thank you!

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

Re: [OpenWrt-Devel] [PATCH] util-linux: package libsmartcols

[Luka Perkov]

On Mon, Dec 01, 2014 at 01:07:38PM +0100, John Crispin wrote:
 patch does not apply, which rev did you generate it against ?

It applied just fine here on the latest trunk.

 On 01/12/2014 13:06, Daniel Golle wrote:
  Packages fdisk and lsblk were missing dependency for libsmartcols.so.1
 
  Add package for libsmartcols and add dependency from fdisk and lsblk.
 
  Signed-off-by: Daniel Golle dan...@makrotopia.org
  ---
   package/utils/util-linux/Makefile | 27 ---
   1 file changed, 24 insertions(+), 3 deletions(-)

Applied in r43459. Thanks!

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

Re: [OpenWrt-Devel] [PATCH] kirkwood: change CRC32 implementation to CRC32_SLICEBY8

[Luka Perkov]

Hi Richard,

On Sat, Nov 29, 2014 at 11:37:38PM +0100, Richard Kunze wrote:
 At least on my Iomega ix2-200 system, this makes btrfs writes about 30%
 faster.
 
 Signed-off-by: Richard Kunze richard.ku...@web.de
 ---
  target/linux/kirkwood/config-3.14 | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

Applied in r43434. Thank you!

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

[OpenWrt-Devel] [PATCH] [procd] initd: mount cgroup

[Luka Perkov]

If kernel is compiled with cgroup support it should be mounted. This change
does not effect kernels without cgroup support.

Signed-off-by: Luka Perkov l...@openwrt.org
---

I'd prefer to put this here rather then having init script which does the same.

 initd/early.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/initd/early.c b/initd/early.c
index a9f6afb..c622aec 100644
--- a/initd/early.c
+++ b/initd/early.c
@@ -29,6 +29,7 @@ early_mounts(void)
 {
mount(proc, /proc, proc, MS_NOATIME, 0);
mount(sysfs, /sys, sysfs, MS_NOATIME, 0);
+   mount(none, /sys/fs/cgroup, cgroup, 0, 0);
 
mount(tmpfs, /tmp, tmpfs, MS_NOSUID | MS_NODEV | MS_NOATIME, 
NULL);
mkdir(/tmp/run, 0777);
-- 
2.1.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] lantiq vr9 and fxs

[Luka Perkov]

Hi Eddi,

On Tue, Nov 11, 2014 at 04:10:30PM +0100, Eddi De Pieri wrote:
 asterisk:
 set debug output on console
 console = notice,warning,error,debug
 
 so, all software recognize correctly the correct port
 
 [Nov 11 15:08:06] DEBUG[894]: chan_lantiq.c:835 lantiq_dev_event_hook: on
 port 0 detected event off hook
 [Nov 11 15:08:10] DEBUG[894]: chan_lantiq.c:835 lantiq_dev_event_hook: on
 port 0 detected event on hook
 [Nov 11 15:08:24] DEBUG[894]: chan_lantiq.c:835 lantiq_dev_event_hook: on
 port 1 detected event off hook
 [Nov 11 15:08:26] DEBUG[894]: chan_lantiq.c:835 lantiq_dev_event_hook: on
 port 1 detected event on hook
 
 but both owsip and asterisk route call to TAPI/1 (and never TAPI/2)

I don't remember if that worked on owsip. But asterisk should support
both channels.

What about TAPI/0? I am unsure if we started naming the channels from 0
or 1...

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

Re: [OpenWrt-Devel] lantiq vr9 and fxs

[Luka Perkov]

Hi Eddi,

On Tue, Nov 11, 2014 at 07:11:13PM +0100, Eddi De Pieri wrote:
 it seems it work better in this way...
 
 chan = ast_channel_alloc(1, state, NULL, NULL, , ext, ctx, 0, c,
 TAPI/%d, (c + 1));
 
 I don't know so well asterisk programming... please let me know if it seems
 correct to you!

I'm not sure. Why don't you use 'TAPI/%d, c' so the naming starts with 0?

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

Re: [OpenWrt-Devel] Pogoplug V4 support

[Luka Perkov]

On Sat, Oct 25, 2014 at 10:00:33PM +, nwf wrote:
 Salutations openwrt-devel@,
 
 I've gotten an initial Pogoplug V4 build into good enough shape that I think
 it's worth sharing.  It uses a lightly-tweaked fork of uBoot for the moment
 (though I'm hoping the tweaks eventually make it back into mainline) and uses
 FDT to bring up the kernel.  Thoughts are welcome.

This patch should be split into two. One for the kernel part and one for
the uboot package. Also, don't create a new uboot-kirkwood-mibodhi
package - the existing uboot-kirkwood should be patched instead.

Luka

 --nwf;
 
 
 diff --git a/package/boot/uboot-kirkwood-mibodhi/Makefile 
 b/package/boot/uboot-kirkwood-mibodhi/Makefile
 new file mode 100644
 index 000..6855a91
 --- /dev/null
 +++ b/package/boot/uboot-kirkwood-mibodhi/Makefile
 @@ -0,0 +1,103 @@
 +#
 +# Copyright (C) 2010-2014 OpenWrt.org
 +#
 +# This is free software, licensed under the GNU General Public License v2.
 +# See /LICENSE for more information.
 +#
 +
 +include $(TOPDIR)/rules.mk
 +
 +PKG_NAME:=u-boot
 +PKG_VERSION:=2014.07-mibodhi
 +PKG_RELEASE:=1
 +
 +PKG_SOURCE_URL:=g...@github.com:nwf/u-boot-kirkwood.git
 +PKG_SOURCE_PROTO:=git
 +PKG_SOURCE_VERSION:=23217407aab5494d7c17b0c5b0b1aabb13e4c26e
 +PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
 +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.gz
 +
 +PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)-$(BUILD_VARIANT)/$(PKG_NAME)-$(PKG_VERSION)
 +
 +PKG_BUILD_PARALLEL:=1
 +
 +include $(INCLUDE_DIR)/package.mk
 +
 +define uboot/Default
 +  TITLE:=
 +  CONFIG:=
 +  IMAGE:=
 +endef
 +
 +define uboot/pogo4
 +  TITLE:=U-Boot for Cloud Engines Pogoplug V4
 +  CONFIG:=pogo_v4
 +endef
 +
 +UBOOTS:= pogo4
 +
 +define Package/uboot/template
 +define Package/uboot-kirkwood-$(1)
 +  SECTION:=boot
 +  CATEGORY:=Boot Loaders
 +  DEPENDS:=@TARGET_kirkwood
 +  TITLE:=$(2)
 +  URL:=http://www.denx.de/wiki/U-Boot
 +  VARIANT:=$(1)
 +endef
 +endef
 +
 +define BuildUBootPackage
 + $(eval $(uboot/Default))
 + $(eval $(uboot/$(1)))
 + $(call Package/uboot/template,$(1),$(TITLE))
 +endef
 +
 +ifdef BUILD_VARIANT
 +$(eval $(call uboot/$(BUILD_VARIANT)))
 +UBOOT_CONFIG:=$(if $(CONFIG),$(CONFIG),$(BUILD_VARIANT))
 +UBOOT_IMAGE:=$(if 
 $(IMAGE),$(IMAGE),openwrt-$(BOARD)-$(BUILD_VARIANT)-u-boot.bin)
 +endif
 +
 +define Build/Configure
 + +$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) \
 + $(UBOOT_CONFIG)_config
 +endef
 +
 +define Build/Compile
 + +$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) \
 + u-boot.kwb \
 + CROSS_COMPILE=$(TARGET_CROSS)
 + mkimage -A $(ARCH) -O linux -T kernel -C none \
 + -a 0x60 -e 0x60 \
 + -n 'OpenWrt Das U-Boot uImage' \
 + -d $(PKG_BUILD_DIR)/u-boot.bin $(PKG_BUILD_DIR)/u-boot.img
 +endef
 +
 +define Package/uboot/install/default
 + $(INSTALL_DIR) $(BIN_DIR)/uboot-$(BOARD)-$(1)
 + $(CP) $(PKG_BUILD_DIR)/u-boot.bin \
 + $(BIN_DIR)/uboot-$(BOARD)-$(1)/openwrt-$(BOARD)-$(1)-u-boot.bin
 + $(CP) $(PKG_BUILD_DIR)/u-boot.kwb \
 + $(BIN_DIR)/uboot-$(BOARD)-$(1)/openwrt-$(BOARD)-$(1)-u-boot.kwb
 + $(CP) $(PKG_BUILD_DIR)/u-boot.img \
 + $(BIN_DIR)/uboot-$(BOARD)-$(1)/openwrt-$(BOARD)-$(1)-u-boot.img
 + $(INSTALL_DIR) $(BIN_DIR)/u-boot-kwboot/
 + $(CP) $(PKG_BUILD_DIR)/tools/kwboot \
 + $(BIN_DIR)/u-boot-kwboot/
 +endef
 +
 +define Package/uboot/install/template
 +define Package/uboot-kirkwood-$(1)/install
 + $(call Package/uboot/install/default,$(2))
 +endef
 +endef
 +
 +$(foreach u,$(UBOOTS), \
 + $(eval $(call Package/uboot/install/template,$(u),$(u))) \
 +)
 +
 +$(foreach u,$(UBOOTS), \
 + $(eval $(call BuildUBootPackage,$(u))) \
 + $(eval $(call BuildPackage,uboot-kirkwood-$(u))) \
 +)
 diff --git 
 a/package/boot/uboot-kirkwood-mibodhi/patches/200-openwrt-config.patch 
 b/package/boot/uboot-kirkwood-mibodhi/patches/200-openwrt-config.patch
 new file mode 100644
 index 000..8abbfe6
 --- /dev/null
 +++ b/package/boot/uboot-kirkwood-mibodhi/patches/200-openwrt-config.patch
 @@ -0,0 +1,109 @@
 +--- /dev/null
  b/include/configs/openwrt-kirkwood-common.h
 +@@ -0,0 +1,47 @@
 ++/*
 ++ * Copyright (C) 2013 Luka Perkov l...@openwrt.org
 ++ *
 ++ * SPDX-License-Identifier: GPL-2.0+
 ++ */
 ++
 ++#ifndef __OPENWRT_KIRKWOOD_COMMON_H
 ++#define __OPENWRT_KIRKWOOD_COMMON_H
 ++
 ++/* Commands */
 ++#define CONFIG_CMD_BOOTZ
 ++
 ++#if defined(CONFIG_CMD_NET)
 ++#define CONFIG_CMD_DHCP
 ++#define CONFIG_CMD_PING
 ++#endif
 ++
 ++/* Auto boot */
 ++#undef CONFIG_BOOTDELAY
 ++#define CONFIG_BOOTDELAY3
 ++
 ++/* Ethernet */
 ++#if defined(CONFIG_CMD_NET)
 ++#define CONFIG_SERVERIP 192.168.1.2
 ++#define CONFIG_IPADDR   192.168.1.1
 ++#endif
 ++
 ++/* second stage loader */
 ++#if defined(CONFIG_SECOND_STAGE)
 ++#undef CONFIG_ENV_IS_IN_NAND
 ++#undef CONFIG_ENV_SECT_SIZE
 ++#define CONFIG_ENV_IS_NOWHERE
 ++#endif

Re: [OpenWrt-Devel] [PATCH] kirkwood: add support for Linksys EA3500

[Luka Perkov]

Hi Dan,

On Wed, Oct 15, 2014 at 09:11:39AM -0500, Dan Walters wrote:
 Support for the Linksys EA3500.  Here's the patch, and I entered the
 basic device info (including the serial console connections) on the
 wiki at http://wiki.openwrt.org/toh/linksys/ea3500 .  Hope it can be
 of use to someone else, I know I've been waiting a long while to run
 OpenWRT on my router!
 
 -Dan
 
 Signed-off-by: Dan Walters d...@walters.io
 
 ---
  package/boot/uboot-envtools/files/kirkwood |   1 +
  .../kirkwood/base-files/etc/uci-defaults/01_leds   |   3 +
  .../base-files/etc/uci-defaults/02_network |   3 +
  target/linux/kirkwood/base-files/lib/kirkwood.sh   |   4 +
  target/linux/kirkwood/image/Makefile   |   3 +
  .../linux/kirkwood/patches-3.14/170-ea3500.patch   | 164 
 +
  target/linux/kirkwood/profiles/115-router.mk   |  16 ++
  7 files changed, 194 insertions(+)
  create mode 100644 target/linux/kirkwood/patches-3.14/170-ea3500.patch


Applied with minor cosmetic changes in r43230. Thank you.

Luka

PS. Please run 'make target/linux/refresh' next time before sending the
patch.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [RFC] imx6: fix image build for Generic profile.

[Luka Perkov]

Hi Yousong,

On Mon, Sep 08, 2014 at 03:33:53PM +0800, Yousong Zhou wrote:
 Signed-off-by: Yousong Zhou yszhou4t...@gmail.com
 ---
 I do not own a board that can run imx6 target firmware, but this patch has
 been compile tested by myself and aandrew in #openwrt.
 
  target/linux/imx6/image/Makefile |   12 +++-
  1 file changed, 7 insertions(+), 5 deletions(-)

Applied in r42455. Thanks!

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

Re: [OpenWrt-Devel] [PATCH 1/3] build: add support for options

[Luka Perkov]

On Tue, Aug 12, 2014 at 01:02:06PM +0200, Jonas Gorski wrote:
 On Mon, Aug 11, 2014 at 8:58 PM, Luka Perkov l...@openwrt.org wrote:
  On Mon, Aug 11, 2014 at 06:59:15PM +0200, Jonas Gorski wrote:
  On Mon, Aug 11, 2014 at 6:34 PM, Luka Perkov l...@openwrt.org wrote:
   On Mon, Aug 11, 2014 at 05:24:32PM +0200, Jonas Gorski wrote:
   On Mon, Aug 11, 2014 at 5:06 PM, Luka Perkov l...@openwrt.org wrote:
On Mon, Aug 11, 2014 at 03:21:58PM +0200, Jonas Gorski wrote:
And further, in your approach you directly select the options, not
just change the defaults (in contrast to the default packages), so 
you
can't even deselect them anymore.
   
You can deselect options with this series. That was the goal and that 
is
why there are HAVE_* options present. Give it a try.
  
   So what is the difference to FEATURES:= then? These already select
   different HAVE_FOO things. Can't you just add the missing features
   there?
  
   FEATURES nor DEPENDS are not good candidates for this. They are global
   for target/subtarget. So you can not define in same target/subtarget for
   one profile to include only zImage and for other to include only uImage.
  
   You can see that does not work if you look how Freescale i.MX23/i.MX28
   (mxs) now behaves.
 
  So the clean solution is to make them both work at the same time, not
  to add additional workarounds. Correct image generation should not
  depend on profile selection. All these options currently alter the way
  the single (ubi) rootfs is generated, while they should enable
  different rootfs variants to be generated at the same time. This is
  the root issue, and this is where it should be fixed. Yes, it isn't
  easy to fix, but we should not break it further.
 
  I agree with you but this does not only solve ubi image generation
  problem. As explained before with this we can enable other options as
  well, thus once we have better fix for ubi images we can keep this for
  other purposes.
 
 Can you please provide an example of a current configuration option we
 would want to enable from a profile?

Look at 3/3.

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

Re: [OpenWrt-Devel] [PATCH 2/3] build: use options to add kernels/dtbs in rootfs

[Luka Perkov]

On Tue, Aug 12, 2014 at 01:12:50PM +0200, Jonas Gorski wrote:
 On Mon, Aug 11, 2014 at 10:48 PM, Luka Perkov l...@openwrt.org wrote:
  On Mon, Aug 11, 2014 at 10:06:27PM +0200, Felix Fietkau wrote:
  On 2014-08-11 10:47, Luka Perkov wrote:
   Use support for options to enable targets and profiles select kernel or 
   dtb
   inclusion by default.
  
   Signed-off-by: Luka Perkov l...@openwrt.org
  What's the rationale for having this stuff as config options in the
  first place? It seems to me that it makes a lot more sense to control
  this from the target's image/Makefile.
 
  Here are the reasons:
 
  * Simplified image/Makefile for targets, no extra ifdefs
 
 .. which makes it impossible to build images for both a device needing
 it and a device not needing it at the same time.
 
... but that is how build system works now. This patch series is not a
stopper for the the fix of the problem you are pointing out here. If you
have better way to deal with this feel free to send a patch. And don't
forget to take in account third point below.

  * Users can select if they want to include kernel/dtb or not - it is not
  hardcoded in the image/Makefile. For example, if one is building ramdisk
  image only no need to include kernel in rootfs.
 
 As a user, I would not want to have to make that decision. Either the
 device needs the kernel in the rootfs, then it should be automatically
 included, or it does not, then it shoudn't be there. If it isn't
 needed for initramfs kernels, then selection state shouldn't have any
 effect on the ramdisk contents.

Then as a user don't touch default settings ;)

  * Introduces ground work for including other options which can not be
  built as modules. Such as lxc/kexec support by default.
 
 As I said on 1/3, lxc/kexec is a bad example. An IB built with profile
 A selected and an IB built with profile B selected should be able to
 create identical* images, regardless of which profile was selected
 while building the IB.

As explained in the other email lxc/kexec would be set at target level
and not on the profile level. That said, the point you are making does
not make any sense to me.

 Jonas
 * apart from time stamps

And user who run the build and machine it was built on. If we get picky
we could probably find couple of other things.

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

Re: [OpenWrt-Devel] [PATCH 1/3] build: add support for options

[Luka Perkov]

On Tue, Aug 12, 2014 at 01:30:49PM +0200, Jonas Gorski wrote:
 On Tue, Aug 12, 2014 at 1:25 PM, Luka Perkov l...@openwrt.org wrote:
  On Tue, Aug 12, 2014 at 01:02:06PM +0200, Jonas Gorski wrote:
  On Mon, Aug 11, 2014 at 8:58 PM, Luka Perkov l...@openwrt.org wrote:
   On Mon, Aug 11, 2014 at 06:59:15PM +0200, Jonas Gorski wrote:
   On Mon, Aug 11, 2014 at 6:34 PM, Luka Perkov l...@openwrt.org wrote:
On Mon, Aug 11, 2014 at 05:24:32PM +0200, Jonas Gorski wrote:
On Mon, Aug 11, 2014 at 5:06 PM, Luka Perkov l...@openwrt.org 
wrote:
 On Mon, Aug 11, 2014 at 03:21:58PM +0200, Jonas Gorski wrote:
 And further, in your approach you directly select the options, not
 just change the defaults (in contrast to the default packages), 
 so you
 can't even deselect them anymore.

 You can deselect options with this series. That was the goal and 
 that is
 why there are HAVE_* options present. Give it a try.
   
So what is the difference to FEATURES:= then? These already select
different HAVE_FOO things. Can't you just add the missing features
there?
   
FEATURES nor DEPENDS are not good candidates for this. They are global
for target/subtarget. So you can not define in same target/subtarget 
for
one profile to include only zImage and for other to include only 
uImage.
   
You can see that does not work if you look how Freescale i.MX23/i.MX28
(mxs) now behaves.
  
   So the clean solution is to make them both work at the same time, not
   to add additional workarounds. Correct image generation should not
   depend on profile selection. All these options currently alter the way
   the single (ubi) rootfs is generated, while they should enable
   different rootfs variants to be generated at the same time. This is
   the root issue, and this is where it should be fixed. Yes, it isn't
   easy to fix, but we should not break it further.
  
   I agree with you but this does not only solve ubi image generation
   problem. As explained before with this we can enable other options as
   well, thus once we have better fix for ubi images we can keep this for
   other purposes.
 
  Can you please provide an example of a current configuration option we
  would want to enable from a profile?
 
  Look at 3/3.
 
 I thought we already agreed that these are not good configuration
 options.

I do not agree. If you have not noticed we already have those as configuration
options. Now I am just trying to set proper defaults.

 I rather meant outside of these, that would make an argument that this is
 anything more than just adding a hackfix for a hackfix.

Well, I think we should have different rootfs directories for profiles. But
this series does not only address that problem.

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

[OpenWrt-Devel] [PATCH 1/3] build: add support for options

[Luka Perkov]

This patch adds support for target DEFAULT_OPTIONS and profile OPTIONS
variables. Those are simmilar to existing DEFAULT_PACKAGES and PACKAGES
but one can use them to select other options by default in menuconfig.

Signed-off-by: Luka Perkov l...@openwrt.org
---
 include/target.mk   |  4 
 scripts/metadata.pl | 12 ++--
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/include/target.mk b/include/target.mk
index e36cdd6..20179d1 100644
--- a/include/target.mk
+++ b/include/target.mk
@@ -11,6 +11,7 @@ __target_inc=1
 # default device type
 DEVICE_TYPE?=router
 
+DEFAULT_OPTIONS:=
 # Default packages - the really basic set
 DEFAULT_PACKAGES:=base-files libc libgcc busybox dropbear mtd uci opkg netifd 
fstools
 # For router targets
@@ -56,6 +57,7 @@ extra_packages = $(if $(filter wpad-mini wpad 
nas,$(1)),iwinfo)
 
 define Profile/Default
   NAME:=
+  OPTIONS:=
   PACKAGES:=
 endef
 
@@ -68,6 +70,7 @@ define Profile
   DUMPINFO += \
echo Target-Profile: $(1); \
echo Target-Profile-Name: $(NAME); \
+   echo Target-Profile-Options: $(OPTIONS); \
echo Target-Profile-Packages: $(PACKAGES) $(call 
extra_packages,$(DEFAULT_PACKAGES) $(PACKAGES)); \
if [ -f ./config/profile-$(1) ]; then \
echo Target-Profile-Kconfig: yes; \
@@ -276,6 +279,7 @@ define BuildTargets/DumpCurrent
 echo 'Target-Description:'; \
 $(SH_FUNC) getvar $(call shvar,Target/Description); \
 echo '@@'; \
+echo 'Default-Options: $(DEFAULT_OPTIONS)'; \
 echo 'Default-Packages: $(DEFAULT_PACKAGES) $(call 
extra_packages,$(DEFAULT_PACKAGES))'; \
 $(DUMPINFO)
$(if $(SUBTARGET),,@$(foreach SUBTARGET,$(SUBTARGETS),$(SUBMAKE) -s 
DUMP=1 SUBTARGET=$(SUBTARGET); ))
diff --git a/scripts/metadata.pl b/scripts/metadata.pl
index 79f930c..d7d168d 100755
--- a/scripts/metadata.pl
+++ b/scripts/metadata.pl
@@ -58,16 +58,19 @@ sub parse_target_metadata() {
/^Linux-Release:\s*(.+)\s*$/ and $target-{release} = $1;
/^Linux-Kernel-Arch:\s*(.+)\s*$/ and $target-{karch} = $1;
/^Default-Subtarget:\s*(.+)\s*$/ and $target-{def_subtarget} = 
$1;
+   /^Default-Options:\s*(.+)\s*$/ and $target-{options} = [ 
split(/\s+/, $1) ];
/^Default-Packages:\s*(.+)\s*$/ and $target-{packages} = [ 
split(/\s+/, $1) ];
/^Target-Profile:\s*(.+)\s*$/ and do {
$profile = {
id = $1,
name = $1,
+   options = [],
packages = []
};
push @{$target-{profiles}}, $profile;
};
/^Target-Profile-Name:\s*(.+)\s*$/ and $profile-{name} = $1;
+   /^Target-Profile-Options:\s*(.*)\s*$/ and $profile-{options} = 
[ split(/\s+/, $1) ];
/^Target-Profile-Packages:\s*(.*)\s*$/ and $profile-{packages} 
= [ split(/\s+/, $1) ];
/^Target-Profile-Description:\s*(.*)\s*/ and $profile-{desc} = 
get_multiline(*FILE);
/^Target-Profile-Config:/ and $profile-{config} = 
get_multiline(*FILE, \t);
@@ -83,6 +86,7 @@ sub parse_target_metadata() {
{
id = 'Default',
name = 'Default',
+   options = [],
packages = []
}
];
@@ -138,7 +142,7 @@ sub gen_kconfig_overrides() {
}
 }
 
-sub merge_package_lists($$) {
+sub merge_lists($$) {
my $list1 = shift;
my $list2 = shift;
my @l = ();
@@ -331,7 +335,11 @@ config TARGET_$target-{conf}_$profile-{id}
 $profile-{config}
 EOF
$profile-{kconfig} and print \tselect 
PROFILE_KCONFIG\n;
-   my @pkglist = merge_package_lists($target-{packages}, 
$profile-{packages});
+   my @optlist = merge_lists($target-{options}, 
$profile-{options});
+   foreach my $opt (@optlist) {
+   print \tselect $opt\n;
+   }
+   my @pkglist = merge_lists($target-{packages}, 
$profile-{packages});
foreach my $pkg (@pkglist) {
print \tselect DEFAULT_$pkg\n;
$defaults{$pkg} = 1;
-- 
2.0.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/3] build: use options to add kernels/dtbs in rootfs

[Luka Perkov]

Use support for options to enable targets and profiles select kernel or dtb
inclusion by default.

Signed-off-by: Luka Perkov l...@openwrt.org
---
 config/Config-images.in  | 49 
 target/linux/mxs/profiles/01-duckbill.mk |  5 +++-
 2 files changed, 41 insertions(+), 13 deletions(-)

diff --git a/config/Config-images.in b/config/Config-images.in
index 39e51e4..2509e09 100644
--- a/config/Config-images.in
+++ b/config/Config-images.in
@@ -274,44 +274,69 @@ menu Target Images
  you probably want the default (/dev/sda2).
 
 
+   config HAVE_TARGET_ROOTFS_INCLUDE_KERNEL
+   bool
+   default n
+
menuconfig TARGET_ROOTFS_INCLUDE_KERNEL
bool Include kernel in root filesystem
depends on TARGET_ROOTFS_UBIFS || TARGET_ROOTFS_EXT4FS
-   default n
+   default y if HAVE_TARGET_ROOTFS_INCLUDE_KERNEL
help
- Include the kernel image in the rootfs. Typically the image 
is placed
- below /boot.
+ Include the kernel image in the rootfs. Typically the image
+ is placed below /boot.
+
+
+   if TARGET_ROOTFS_INCLUDE_KERNEL
+
+   config HAVE_TARGET_ROOTFS_INCLUDE_UIMAGE
+   bool
+   default n
 
config TARGET_ROOTFS_INCLUDE_UIMAGE
-   bool include uImage if TARGET_ROOTFS_INCLUDE_KERNEL
-   default y
+   bool include uImage
+   default y if HAVE_TARGET_ROOTFS_INCLUDE_UIMAGE
help
  This option might not apply to all targets. Make sure
  to check target/linux/your_target/image/Makefile to
  see if this option will have any effect.
 
+   config HAVE_TARGET_ROOTFS_INCLUDE_ZIMAGE
+   bool
+   default n
+
config TARGET_ROOTFS_INCLUDE_ZIMAGE
-   bool include zImage if TARGET_ROOTFS_INCLUDE_KERNEL
-   default y
+   bool include zImage
+   default y if HAVE_TARGET_ROOTFS_INCLUDE_ZIMAGE
help
  This option might not apply to all targets. Make sure
  to check target/linux/your_target/image/Makefile to
  see if this option will have any effect.
 
+   config HAVE_TARGET_ROOTFS_INCLUDE_FIT
+   bool
+   default n
+
config TARGET_ROOTFS_INCLUDE_FIT
-   bool include FIT if TARGET_ROOTFS_INCLUDE_KERNEL
-   default y
+   bool include FIT
+   default y if HAVE_TARGET_ROOTFS_INCLUDE_FIT
help
  This option might not apply to all targets. Make sure
  to check target/linux/your_target/image/Makefile to
  see if this option will have any effect.
 
+   endif # TARGET_ROOTFS_INCLUDE_KERNEL
+
+   config HAVE_TARGET_ROOTFS_INCLUDE_DTB
+   bool
+   default n
+
config TARGET_ROOTFS_INCLUDE_DTB
bool Include DTB in root filesystem
depends on USES_DEVICETREE  (TARGET_ROOTFS_UBIFS || 
TARGET_ROOTFS_EXT4FS)
-   default n
+   default y if HAVE_TARGET_ROOTFS_INCLUDE_DTB
help
- Include the device tree blob file(s) in the rootfs. Typically 
the DTBs
- are placed below /boot.
+ Include the device tree blob file(s) in the rootfs. Typically
+ the DTBs are placed below /boot.
 
 endmenu
diff --git a/target/linux/mxs/profiles/01-duckbill.mk 
b/target/linux/mxs/profiles/01-duckbill.mk
index 3f75a7a..ac3206d 100644
--- a/target/linux/mxs/profiles/01-duckbill.mk
+++ b/target/linux/mxs/profiles/01-duckbill.mk
@@ -7,8 +7,11 @@
 
 define Profile/duckbill
   NAME:=I2SE Duckbill boards
-  DEPENDS:=+@TARGET_ROOTFS_INCLUDE_KERNEL +@TARGET_ROOTFS_INCLUDE_DTB
   FEATURES+=usbgadget
+  OPTIONS:= \
+   HAVE_TARGET_ROOTFS_INCLUDE_KERNEL \
+   HAVE_TARGET_ROOTFS_INCLUDE_ZIMAGE \
+   HAVE_TARGET_ROOTFS_INCLUDE_DTB
   PACKAGES+= \
-dnsmasq -firewall -ppp -ip6tables -iptables -6relayd -mtd 
uboot-envtools \
kmod-leds-gpio kmod-ledtrig-timer kmod-usb-mxs-phy -kmod-ipt-nathelper
-- 
2.0.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 3/3] imx6: ventana: by default include uimage and dtb in rootfs

[Luka Perkov]

Signed-off-by: Luka Perkov l...@openwrt.org
---
 target/linux/imx6/profiles/120-gateworks.mk | 4 
 1 file changed, 4 insertions(+)

diff --git a/target/linux/imx6/profiles/120-gateworks.mk 
b/target/linux/imx6/profiles/120-gateworks.mk
index d64a0bd..7257ab8 100644
--- a/target/linux/imx6/profiles/120-gateworks.mk
+++ b/target/linux/imx6/profiles/120-gateworks.mk
@@ -7,6 +7,10 @@
 
 define Profile/VENTANA
   NAME:=Gateworks Ventana family
+  OPTIONS:= \
+   HAVE_TARGET_ROOTFS_INCLUDE_KERNEL \
+   HAVE_TARGET_ROOTFS_INCLUDE_UIMAGE \
+   HAVE_TARGET_ROOTFS_INCLUDE_DTB
   PACKAGES:= \
kmod-thermal-imx kmod-sky2 kmod-usb-chipidea kmod-usb-mxs-phy \
kmod-sound-core kmod-sound-soc-imx kmod-sound-soc-imx-sgtl5000 \
-- 
2.0.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/3] build: add support for options

[Luka Perkov]

On Mon, Aug 11, 2014 at 01:17:04PM +0200, Jonas Gorski wrote:
 On Mon, Aug 11, 2014 at 10:47 AM, Luka Perkov l...@openwrt.org wrote:
  This patch adds support for target DEFAULT_OPTIONS and profile OPTIONS
  variables. Those are simmilar to existing DEFAULT_PACKAGES and PACKAGES
  but one can use them to select other options by default in menuconfig.
 
 I don't think this is a good idea. This is very easy to abuse (add
 package configuration options, build options for the kernel etc) which
 is unexpected, and I am not sure if this will work properly with IB.

Why do you think this would not work properly with IB?
 
 Instead of adding more cludges working around the need for individual
 rootfs versions/contents for devices, we should rather work on
 removing the need for these options.

Even though this now is useful mainly for including kernel/dtb in rootfs
we could also use it for other options as well. For example on not
resource constraint platforms we could add support for kexec, cgroups,
namespaces and others if we wanted without hackery in config/ directory.

Luka

 Maybe we could invert the way the
 rootfs is built for ubi, i.e. instead of generating the ubi, then
 calling Image/Build, let Image/Build/ build the individual rootfs's
 itself.
 
 We could have something like
 
 define Image/PrepareUbifs
 (copy prepared rootfs to rootfs-$(1))
 (if $(3), copy contents of $() into rootfs-$(3))
 (create ubifs using config $(2), calling it ubifs-$(1))
 endef
 
 so a create image with dtb + zImage could look like
 
 define Image/Build/foorouter
 mkdir -p $(KDIR)/extra-foorouter/boot
 $(CP) $(KDIR)/zImage $(KDIR)/extra-foorouter/boot/zImage
 $(CP) $(DTS_DIR)/foorouter.dtb $(KDIR)/extra-foorouter/boot/dtb
 $(Call Image/PrepareUbifs,foorouter,./foorouter-ubinize.cfg,
 $(KDIR)/extra-foorouter))
 # do the usual image preparetion steps
 endef
 
 define Image/Build/ubi
 $(call Image/Build/foorouter)
 endef
 
 
 Jonas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/3] build: add support for options

[Luka Perkov]

On Mon, Aug 11, 2014 at 03:21:58PM +0200, Jonas Gorski wrote:
 On Mon, Aug 11, 2014 at 2:57 PM, Luka Perkov l...@openwrt.org wrote:
  On Mon, Aug 11, 2014 at 01:17:04PM +0200, Jonas Gorski wrote:
  On Mon, Aug 11, 2014 at 10:47 AM, Luka Perkov l...@openwrt.org wrote:
   This patch adds support for target DEFAULT_OPTIONS and profile OPTIONS
   variables. Those are simmilar to existing DEFAULT_PACKAGES and PACKAGES
   but one can use them to select other options by default in menuconfig.
 
  I don't think this is a good idea. This is very easy to abuse (add
  package configuration options, build options for the kernel etc) which
  is unexpected, and I am not sure if this will work properly with IB.
 
  Why do you think this would not work properly with IB?
 
  Instead of adding more cludges working around the need for individual
  rootfs versions/contents for devices, we should rather work on
  removing the need for these options.
 
  Even though this now is useful mainly for including kernel/dtb in rootfs
  we could also use it for other options as well. For example on not
  resource constraint platforms we could add support for kexec, cgroups,
  namespaces and others if we wanted without hackery in config/ directory.
 
 cgroups and kexec are exactly what I'm talking about what won't work
 with the IB.
 
 Say you create an IB (with the default profile selected). Now if you
 run make PROFILE=foo, where foo selects cgroups or kexec, the
 resulting kernel won't actually have this enabled as this would
 require a recompilation of the kernel, which isn't possible in IB.

Ok. Those specific options can be limited to target, not profile. I
don't see this as a problem.

 And when building from source, you also can't build a
 release-compatible image when selecting a profile selecting
 cgroups/kexec, as the kernel's hash will not match the releases's
 config, unless the default profile also does that.

 So in effect if we do that we need to build a separate packages feed
 and a separate SDK and IB for each of the profiles. I don't think this
 is feasable.

Same comment as above. Those options which would require kernel re-build
can be set globally on target if maintainer wants to.

 And further, in your approach you directly select the options, not
 just change the defaults (in contrast to the default packages), so you
 can't even deselect them anymore.

You can deselect options with this series. That was the goal and that is
why there are HAVE_* options present. Give it a try.

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

Re: [OpenWrt-Devel] [PATCH 1/3] build: add support for options

[Luka Perkov]

On Mon, Aug 11, 2014 at 05:24:32PM +0200, Jonas Gorski wrote:
 On Mon, Aug 11, 2014 at 5:06 PM, Luka Perkov l...@openwrt.org wrote:
  On Mon, Aug 11, 2014 at 03:21:58PM +0200, Jonas Gorski wrote:
  And further, in your approach you directly select the options, not
  just change the defaults (in contrast to the default packages), so you
  can't even deselect them anymore.
 
  You can deselect options with this series. That was the goal and that is
  why there are HAVE_* options present. Give it a try.
 
 So what is the difference to FEATURES:= then? These already select
 different HAVE_FOO things. Can't you just add the missing features
 there?

FEATURES nor DEPENDS are not good candidates for this. They are global
for target/subtarget. So you can not define in same target/subtarget for
one profile to include only zImage and for other to include only uImage.

You can see that does not work if you look how Freescale i.MX23/i.MX28
(mxs) now behaves.

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

Re: [OpenWrt-Devel] [PATCH 1/3] build: add support for options

[Luka Perkov]

On Mon, Aug 11, 2014 at 06:59:15PM +0200, Jonas Gorski wrote:
 On Mon, Aug 11, 2014 at 6:34 PM, Luka Perkov l...@openwrt.org wrote:
  On Mon, Aug 11, 2014 at 05:24:32PM +0200, Jonas Gorski wrote:
  On Mon, Aug 11, 2014 at 5:06 PM, Luka Perkov l...@openwrt.org wrote:
   On Mon, Aug 11, 2014 at 03:21:58PM +0200, Jonas Gorski wrote:
   And further, in your approach you directly select the options, not
   just change the defaults (in contrast to the default packages), so you
   can't even deselect them anymore.
  
   You can deselect options with this series. That was the goal and that is
   why there are HAVE_* options present. Give it a try.
 
  So what is the difference to FEATURES:= then? These already select
  different HAVE_FOO things. Can't you just add the missing features
  there?
 
  FEATURES nor DEPENDS are not good candidates for this. They are global
  for target/subtarget. So you can not define in same target/subtarget for
  one profile to include only zImage and for other to include only uImage.
 
  You can see that does not work if you look how Freescale i.MX23/i.MX28
  (mxs) now behaves.
 
 So the clean solution is to make them both work at the same time, not
 to add additional workarounds. Correct image generation should not
 depend on profile selection. All these options currently alter the way
 the single (ubi) rootfs is generated, while they should enable
 different rootfs variants to be generated at the same time. This is
 the root issue, and this is where it should be fixed. Yes, it isn't
 easy to fix, but we should not break it further.

I agree with you but this does not only solve ubi image generation
problem. As explained before with this we can enable other options as
well, thus once we have better fix for ubi images we can keep this for
other purposes.

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

Re: [OpenWrt-Devel] [PATCH 2/3] build: use options to add kernels/dtbs in rootfs

[Luka Perkov]

On Mon, Aug 11, 2014 at 10:06:27PM +0200, Felix Fietkau wrote:
 On 2014-08-11 10:47, Luka Perkov wrote:
  Use support for options to enable targets and profiles select kernel or dtb
  inclusion by default.
  
  Signed-off-by: Luka Perkov l...@openwrt.org
 What's the rationale for having this stuff as config options in the
 first place? It seems to me that it makes a lot more sense to control
 this from the target's image/Makefile.

Here are the reasons:

* Simplified image/Makefile for targets, no extra ifdefs
* Users can select if they want to include kernel/dtb or not - it is not
hardcoded in the image/Makefile. For example, if one is building ramdisk
image only no need to include kernel in rootfs.
* Introduces ground work for including other options which can not be
built as modules. Such as lxc/kexec support by default.

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

Re: [OpenWrt-Devel] [PATCH] kernel: ledtrig-netdev: use netdev_notifier_info

[Luka Perkov]

Hi Claudio,

On Mon, Jul 07, 2014 at 08:24:32PM -0400, Claudio Leite wrote:
 Since kernel 3.11, the third parameter passed to notifier_call()
 is of type struct netdev_notifier_info. This patch fixes an oops
 when setting a netdev LED trigger.
 
 Signed-off-by: Claudio Leite lei...@staticky.com
 ---
  .../patches-3.12/833-ledtrig_netdev-use-notifier-info.patch | 13 
 +
  .../patches-3.13/833-ledtrig_netdev-use-notifier-info.patch | 13 
 +
  .../patches-3.14/833-ledtrig_netdev-use-notifier-info.patch | 13 
 +
  3 files changed, 39 insertions(+)
  create mode 100644 
 target/linux/generic/patches-3.12/833-ledtrig_netdev-use-notifier-info.patch
  create mode 100644 
 target/linux/generic/patches-3.13/833-ledtrig_netdev-use-notifier-info.patch
  create mode 100644 
 target/linux/generic/patches-3.14/833-ledtrig_netdev-use-notifier-info.patch

Applied in r41552. I have merged the patch with already existing
831-ledtrig_netdev.patch. Thanks for fixing this!

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

[OpenWrt-Devel] [PATCH][uclient][V2] fetch: fix segfault after destination was not reached

[Luka Perkov]

Signed-off-by: Luka Perkov l...@openwrt.org
---
v1-v2:
* don't change connecting to connected

 uclient-fetch.c | 34 --
 1 file changed, 28 insertions(+), 6 deletions(-)

diff --git a/uclient-fetch.c b/uclient-fetch.c
index 881b4ea..22f15c6 100644
--- a/uclient-fetch.c
+++ b/uclient-fetch.c
@@ -149,13 +149,27 @@ static void msg_connecting(struct uclient *cl)
fprintf(stderr, Connecting to %s:%d\n, addr, port);
 }
 
-static void init_request(struct uclient *cl)
+static int init_request(struct uclient *cl)
 {
+   int rc;
+
out_bytes = 0;
-   uclient_connect(cl);
+
+   rc = uclient_connect(cl);
+   if (rc)
+   return rc;
+
msg_connecting(cl);
-   uclient_http_set_request_type(cl, GET);
-   uclient_request(cl);
+
+   rc = uclient_http_set_request_type(cl, GET);
+   if (rc)
+   return rc;
+
+   rc = uclient_request(cl);
+   if (rc)
+   return rc;
+
+   return 0;
 }
 
 static void eof_cb(struct uclient *cl)
@@ -269,6 +283,7 @@ int main(int argc, char **argv)
struct uclient *cl;
int ch;
int longopt_idx = 0;
+   int rc;
 
init_ustream_ssl();
 
@@ -340,8 +355,15 @@ int main(int argc, char **argv)
if (ssl_ctx)
uclient_http_set_ssl_ctx(cl, ssl_ops, ssl_ctx, verify);
 
-   init_request(cl);
-   uloop_run();
+   rc = init_request(cl);
+   if (!rc) {
+   /* no error received, we can enter main loop */
+   uloop_run();
+   } else {
+   fprintf(stderr, Failed to establish connection\n);
+   error_ret = 4;
+   }
+
uloop_done();
 
uclient_free(cl);
-- 
2.0.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH][uclient] http: implement data_sent write callback

[Luka Perkov]

Signed-off-by: Luka Perkov l...@openwrt.org
---
 uclient-http.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/uclient-http.c b/uclient-http.c
index 9652fb8..b9de3a7 100644
--- a/uclient-http.c
+++ b/uclient-http.c
@@ -653,6 +653,12 @@ static void __uclient_notify_read(struct uclient_http *uh)
uc-cb-data_read(uc);
 }
 
+static void __uclient_notify_write(struct uclient_http *uh)
+{
+   struct uclient *uc = uh-uc;
+   uc-cb-data_sent(uc);
+}
+
 static void uclient_notify_read(struct ustream *us, int bytes)
 {
struct uclient_http *uh = container_of(us, struct uclient_http, 
ufd.stream);
@@ -660,6 +666,13 @@ static void uclient_notify_read(struct ustream *us, int 
bytes)
__uclient_notify_read(uh);
 }
 
+static void uclient_notify_write(struct ustream *us, int bytes)
+{
+   struct uclient_http *uh = container_of(us, struct uclient_http, 
ufd.stream);
+
+   __uclient_notify_write(uh);
+}
+
 static void uclient_notify_state(struct ustream *us)
 {
struct uclient_http *uh = container_of(us, struct uclient_http, 
ufd.stream);
@@ -678,6 +691,7 @@ static int uclient_setup_http(struct uclient_http *uh)
us-string_data = true;
us-notify_state = uclient_notify_state;
us-notify_read = uclient_notify_read;
+   us-notify_write = uclient_notify_write;
 
ret = uclient_do_connect(uh, 80);
if (ret)
@@ -693,6 +707,13 @@ static void uclient_ssl_notify_read(struct ustream *us, 
int bytes)
__uclient_notify_read(uh);
 }
 
+static void uclient_ssl_notify_write(struct ustream *us, int bytes)
+{
+   struct uclient_http *uh = container_of(us, struct uclient_http, 
ussl.stream);
+
+   __uclient_notify_write(uh);
+}
+
 static void uclient_ssl_notify_state(struct ustream *us)
 {
struct uclient_http *uh = container_of(us, struct uclient_http, 
ussl.stream);
@@ -746,6 +767,7 @@ static int uclient_setup_https(struct uclient_http *uh)
us-string_data = true;
us-notify_state = uclient_ssl_notify_state;
us-notify_read = uclient_ssl_notify_read;
+   us-notify_write = uclient_ssl_notify_write;
uh-ussl.notify_error = uclient_ssl_notify_error;
uh-ussl.notify_verify_error = uclient_ssl_notify_verify_error;
uh-ussl.notify_connected = uclient_ssl_notify_connected;
-- 
2.0.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/5] [libubox] usock: fix indentation

[Luka Perkov]

Signed-off-by: Luka Perkov l...@openwrt.org
---
 usock.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/usock.h b/usock.h
index 8f30add..5df4362 100644
--- a/usock.h
+++ b/usock.h
@@ -23,12 +23,12 @@
 #define USOCK_UDP 1
 
 #define USOCK_SERVER   0x0100
-#define USOCK_NOCLOEXEC0x0200
+#define USOCK_NOCLOEXEC0x0200
 #define USOCK_NONBLOCK 0x0400
 #define USOCK_NUMERIC  0x0800
 #define USOCK_IPV6ONLY 0x2000
 #define USOCK_IPV4ONLY 0x4000
-#define USOCK_UNIX 0x8000
+#define USOCK_UNIX 0x8000
 
 int usock(int type, const char *host, const char *service);
 
-- 
2.0.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel