date:20160603

[LEDE-DEV] ar71xx kernel size starts getting oversized

2016-06-03 Thread Yousong Zhou

Several days ago I tried to build a firmware for HiWiFi-HC6361 with
LEDE master branch.  Yet the firmware was not present in
bin/targets/ar71xx/generic after the build completed.  I checked the
downloads.lede-project.org the firmware was also missing there.

The problem is that mtdparts layout of HC6361 requires the kernel part
to be not bigger than 1280KB (1310720 bytes).  Yet the lzma-compressed
kernel uImage has exceeded this size limit.

The current size of lede-ar71xx-generic-uImage-lzma.bin in
downloads.lede-project.org is 1367988

The corresponding file in OpenWrt downloads site are as follows

snapshot 1295637
15.05.11176662
14.07   1107048

My device is currently running 4.1.16 with OpenWrt r48975.  So the
bloat probably comes from the 4.4 bump.  Sorry that at the moment I
can just bring the issue up and cannot find time to do further
investigation.

Regards

yousong

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] mmc driver for openwrt on fonera 2100

2016-06-03 Thread Marco Castrovilli


hi andrew,
i've installed
openwrt-atheros-root.jffs2-64k
openwrt-atheros-vmlinux.lzma
from https://downloads.openwrt.org/kamikaze/8.09/atheros/

after few problems to configure internet access, i did:

opkg update
opkg install kmod-mmc-over-gpio kmod-fs-ext3 cfdisk e2fsprogs kmod-nls-base 
kmod-nls-cp437 kmod-nls-iso8859-1

and each installation was fine.

during GPIO configuration i had the message:
uci: entry not found
after each command:
uci set mmc_over_gpio.@mmc_over_gpio[0].enabled=1
uci set mmc_over_gpio.@mmc_over_gpio[0].DI_pin=1
uci set mmc_over_gpio.@mmc_over_gpio[0].DO_pin=4
uci set mmc_over_gpio.@mmc_over_gpio[0].CLK_pin=3
uci set mmc_over_gpio.@mmc_over_gpio[0].CS_pin=7
then i had "can't create /config/gpiommc/ directory" error. so i rebooted, but 
now i can ping fonera 15/16 times, 1 timeout, other 10/12 ping ok,
then it is unreachable for some seconds and so looping on.

do you know the reason?

and now the final question: i soldered exactly like in figure above:
www.WiFi-Ita.com
as explained here:
http://www.wifi-ita.com/index.php?option=com_content=view=223

must i have to solder ALL cables on pin of GPIO?

thank you again.
Il 03/06/2016 16:32, Andrew Yong ha scritto:

You'll want to use OpenWrt Kamikaze 8.09 and use the official package
manager opkg. Follow the linked wiki page
(https://wiki.openwrt.org/doc/howto/mmc_over_gpio) and you'll be fine.

The latest releases have deprecated kmod-mmc-over-gpio in favor of
just getting other generic $30 routers from AliExpress that have built
in TF/MMC ports (generally RT5350), or AR9311 routers with USB e.g.
TL-MR3020.



On Fri, Jun 3, 2016 at 10:15 PM, Marco Castrovilli
 wrote:

thanks a lot for your immediate answer.
i followed this guide to mod fonera adding an sd card:
http://www.wifi-ita.com/index.php?option=com_content=view=223
and this one:
http://www.nabuk.org/f/index.php?topic=1486.0
everything is ok but i can't find 26215-4pinfon2100Driver7143.ipk anywere.
i'm on kamikaze 7.09 and kernel:
Linux Legend 2.6.22.1 #5 Mon Aug 13 18:18:07 EDT 2007 mips unknown

i tried to update (with ipkg, not opkg) but i have problem with original
openwrt feed:
root@Legend:~# ipkg update
Downloading
http://downloads.openwrt.org/snapshots/atheros-2.6/packages/Packages
wget: server returned error: HTTP/1.1 404 Not Found
Downloading http://downloads.openwrt.org/kamikaze/packages/mips/Packages
wget: server returned error: HTTP/1.1 404 Not Found
Downloading
http://downloads.x-wrt.org/xwrt/kamikaze/snapshots/atheros-2.6/packages/Packages
wget: server returned error: HTTP/1.1 404 Not Found
An error ocurred, return value: 3.
Collected errors:
ipkg_download: ERROR: Command failed with return value 1: `wget
--passive-ftp-q -P /tmp/ipkg-hCDHje
http://downloads.openwrt.org/snapshots/atheros-2.6/packages/Packages'
ipkg_download: ERROR: Command failed with return value 1: `wget
--passive-ftp-q -P /tmp/ipkg-hCDHje
http://downloads.openwrt.org/kamikaze/packages/mips/Packages'
ipkg_download: ERROR: Command failed with return value 1: `wget
--passive-ftp-q -P /tmp/ipkg-hCDHje
http://downloads.x-wrt.org/xwrt/kamikaze/snapshots/atheros-2.6/packages/Packages'
root@Legend:~#

so i tried with other ones but:
root@Legend:~# ipkg update
Downloading
https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
wget: not an http or ftp url:
https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
Downloading
https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
wget: not an http or ftp url:
https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
Downloading
https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
wget: not an http or ftp url:
https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
An error ocurred, return value: 3.
Collected errors:
ipkg_download: ERROR: Command failed with return value 1: `wget
--passive-ftp-q -P /tmp/ipkg-nErUJo
https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages'
ipkg_download: ERROR: Command failed with return value 1: `wget
--passive-ftp-q -P /tmp/ipkg-nErUJo
https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages'
ipkg_download: ERROR: Command failed with return value 1: `wget
--passive-ftp-q -P /tmp/ipkg-nErUJo
https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages'
root@Legend:~#

i got a more recent wget (wget_1.10.2-2_mips.ipk) but stil have problems
with ssl.
anyway, browsing manually feeds i can't find driver.

perhaps i NEED to use kamikaze 8.09 and all troubles will run away?

again many thanks Andrew for your interest: this is my last chance to use a
microSD on my fonera 2100 :)



Il 03/06/2016 15:49, Andrew Yong ha scritto:

https://wiki.openwrt.org/doc/hardware/port.gpio and see relevant sections
for bitbanging MMC over GPIO.

On 3 Jun 2016 21:46, "Marco Castrovilli" 
wrote:

hi all!
does

Re: [LEDE-DEV] Meeting on TR-069 Work - Friday, June 10 - 7 AM PT

2016-06-03 Thread Eric Schultz

All,

Just noticed that the Fuze url was sent inappropriately in my mail
client. The correct URL is http://fuze.me/32924366

Thanks,

Eric

On 06/03/2016 04:41 PM, Eric Schultz wrote:
> I'm excited to see so many people interested in TR-069 support! As a
> follow up to the previous TR-069 email, I've set up a meeting on TR-069
> support for OpenWrt. The meeting is on Friday, June 10 at 7 AM PT.
>
> I expect the meeting will discuss:
>
> * The proposals for creating/integrating TR-069 support into OpenWrt
> from Luka and Felix
> * The proposed open source TR-069 stacks from SoftAtHome and
> Technicolor, as well as the potential for reuse between stacks
> * The potential for a standard TR-069 stack interface in OpenWrt
> * A standard interface in OpenWrt for protocols like TR-069, as proposed
> by Felix
> * A face-to-face meeting for all of the core implementers to work
> through the technical details to develop a plan forward
> * Anything else related!
>
> Everyone interested is invited to join the meeting. I also plan to post
> a video of the meeting to Youtube for those who couldn't attend. To join
> the meeting using any WebRTC enabled browser, please follow the
> instructions below.
>
> Thanks a lot and I look forward to seeing many of you at the meeting.
>
> Thanks,
>
> Eric
>
> --
>
> Eric Schultz, Community Manager, prpl Foundation
> http://www.prplfoundation.org
> eschu...@prplfoundation.org 
> cell: 920-539-0404 
> skype: ericschultzwi
> @EricPrpl
>
> ---
>
>  
> To join the web meeting click or copy and paste this URL into your browser:
>  
> _http://fuze.me/32924366_
>  
> To join the audio portion of this meeting:
>  
> Internet Audio: Simply select the internet audio option after joining.
> Toll / Intl #: +12014794595
> Toll free #: +18553463893
> You can find international access numbers at
> _https://www.fuze.com/extras/symphony_
> If prompted, enter the meeting number: 32924366, then press #.
>  
> For the optimal experience, download Fuze: 
> _www.fuzebox.com/products/download_
>  
> Need help? You can connect to our Customer Support Team or access self-help
> tools at _www.fuzebox.com/support_ .
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Meeting on TR-069 Work - Friday, June 10 - 7 AM PT

2016-06-03 Thread Eric Schultz

I'm excited to see so many people interested in TR-069 support! As a
follow up to the previous TR-069 email, I've set up a meeting on TR-069
support for OpenWrt. The meeting is on Friday, June 10 at 7 AM PT.

I expect the meeting will discuss:

* The proposals for creating/integrating TR-069 support into OpenWrt
from Luka and Felix
* The proposed open source TR-069 stacks from SoftAtHome and
Technicolor, as well as the potential for reuse between stacks
* The potential for a standard TR-069 stack interface in OpenWrt
* A standard interface in OpenWrt for protocols like TR-069, as proposed
by Felix
* A face-to-face meeting for all of the core implementers to work
through the technical details to develop a plan forward
* Anything else related!

Everyone interested is invited to join the meeting. I also plan to post
a video of the meeting to Youtube for those who couldn't attend. To join
the meeting using any WebRTC enabled browser, please follow the
instructions below.

Thanks a lot and I look forward to seeing many of you at the meeting.

Thanks,

Eric

--

Eric Schultz, Community Manager, prpl Foundation
http://www.prplfoundation.org
eschu...@prplfoundation.org 
cell: 920-539-0404 
skype: ericschultzwi
@EricPrpl

---

 
To join the web meeting click or copy and paste this URL into your browser:
 
_http://fuze.me/32924366_
 
To join the audio portion of this meeting:
 
Internet Audio: Simply select the internet audio option after joining.
Toll / Intl #: +12014794595
Toll free #: +18553463893
You can find international access numbers at
_https://www.fuze.com/extras/symphony_
If prompted, enter the meeting number: 32924366, then press #.
 
For the optimal experience, download Fuze: 
_www.fuzebox.com/products/download_
 
Need help? You can connect to our Customer Support Team or access self-help
tools at _www.fuzebox.com/support_ .

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.

2016-06-03 Thread Ben Greear

On 06/03/2016 09:19 AM, Karl Palsson wrote:

Maybe some of it, but for more generic platforms, I am not sure
sub-targets make sense, and in general, it is more difficult to
edit those than to change a diffconfig as far as I can tell.

For who? I'm pretty sure I can use "make menuconfig" _far_ more reliably than I can edit a diffconfig file
to use a "buildme" script. If I don't know anything, and _need_ to build a custom image that can't be built
with image builder, or post install config, then menuconfig at least makes sure that dependencies get pulled in
properly. Adding line items to file that you then "defoncfig" and hope you got perfectt seems fraught with
danger, and for what? To avoid showing someone how to use menuconfig? Which they'll need to use anyway? Because I
don't believe for a _second_ that somehow you're going to have "buildme" magic that automatically solves all
the configs someone needs.

First of all, any time you try to add a new module, someone will bitch about
how it bloats their beautiful image and makes it impure. Adding more
sub-targets
almost cannot by definition be any less likely to rot or be un-maintained than
the buildme targets I am proposing.

To create (or update) the diffconfig, you can run menuconfig, twiddle as you
like, and then save the
new diffconfig. And commit changes (assuming you are maintaining this buildme
profile).

If the diffconfig profiles are really that un-cool, then maybe just add the
buildme
script with ability to use URL for the diffconfig profile and let folks host
them
elsewhere. That is less user-friendly (it would be hard to show user all
available options),
but at least it is still one command to build an image.

And anyway, no one is proposing to remove menuconfig logic, I just want to add
some
wrappers to make it easier for newbies that may initially be bewildered by all
of the menuconfig
options (and lack of options if you haven't installed the proper feeds already).

Thanks,
Ben

--
Ben Greear
Candela Technologies Inc http://www.candelatech.com

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.

2016-06-03 Thread Karl Palsson


> Maybe some of it, but for more generic platforms, I am not sure
> sub-targets make sense, and in general, it is more difficult to
> edit those than to change a diffconfig as far as I can tell.

For who?  I'm pretty sure I can use "make menuconfig" _far_ more reliably than 
I can edit a diffconfig file to use a "buildme" script.  If I don't know 
anything, and _need_ to build a custom image that can't be built with image 
builder, or post install config, then menuconfig at least makes sure that 
dependencies get pulled in properly.  Adding line items to file that you then 
"defoncfig" and hope you got perfectt seems fraught with danger, and for what? 
To avoid showing someone how to use menuconfig?  Which they'll need to use 
anyway?  Because I don't believe for a _second_ that somehow you're going to 
have "buildme" magic that automatically solves all the configs someone needs.  

Sincerely,
Karl Palsson


signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.

2016-06-03 Thread Karl Palsson


Conor O'Gorman  wrote:
> 
> 
> On 03/06/16 13:27, Ben Greear wrote:
> >
> >
> > On 06/03/2016 02:17 AM, John Crispin wrote:
> >>
> >>
> >> On 01/06/2016 20:21, Ben Greear wrote:
> >>> On 06/01/2016 11:07 AM, John Crispin wrote:
>  Hi Ben,
> 
>  also inclined to reject this one. it will open up the pandoras box and
>  we will end up maintaining piles of diffconfig files. it would make
>  morse sense to document what the script does inside web.git as a 
>  "how to
>  build" or "getting started" page
> >>>
> >>> I do not have much history with LEDE/WRT, but is the diffconfig output
> >>> really that fragile?
> >>>
> >>> I will be willing to maintain the x86-64 and probably Ventana
> >>> diffconfigs, and even if it totally fails, you have not lost
> >>> any functionality since the main infrastructure is unchanged.
> >>
> >> for how long and will all the other people submitting these files also
> >> provide LTS ? normally activism fades after a few months. we can see
> >> this will board support and package maintenance. i think this will be a
> >> burden.
> >
> > Anything that makes it more easy for others to build images
> > should help bring in more newbies faster, which might keep the
> > activism going, especially for common platforms that will
> > constantly be getting new hardware (like x86-64).
> >
> > Currently, a newbie with an x86-64 board is going to have a slow
> > and frustrating time trying to get any sort of useful 'AP' built
> > from LEDE.  I think I can help to fix that problem if you will
> > let me.
> >
> > So, how about you accept a small number of diffconfig recipes, and the 
> > buildme
> > script, and then see how that works for a while.  I can update
> > buildme.sh to grab a diffconfig from a URL (using curl, or something)
> > and then folks wanting to provide out-of-tree diffconfigs need only
> > put their config in a public place and tell users how to use it:
> >
> > ./buildme.sh -T http://my.funkyplatform.com/board1
> >
> > Thanks,
> > Ben
> >
> This seems to duplicate the functionality of the sub-targets
> and profiles mechanism?


Also, image builder.


signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] fix uClibc-ng scanf check

2016-06-03 Thread Alexey Brodkin

Hi Waldemar,

On Fri, 2016-06-03 at 17:16 +0200, Waldemar Brodkorb wrote:
> Hi Alexey,
> Alexey Brodkin wrote,
> 
> > 
> > Hi Waldemar,
> > 
> > On Fri, 2016-06-03 at 04:23 +0200, Waldemar Brodkorb wrote:
> > > 
> > > uClibc-ng tries to be compatible with GNU libc and defines
> > > __GLIBC__ and pretend to be version 2.2.
> > > We once changed it to 2.10, but then some hard to fix problems
> > > in different software packages (gcc) occured.
> > > It would be better if we disable the special GNU libc checks
> > > for uClibc-ng here. uClibc-ng implements the required scanf
> > > functionality.
> > > 
> > > Signed-off-by: Waldemar Brodkorb 
> > > ---
> > >  configure.ac | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/configure.ac b/configure.ac
> > > index f36b18c..4661c0d 100644
> > > --- a/configure.ac
> > > +++ b/configure.ac
> > > @@ -581,7 +581,7 @@ AC_CACHE_VAL([scanf_cv_alloc_modifier],
> > >   #include 
> > >   #include 
> > >  
> > > - #ifdef __GLIBC__
> > > + #if defined(__GLIBC__) && !defined(__UCLIBC__)
> > >  
> > >   #if !(__GLIBC_PREREQ(2, 7))
> > >   #error %m is not available
> > Even though this is a very minor and clean change I don't like this
> > approach. We're again implicitly assume something.
> > 
> > IMHO much better approach would be to include a compile test for
> > small source that uses scanf() with "%as"/"%ms".
> > 
> > That way we may remove all dependencies on either GLIBC/UCLIBC/MUSL etc.
> Just for completeness, I saw your other mail already.
> Musl has no problem with this code, because it is util-linux
> fallback code for old GNU libc. Unfortunately it matches the
> pretended version from uClibc-ng. So I think it is the right
> solution, if the fallback code will not be removed.

Thanks for explanation.

-Alexey
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] international keyboard layout support

2016-06-03 Thread edgar . soldin

On 03.06.2016 16:48, John Crispin wrote:
> 
> 
> On 03/06/2016 14:19, edgar.sol...@web.de wrote:
>> hey All,
>>
>> i already posted this on openwrt-de...@lists.openwrt.org , but am currently 
>> unsure what the status is for LEDE vs. OpenWrt. so here i go again on this 
>> very ml.
>>
>> while tinkering with Gluon the Openwrt based Freifunk firmware (currently on 
>> CC) on a x86 based thin client box i needed support for a german keyboard 
>> layout. i managed to realize that manually as i didn't find any prepared 
>> packages for this purpose.
>>
>> is there any interest in a keyboardmaps package, holding busybox compatible 
>> binary kmaps and activating the needed busybox utilities? i imagine some 
>> devs/users especially on platforms with proper keyboard interfaces (usb/ps2) 
>> would appreciate that.
>>
>> thanks ..ede
>>
> 
> 
> Hi,
> 
> generally not a bad idea. the problem is enabling extra uclibc applets.
> can this be done using the normal gnu tools ? x86 will have enough space
> to install extra full blown tools
> 

you mean busybox applets? it's actually just one 
CONFIG_BUSYBOX_CONFIG_LOADKMAP=y .

i just added a short Gluon specific summary here
 
https://github.com/freifunk-gluon/gluon/wiki/Commandline-administration#load-a-new-keyboard-layout

a full blown package would autoselect the busybox applet and offer menuconfig 
entries for users to select the maps they want in their build, although they 
will probably just add all on x86 most of the time (1.1MB).

i already wrote a uci-defaults/ script that adds the appropriate line to 
/etc/rc.local so a default mapping will be loaded automagically. that could be 
made selectable in menuconfig as well.

thanks.. ede

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH libubox] blobmsg_json: add new functions blobmsg_format_json_value*

2016-06-03 Thread Eyal Birger


Hi,

> On 3 Jun 2016, at 13:11, Matthias Schiffer  
> wrote:
> 
(snip)
> 
> 1) and 2) would allow blobmsg to store everything that json-c can (with the
> caveat that json-c stores integers as int64 internally, while blobmsg_json
> uses int32) -

We also noticed this as a problem for us since when converting json strings to 
blobmsg, integers become signed and thus no more than INT32_MAX can be used.

Do you plans to approach this in your patchsets?

Eyal

> do you think these changes make sense?
> 
> Would there also be general interest in 3), so it might be integrated into
> libubox?
> 
> Regards,
> Matthias
> 
> 
>> 
>>> 
>>> Signed-off-by: Matthias Schiffer 
>>> ---
>>> blobmsg_json.c | 49 -
>>> blobmsg_json.h | 14 ++
>>> 2 files changed, 50 insertions(+), 13 deletions(-)
>>> 
>>> diff --git a/blobmsg_json.c b/blobmsg_json.c
>>> index 5713948..538c816 100644
>>> --- a/blobmsg_json.c
>>> +++ b/blobmsg_json.c
>>> @@ -207,7 +207,7 @@ static void blobmsg_format_string(struct strbuf *s, 
>>> const char *str)
>>> 
>>> static void blobmsg_format_json_list(struct strbuf *s, struct blob_attr 
>>> *attr, int len, bool array);
>>> 
>>> -static void blobmsg_format_element(struct strbuf *s, struct blob_attr 
>>> *attr, bool array, bool head)
>>> +static void blobmsg_format_element(struct strbuf *s, struct blob_attr 
>>> *attr, bool without_name, bool head)
>>> {
>>>const char *data_str;
>>>char buf[32];
>>> @@ -217,7 +217,7 @@ static void blobmsg_format_element(struct strbuf *s, 
>>> struct blob_attr *attr, boo
>>>if (!blobmsg_check_attr(attr, false))
>>>return;
>>> 
>>> -if (!array && blobmsg_name(attr)[0]) {
>>> +if (!without_name && blobmsg_name(attr)[0]) {
>>>blobmsg_format_string(s, blobmsg_name(attr));
>>>blobmsg_puts(s, ": ", s->indent ? 2 : 1);
>>>}
>>> @@ -286,22 +286,26 @@ static void blobmsg_format_json_list(struct strbuf 
>>> *s, struct blob_attr *attr, i
>>>blobmsg_puts(s, (array ? "]" : "}"), 1);
>>> }
>>> 
>>> +static void setup_strbuf(struct strbuf *s, struct blob_attr *attr, 
>>> blobmsg_json_format_t cb, void *priv, int indent) {
>>> +s->len = blob_len(attr);
>>> +s->buf = malloc(s->len);
>>> +s->pos = 0;
>>> +s->custom_format = cb;
>>> +s->priv = priv;
>>> +s->indent = false;
>>> +
>>> +if (indent >= 0) {
>>> +s->indent = true;
>>> +s->indent_level = indent;
>>> +}
>>> +}
>>> +
>>> char *blobmsg_format_json_with_cb(struct blob_attr *attr, bool list, 
>>> blobmsg_json_format_t cb, void *priv, int indent)
>>> {
>>>struct strbuf s;
>>>bool array;
>>> 
>>> -s.len = blob_len(attr);
>>> -s.buf = malloc(s.len);
>>> -s.pos = 0;
>>> -s.custom_format = cb;
>>> -s.priv = priv;
>>> -s.indent = false;
>>> -
>>> -if (indent >= 0) {
>>> -s.indent = true;
>>> -s.indent_level = indent;
>>> -}
>>> +setup_strbuf(, attr, cb, priv, indent);
>>> 
>>>array = blob_is_extended(attr) &&
>>>blobmsg_type(attr) == BLOBMSG_TYPE_ARRAY;
>>> @@ -321,3 +325,22 @@ char *blobmsg_format_json_with_cb(struct blob_attr 
>>> *attr, bool list, blobmsg_jso
>>> 
>>>return s.buf;
>>> }
>>> +
>>> +char *blobmsg_format_json_value_with_cb(struct blob_attr *attr, 
>>> blobmsg_json_format_t cb, void *priv, int indent)
>>> +{
>>> +struct strbuf s;
>>> +
>>> +setup_strbuf(, attr, cb, priv, indent);
>>> +
>>> +blobmsg_format_element(, attr, true, false);
>>> +
>>> +if (!s.len) {
>>> +free(s.buf);
>>> +return NULL;
>>> +}
>>> +
>>> +s.buf = realloc(s.buf, s.pos + 1);
>>> +s.buf[s.pos] = 0;
>>> +
>>> +return s.buf;
>>> +}
>>> diff --git a/blobmsg_json.h b/blobmsg_json.h
>>> index cd9ed33..9dfc02d 100644
>>> --- a/blobmsg_json.h
>>> +++ b/blobmsg_json.h
>>> @@ -42,4 +42,18 @@ static inline char *blobmsg_format_json_indent(struct 
>>> blob_attr *attr, bool list
>>>return blobmsg_format_json_with_cb(attr, list, NULL, NULL, indent);
>>> }
>>> 
>>> +char *blobmsg_format_json_value_with_cb(struct blob_attr *attr,
>>> +blobmsg_json_format_t cb, void *priv,
>>> +int indent);
>>> +
>>> +static inline char *blobmsg_format_json_value(struct blob_attr *attr)
>>> +{
>>> +return blobmsg_format_json_value_with_cb(attr, NULL, NULL, -1);
>>> +}
>>> +
>>> +static inline char *blobmsg_format_json_value_indent(struct blob_attr 
>>> *attr, int indent)
>>> +{
>>> +return blobmsg_format_json_value_with_cb(attr, NULL, NULL, indent);
>>> +}
>>> +
>>> #endif
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-de...@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

___
Lede-dev mailing list
Lede-dev@lists.infradead.org

Re: [LEDE-DEV] international keyboard layout support

2016-06-03 Thread John Crispin



On 03/06/2016 14:19, edgar.sol...@web.de wrote:
> hey All,
> 
> i already posted this on openwrt-de...@lists.openwrt.org , but am currently 
> unsure what the status is for LEDE vs. OpenWrt. so here i go again on this 
> very ml.
> 
> while tinkering with Gluon the Openwrt based Freifunk firmware (currently on 
> CC) on a x86 based thin client box i needed support for a german keyboard 
> layout. i managed to realize that manually as i didn't find any prepared 
> packages for this purpose.
> 
> is there any interest in a keyboardmaps package, holding busybox compatible 
> binary kmaps and activating the needed busybox utilities? i imagine some 
> devs/users especially on platforms with proper keyboard interfaces (usb/ps2) 
> would appreciate that.
> 
> thanks ..ede
> 


Hi,

generally not a bad idea. the problem is enabling extra uclibc applets.
can this be done using the normal gnu tools ? x86 will have enough space
to install extra full blown tools

John

> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] package/devel/gdb: Add support of ARC gdb

2016-06-03 Thread Alexey Brodkin

Hi John,

On Fri, 2016-06-03 at 11:09 +0200, John Crispin wrote:
> Hi,
> 
> On 01/06/2016 17:32, Alexey Brodkin wrote:
> > 
> > As of today gdb port for ARC is not yet in upstream even though
> > we're working hard on that.
> > 
> > Still to allow ARC users to debug user-space apps on top of
> > Linux kernel we're adding here support for building GDB from
> > sources hosted on our GitHub here:
> > https://github.com/foss-for-synopsys-dwc-arc-processors/binutils-gdb/releases/tag/arc-2016.03-gdb
> > 
> > Likewise for host GDB sources that come from unified git repository
> > (which is the case for upstream binutils/gdb today) we need to disable
> > building of binutils in gdb:
> > -->8--
> > --disable-binutils
> > --disable-ld
> > --disable-gas
> > -->8--
> > 
> these work for !arc targets. disabling them for all targets because they
> are broken on arc seem weird even if they might not be used.
> 
> rather than cluttering the makefile how about marking the packahe broken
> for arc and adding a new one called gdb-arc that depends on arc only.
> this will allow us to keep gdb clean and just drop the gdb-arc package
> once the fixes treacled down the tree.

Well all 3 options except "--sim" are very valid because modern GDB sources
come from "unified" git repo where binutils co-exist with gdb.

That's done on purpose because a lot of stuff indeed is the same in both
projects. And there's really no point in building either binutils, ld or gas
when we're building GDB. Disabling those options we at least saving some time
and in some cases may escape build failures.

Mentioned build failures might happen with some even release versions of GDB
tarballs. Again that is because gdb comes from the same unified repo BUT
(and that's important) still from the separate branch and so some parts of
binutils might be taken from "binutils" branch in unstable state.

In other words disabling build of not used components is pretty safe and
future-proof. And simulator falls here as well - we don't need it anyways
for either arch/board.

As for adding a separate package... we'll need to propagate new Kconfig symbol 
in
other files and so instead of limiting changes to 1 file we'll spread our
contamination all over source tree. Do we really want it?

-Alexey

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] mmc driver for openwrt on fonera 2100

2016-06-03 Thread Andrew Yong

You'll want to use OpenWrt Kamikaze 8.09 and use the official package
manager opkg. Follow the linked wiki page
(https://wiki.openwrt.org/doc/howto/mmc_over_gpio) and you'll be fine.

The latest releases have deprecated kmod-mmc-over-gpio in favor of
just getting other generic $30 routers from AliExpress that have built
in TF/MMC ports (generally RT5350), or AR9311 routers with USB e.g.
TL-MR3020.



On Fri, Jun 3, 2016 at 10:15 PM, Marco Castrovilli
 wrote:
> thanks a lot for your immediate answer.
> i followed this guide to mod fonera adding an sd card:
> http://www.wifi-ita.com/index.php?option=com_content=view=223
> and this one:
> http://www.nabuk.org/f/index.php?topic=1486.0
> everything is ok but i can't find 26215-4pinfon2100Driver7143.ipk anywere.
> i'm on kamikaze 7.09 and kernel:
> Linux Legend 2.6.22.1 #5 Mon Aug 13 18:18:07 EDT 2007 mips unknown
>
> i tried to update (with ipkg, not opkg) but i have problem with original
> openwrt feed:
> root@Legend:~# ipkg update
> Downloading
> http://downloads.openwrt.org/snapshots/atheros-2.6/packages/Packages
> wget: server returned error: HTTP/1.1 404 Not Found
> Downloading http://downloads.openwrt.org/kamikaze/packages/mips/Packages
> wget: server returned error: HTTP/1.1 404 Not Found
> Downloading
> http://downloads.x-wrt.org/xwrt/kamikaze/snapshots/atheros-2.6/packages/Packages
> wget: server returned error: HTTP/1.1 404 Not Found
> An error ocurred, return value: 3.
> Collected errors:
> ipkg_download: ERROR: Command failed with return value 1: `wget
> --passive-ftp-q -P /tmp/ipkg-hCDHje
> http://downloads.openwrt.org/snapshots/atheros-2.6/packages/Packages'
> ipkg_download: ERROR: Command failed with return value 1: `wget
> --passive-ftp-q -P /tmp/ipkg-hCDHje
> http://downloads.openwrt.org/kamikaze/packages/mips/Packages'
> ipkg_download: ERROR: Command failed with return value 1: `wget
> --passive-ftp-q -P /tmp/ipkg-hCDHje
> http://downloads.x-wrt.org/xwrt/kamikaze/snapshots/atheros-2.6/packages/Packages'
> root@Legend:~#
>
> so i tried with other ones but:
> root@Legend:~# ipkg update
> Downloading
> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
> wget: not an http or ftp url:
> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
> Downloading
> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
> wget: not an http or ftp url:
> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
> Downloading
> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
> wget: not an http or ftp url:
> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
> An error ocurred, return value: 3.
> Collected errors:
> ipkg_download: ERROR: Command failed with return value 1: `wget
> --passive-ftp-q -P /tmp/ipkg-nErUJo
> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages'
> ipkg_download: ERROR: Command failed with return value 1: `wget
> --passive-ftp-q -P /tmp/ipkg-nErUJo
> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages'
> ipkg_download: ERROR: Command failed with return value 1: `wget
> --passive-ftp-q -P /tmp/ipkg-nErUJo
> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages'
> root@Legend:~#
>
> i got a more recent wget (wget_1.10.2-2_mips.ipk) but stil have problems
> with ssl.
> anyway, browsing manually feeds i can't find driver.
>
> perhaps i NEED to use kamikaze 8.09 and all troubles will run away?
>
> again many thanks Andrew for your interest: this is my last chance to use a
> microSD on my fonera 2100 :)
>
>
>
> Il 03/06/2016 15:49, Andrew Yong ha scritto:
>
> https://wiki.openwrt.org/doc/hardware/port.gpio and see relevant sections
> for bitbanging MMC over GPIO.
>
> On 3 Jun 2016 21:46, "Marco Castrovilli" 
> wrote:
>>
>> hi all!
>> does anyone can help me to find mmc driver working on openwrt, installed
>> on fonera 2100 (mips architectire)?
>> thank you in advance.
>>
>> ___
>> Lede-dev mailing list
>> Lede-dev@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
>
>

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] mmc driver for openwrt on fonera 2100

2016-06-03 Thread Marco Castrovilli


i send again in plain text format (not HTML).

sorry for my bad /Netiquette :(
/

thank you.

thanks a lot for your immediate answer.
i followed this guide to mod fonera adding an sd card:
http://www.wifi-ita.com/index.php?option=com_content=view=223
and this one:
http://www.nabuk.org/f/index.php?topic=1486.0
everything is ok but i can't find 26215-4pinfon2100Driver7143.ipk anywere.
i'm on kamikaze 7.09 and kernel:
Linux Legend 2.6.22.1 #5 Mon Aug 13 18:18:07 EDT 2007 mips unknown

i tried to update (with ipkg, not opkg) but i have problem with original 
openwrt feed:

root@Legend:~# ipkg update
Downloading 
http://downloads.openwrt.org/snapshots/atheros-2.6/packages/Packages

wget: server returned error: HTTP/1.1 404 Not Found
Downloading http://downloads.openwrt.org/kamikaze/packages/mips/Packages
wget: server returned error: HTTP/1.1 404 Not Found
Downloading 
http://downloads.x-wrt.org/xwrt/kamikaze/snapshots/atheros-2.6/packages/Packages

wget: server returned error: HTTP/1.1 404 Not Found
An error ocurred, return value: 3.
Collected errors:
ipkg_download: ERROR: Command failed with return value 1: `wget 
--passive-ftp-q -P /tmp/ipkg-hCDHje 
http://downloads.openwrt.org/snapshots/atheros-2.6/packages/Packages'
ipkg_download: ERROR: Command failed with return value 1: `wget 
--passive-ftp-q -P /tmp/ipkg-hCDHje 
http://downloads.openwrt.org/kamikaze/packages/mips/Packages'
ipkg_download: ERROR: Command failed with return value 1: `wget 
--passive-ftp-q -P /tmp/ipkg-hCDHje 
http://downloads.x-wrt.org/xwrt/kamikaze/snapshots/atheros-2.6/packages/Packages'

root@Legend:~#

so i tried with other ones but:
root@Legend:~# ipkg update
Downloading 
https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
wget: not an http or ftp url: 
https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
Downloading 
https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
wget: not an http or ftp url: 
https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
Downloading 
https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
wget: not an http or ftp url: 
https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages

An error ocurred, return value: 3.
Collected errors:
ipkg_download: ERROR: Command failed with return value 1: `wget 
--passive-ftp-q -P /tmp/ipkg-nErUJo 
https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages'
ipkg_download: ERROR: Command failed with return value 1: `wget 
--passive-ftp-q -P /tmp/ipkg-nErUJo 
https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages'
ipkg_download: ERROR: Command failed with return value 1: `wget 
--passive-ftp-q -P /tmp/ipkg-nErUJo 
https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages'

root@Legend:~#

i got a more recent wget (wget_1.10.2-2_mips.ipk) but stil have problems 
with ssl.

anyway, browsing manually feeds i can't find driver.

perhaps i NEED to use kamikaze 8.09 and all troubles will run away?

again many thanks Andrew for your interest: this is my last chance to 
use a microSD on my fonera 2100 :)





___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.

2016-06-03 Thread Ben Greear




On 06/03/2016 05:37 AM, Conor O'Gorman wrote:



On 03/06/16 13:27, Ben Greear wrote:



On 06/03/2016 02:17 AM, John Crispin wrote:



On 01/06/2016 20:21, Ben Greear wrote:

On 06/01/2016 11:07 AM, John Crispin wrote:

Hi Ben,

also inclined to reject this one. it will open up the pandoras box and
we will end up maintaining piles of diffconfig files. it would make
morse sense to document what the script does inside web.git as a "how to
build" or "getting started" page


I do not have much history with LEDE/WRT, but is the diffconfig output
really that fragile?

I will be willing to maintain the x86-64 and probably Ventana
diffconfigs, and even if it totally fails, you have not lost
any functionality since the main infrastructure is unchanged.


for how long and will all the other people submitting these files also
provide LTS ? normally activism fades after a few months. we can see
this will board support and package maintenance. i think this will be a
burden.


Anything that makes it more easy for others to build images
should help bring in more newbies faster, which might keep the
activism going, especially for common platforms that will
constantly be getting new hardware (like x86-64).

Currently, a newbie with an x86-64 board is going to have a slow
and frustrating time trying to get any sort of useful 'AP' built
from LEDE.  I think I can help to fix that problem if you will
let me.

So, how about you accept a small number of diffconfig recipes, and the buildme
script, and then see how that works for a while.  I can update
buildme.sh to grab a diffconfig from a URL (using curl, or something)
and then folks wanting to provide out-of-tree diffconfigs need only
put their config in a public place and tell users how to use it:

./buildme.sh -T http://my.funkyplatform.com/board1

Thanks,
Ben


This seems to duplicate the functionality of the sub-targets and profiles 
mechanism?


Maybe some of it, but for more generic platforms, I am not sure sub-targets make
sense, and in general, it is more difficult to edit those than to change a 
diffconfig
as far as I can tell.

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.

2016-06-03 Thread Conor O'Gorman




On 03/06/16 13:27, Ben Greear wrote:



On 06/03/2016 02:17 AM, John Crispin wrote:



On 01/06/2016 20:21, Ben Greear wrote:

On 06/01/2016 11:07 AM, John Crispin wrote:

Hi Ben,

also inclined to reject this one. it will open up the pandoras box and
we will end up maintaining piles of diffconfig files. it would make
morse sense to document what the script does inside web.git as a 
"how to

build" or "getting started" page


I do not have much history with LEDE/WRT, but is the diffconfig output
really that fragile?

I will be willing to maintain the x86-64 and probably Ventana
diffconfigs, and even if it totally fails, you have not lost
any functionality since the main infrastructure is unchanged.


for how long and will all the other people submitting these files also
provide LTS ? normally activism fades after a few months. we can see
this will board support and package maintenance. i think this will be a
burden.


Anything that makes it more easy for others to build images
should help bring in more newbies faster, which might keep the
activism going, especially for common platforms that will
constantly be getting new hardware (like x86-64).

Currently, a newbie with an x86-64 board is going to have a slow
and frustrating time trying to get any sort of useful 'AP' built
from LEDE.  I think I can help to fix that problem if you will
let me.

So, how about you accept a small number of diffconfig recipes, and the 
buildme

script, and then see how that works for a while.  I can update
buildme.sh to grab a diffconfig from a URL (using curl, or something)
and then folks wanting to provide out-of-tree diffconfigs need only
put their config in a public place and tell users how to use it:

./buildme.sh -T http://my.funkyplatform.com/board1

Thanks,
Ben

This seems to duplicate the functionality of the sub-targets and 
profiles mechanism?



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.

2016-06-03 Thread Ben Greear




On 06/03/2016 02:17 AM, John Crispin wrote:



On 01/06/2016 20:21, Ben Greear wrote:

On 06/01/2016 11:07 AM, John Crispin wrote:

Hi Ben,

also inclined to reject this one. it will open up the pandoras box and
we will end up maintaining piles of diffconfig files. it would make
morse sense to document what the script does inside web.git as a "how to
build" or "getting started" page


I do not have much history with LEDE/WRT, but is the diffconfig output
really that fragile?

I will be willing to maintain the x86-64 and probably Ventana
diffconfigs, and even if it totally fails, you have not lost
any functionality since the main infrastructure is unchanged.


for how long and will all the other people submitting these files also
provide LTS ? normally activism fades after a few months. we can see
this will board support and package maintenance. i think this will be a
burden.


Anything that makes it more easy for others to build images
should help bring in more newbies faster, which might keep the
activism going, especially for common platforms that will
constantly be getting new hardware (like x86-64).

Currently, a newbie with an x86-64 board is going to have a slow
and frustrating time trying to get any sort of useful 'AP' built
from LEDE.  I think I can help to fix that problem if you will
let me.

So, how about you accept a small number of diffconfig recipes, and the buildme
script, and then see how that works for a while.  I can update
buildme.sh to grab a diffconfig from a URL (using curl, or something)
and then folks wanting to provide out-of-tree diffconfigs need only
put their config in a public place and tell users how to use it:

./buildme.sh -T http://my.funkyplatform.com/board1

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 1/3] [ubox] remove unnecessary size struct between messages

2016-06-03 Thread Conor O'Gorman


On 03/06/16 11:59, Dan Bugnar wrote:

From: Dan Bugnar 

The next message needs to be written after the data of current message.
This was adding "sizeof(struct log_head)" bytes between messages.

Signed-off-by: Dan Bugnar 
---
  log/syslog.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/log/syslog.c b/log/syslog.c
index e8b6774..2042e93 100644
--- a/log/syslog.c
+++ b/log/syslog.c
@@ -51,7 +51,7 @@ static regex_t pat_tstamp;
  static struct log_head*
  log_next(struct log_head *h, int size)
  {
-   struct log_head *n = (struct log_head *) >data[PAD(sizeof(struct 
log_head) + size)];
+   struct log_head *n = (struct log_head *) >data[size];


You lost the PAD? Which is over the struct and size, not just the struct.

Conor

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] urandom-seed: add initial implementation

2016-06-03 Thread John Crispin



On 03/06/2016 13:15, Etienne Champetier wrote:
> Hi John,
> 
> 2016-06-03 11:00 GMT+02:00 John Crispin :
>> Hi Etienne,
>>
>> comment inline ...
>>
>> On 02/06/2016 23:21, Etienne CHAMPETIER wrote:
>>> This package:
>>> 1) seed /dev/urandom with a saved seed as early as possible
>>> (using /lib/preinit/81_urandom_seed)
>>> 2) save a new seed using getrandom() so we are sure /dev/urandom
>>>pool is initialized (using /etc/init.d/urandom_seed)
>>>
>>> seed size is 512 bytes (ie /proc/sys/kernel/random/poolsize / 8)
>>> it's the same size as in ubuntu 14.04 and all systemd systems
>>>
>>> seed file is /etc/urandom.seed (need a writable path)
>>>
>>> seeding /dev/urandom doesn't change entropy estimation, so we still have
>>> "random: ubus urandom read with 4 bits of entropy available"
>>> messages in the logs, but we can now ignore them
>>>
>>> Once tested on enough configuration (jffs2/ext4/ubifs/...)
>>> this package should be added to DEFAULT_PACKAGES
>>>
>>> We could also add an urandom.seed at build time to improve first boot
>>>
>>> Signed-off-by: Etienne CHAMPETIER 
>>> ---
>>>  package/utils/urandom-seed/Makefile| 53 
>>> 
>>>  .../urandom-seed/files/81_urandom_seed.preinit | 15 ++
>>>  package/utils/urandom-seed/files/getrandom.c   | 58 
>>> ++
>>>  package/utils/urandom-seed/files/urandom_seed.init | 19 +++
>>>  4 files changed, 145 insertions(+)
>>>  create mode 100644 package/utils/urandom-seed/Makefile
>>>  create mode 100644 package/utils/urandom-seed/files/81_urandom_seed.preinit
>>>  create mode 100644 package/utils/urandom-seed/files/getrandom.c
>>>  create mode 100644 package/utils/urandom-seed/files/urandom_seed.init
>>>
>>> diff --git a/package/utils/urandom-seed/Makefile 
>>> b/package/utils/urandom-seed/Makefile
>>> new file mode 100644
>>> index 000..ac58bfc
>>> --- /dev/null
>>> +++ b/package/utils/urandom-seed/Makefile
>>> @@ -0,0 +1,53 @@
>>> +#
>>> +# Copyright (C) 2016 Etienne CHAMPETIER 
>>> +#
>>> +# This is free software, licensed under the GNU General Public License v2.
>>> +# See /LICENSE for more information.
>>> +#
>>> +
>>> +include $(TOPDIR)/rules.mk
>>> +
>>> +PKG_NAME:=urandom-seed
>>> +PKG_RELEASE:=1
>>> +PKG_LICENSE:=GPL-2.0
>>> +PKG_LICENSE_FILES:=COPYING
>>> +PKG_BUILD_DIR := $(BUILD_DIR)/$(PKG_NAME)_$(PKG_RELEASE)
>>> +PKG_FLAGS:=nonshared
>>> +
>>> +include $(INCLUDE_DIR)/package.mk
>>> +
>>> +define Package/urandom-seed
>>> +  SECTION:=utils
>>> +  CATEGORY:=Base system
>>> +  TITLE:=Seed /dev/urandom on startup
>>> +  MAINTAINER:=Etienne CHAMPETIER 
>>> +endef
>>> +
>>> +define Package/urandom-seed/description
>>> +This package takes care of loading a previously saved seed into 
>>> /dev/urandom,
>>> +and save a new seed from getrandom()
>>> +endef
>>> +
>>> +define Build/Prepare
>>> + mkdir -p $(PKG_BUILD_DIR)
>>> +endef
>>> +
>>> +define Build/Configure
>>> +endef
>>> +
>>> +define Build/Compile
>>> + $(TARGET_CC) $(TARGET_CFLAGS) ./files/getrandom.c -o 
>>> $(PKG_BUILD_DIR)/getrandom
>>> +endef
>>> +
>>> +define Package/urandom-seed/install
>>> + $(INSTALL_DIR) $(1)/usr/bin
>>> + $(INSTALL_BIN) $(PKG_BUILD_DIR)/getrandom $(1)/usr/bin/
>>> +
>>> + $(INSTALL_DIR) $(1)/lib/preinit
>>> + $(INSTALL_DATA) ./files/81_urandom_seed.preinit 
>>> $(1)/lib/preinit/81_urandom_seed
>>> +
>>> + $(INSTALL_DIR) $(1)/etc/init.d
>>> + $(INSTALL_BIN) ./files/urandom_seed.init $(1)/etc/init.d/urandom_seed
>>> +endef
>>> +
>>> +$(eval $(call BuildPackage,urandom-seed))
>>> diff --git a/package/utils/urandom-seed/files/81_urandom_seed.preinit 
>>> b/package/utils/urandom-seed/files/81_urandom_seed.preinit
>>> new file mode 100644
>>> index 000..27ff587
>>> --- /dev/null
>>> +++ b/package/utils/urandom-seed/files/81_urandom_seed.preinit
>>> @@ -0,0 +1,15 @@
>>> +#!/bin/sh
>>> +
>>> +do_urandom_seed() {
>>> +S=/etc/urandom.seed
>>> +U=/dev/urandom
>>> +
>>> +[ -c $U ] || { echo "Something is wrong with $U"; return; }
>>> +[ -f $S ] || { echo "Seed file not found: $S"; return; }
>>> +[ -O $S -a -G $S -a ! -x $S ] || { echo "Wrong owner / permissions for 
>>> $S"; return; }
>>> +
>>> +echo "Seeding $U with $S"
>>> +cat $S > $U
>>> +}
>>> +
>>> +boot_hook_add preinit_main do_urandom_seed
>>> diff --git a/package/utils/urandom-seed/files/getrandom.c 
>>> b/package/utils/urandom-seed/files/getrandom.c
>>> new file mode 100644
>>> index 000..2093ef8
>>> --- /dev/null
>>> +++ b/package/utils/urandom-seed/files/getrandom.c
>>> @@ -0,0 +1,58 @@
>>> +/*
>>> + * Copyright (C) 2016 Etienne Champetier 
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License as published by
>>> + * the Free Software Foundation; either

Re: [LEDE-DEV] [PATCH] urandom-seed: add initial implementation

2016-06-03 Thread Etienne Champetier

Hi John,

2016-06-03 11:00 GMT+02:00 John Crispin :
> Hi Etienne,
>
> comment inline ...
>
> On 02/06/2016 23:21, Etienne CHAMPETIER wrote:
>> This package:
>> 1) seed /dev/urandom with a saved seed as early as possible
>> (using /lib/preinit/81_urandom_seed)
>> 2) save a new seed using getrandom() so we are sure /dev/urandom
>>pool is initialized (using /etc/init.d/urandom_seed)
>>
>> seed size is 512 bytes (ie /proc/sys/kernel/random/poolsize / 8)
>> it's the same size as in ubuntu 14.04 and all systemd systems
>>
>> seed file is /etc/urandom.seed (need a writable path)
>>
>> seeding /dev/urandom doesn't change entropy estimation, so we still have
>> "random: ubus urandom read with 4 bits of entropy available"
>> messages in the logs, but we can now ignore them
>>
>> Once tested on enough configuration (jffs2/ext4/ubifs/...)
>> this package should be added to DEFAULT_PACKAGES
>>
>> We could also add an urandom.seed at build time to improve first boot
>>
>> Signed-off-by: Etienne CHAMPETIER 
>> ---
>>  package/utils/urandom-seed/Makefile| 53 
>>  .../urandom-seed/files/81_urandom_seed.preinit | 15 ++
>>  package/utils/urandom-seed/files/getrandom.c   | 58 
>> ++
>>  package/utils/urandom-seed/files/urandom_seed.init | 19 +++
>>  4 files changed, 145 insertions(+)
>>  create mode 100644 package/utils/urandom-seed/Makefile
>>  create mode 100644 package/utils/urandom-seed/files/81_urandom_seed.preinit
>>  create mode 100644 package/utils/urandom-seed/files/getrandom.c
>>  create mode 100644 package/utils/urandom-seed/files/urandom_seed.init
>>
>> diff --git a/package/utils/urandom-seed/Makefile 
>> b/package/utils/urandom-seed/Makefile
>> new file mode 100644
>> index 000..ac58bfc
>> --- /dev/null
>> +++ b/package/utils/urandom-seed/Makefile
>> @@ -0,0 +1,53 @@
>> +#
>> +# Copyright (C) 2016 Etienne CHAMPETIER 
>> +#
>> +# This is free software, licensed under the GNU General Public License v2.
>> +# See /LICENSE for more information.
>> +#
>> +
>> +include $(TOPDIR)/rules.mk
>> +
>> +PKG_NAME:=urandom-seed
>> +PKG_RELEASE:=1
>> +PKG_LICENSE:=GPL-2.0
>> +PKG_LICENSE_FILES:=COPYING
>> +PKG_BUILD_DIR := $(BUILD_DIR)/$(PKG_NAME)_$(PKG_RELEASE)
>> +PKG_FLAGS:=nonshared
>> +
>> +include $(INCLUDE_DIR)/package.mk
>> +
>> +define Package/urandom-seed
>> +  SECTION:=utils
>> +  CATEGORY:=Base system
>> +  TITLE:=Seed /dev/urandom on startup
>> +  MAINTAINER:=Etienne CHAMPETIER 
>> +endef
>> +
>> +define Package/urandom-seed/description
>> +This package takes care of loading a previously saved seed into 
>> /dev/urandom,
>> +and save a new seed from getrandom()
>> +endef
>> +
>> +define Build/Prepare
>> + mkdir -p $(PKG_BUILD_DIR)
>> +endef
>> +
>> +define Build/Configure
>> +endef
>> +
>> +define Build/Compile
>> + $(TARGET_CC) $(TARGET_CFLAGS) ./files/getrandom.c -o 
>> $(PKG_BUILD_DIR)/getrandom
>> +endef
>> +
>> +define Package/urandom-seed/install
>> + $(INSTALL_DIR) $(1)/usr/bin
>> + $(INSTALL_BIN) $(PKG_BUILD_DIR)/getrandom $(1)/usr/bin/
>> +
>> + $(INSTALL_DIR) $(1)/lib/preinit
>> + $(INSTALL_DATA) ./files/81_urandom_seed.preinit 
>> $(1)/lib/preinit/81_urandom_seed
>> +
>> + $(INSTALL_DIR) $(1)/etc/init.d
>> + $(INSTALL_BIN) ./files/urandom_seed.init $(1)/etc/init.d/urandom_seed
>> +endef
>> +
>> +$(eval $(call BuildPackage,urandom-seed))
>> diff --git a/package/utils/urandom-seed/files/81_urandom_seed.preinit 
>> b/package/utils/urandom-seed/files/81_urandom_seed.preinit
>> new file mode 100644
>> index 000..27ff587
>> --- /dev/null
>> +++ b/package/utils/urandom-seed/files/81_urandom_seed.preinit
>> @@ -0,0 +1,15 @@
>> +#!/bin/sh
>> +
>> +do_urandom_seed() {
>> +S=/etc/urandom.seed
>> +U=/dev/urandom
>> +
>> +[ -c $U ] || { echo "Something is wrong with $U"; return; }
>> +[ -f $S ] || { echo "Seed file not found: $S"; return; }
>> +[ -O $S -a -G $S -a ! -x $S ] || { echo "Wrong owner / permissions for 
>> $S"; return; }
>> +
>> +echo "Seeding $U with $S"
>> +cat $S > $U
>> +}
>> +
>> +boot_hook_add preinit_main do_urandom_seed
>> diff --git a/package/utils/urandom-seed/files/getrandom.c 
>> b/package/utils/urandom-seed/files/getrandom.c
>> new file mode 100644
>> index 000..2093ef8
>> --- /dev/null
>> +++ b/package/utils/urandom-seed/files/getrandom.c
>> @@ -0,0 +1,58 @@
>> +/*
>> + * Copyright (C) 2016 Etienne Champetier 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the

[LEDE-DEV] [PATCH 1/3] [ubox] remove unnecessary size struct between messages

2016-06-03 Thread Dan Bugnar

From: Dan Bugnar 

The next message needs to be written after the data of current message.
This was adding "sizeof(struct log_head)" bytes between messages.

Signed-off-by: Dan Bugnar 
---
 log/syslog.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/log/syslog.c b/log/syslog.c
index e8b6774..2042e93 100644
--- a/log/syslog.c
+++ b/log/syslog.c
@@ -51,7 +51,7 @@ static regex_t pat_tstamp;
 static struct log_head*
 log_next(struct log_head *h, int size)
 {
-   struct log_head *n = (struct log_head *) >data[PAD(sizeof(struct 
log_head) + size)];
+   struct log_head *n = (struct log_head *) >data[size];
 
return (n >= log_end) ? (log) : (n);
 }
-- 
2.8.1


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH 3/3] [ubox] logd: add ubus reload method

2016-06-03 Thread Dan Bugnar

Add ubus method to set the buffer size.
Example:
ubus call log reload "{\"log_buffer_size\":size}"

Signed-off-by: Dan Bugnar 
---
 log/logd.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/log/logd.c b/log/logd.c
index 27d3cac..563c545 100644
--- a/log/logd.c
+++ b/log/logd.c
@@ -26,11 +26,16 @@
 
 #include "syslog.h"
 
+#define LOG_DEFAULT_SIZE 16 * 1024
+
 int debug = 0;
 static struct blob_buf b;
 static struct ubus_auto_conn conn;
 static LIST_HEAD(clients);
 
+static const struct blobmsg_policy reload_policy =
+   { .name = "log_buffer_size", .type = BLOBMSG_TYPE_INT32 };
+
 static const struct blobmsg_policy read_policy =
{ .name = "lines", .type = BLOBMSG_TYPE_INT32 };
 
@@ -124,9 +129,29 @@ write_log(struct ubus_context *ctx, struct ubus_object 
*obj,
return 0;
 }
 
+static int
+reload_log(struct ubus_context *ctx, struct ubus_object *obj,
+   struct ubus_request_data *req, const char *method,
+   struct blob_attr *msg)
+{
+   struct blob_attr *tb;
+   int size = 0;
+
+   if (msg) {
+   blobmsg_parse(_policy, 1, , blob_data(msg), 
blob_len(msg));
+   if (tb) {
+   size = blobmsg_get_u32(tb);
+   log_buffer_reinit(size < 1 ? LOG_DEFAULT_SIZE : size * 
1024);
+   }
+   }
+
+   return 0;
+}
+
 static const struct ubus_method log_methods[] = {
{ .name = "read", .handler = read_log, .policy = _policy, 
.n_policy = 1 },
{ .name = "write", .handler = write_log, .policy = _policy, 
.n_policy = 1 },
+   { .name = "reload", .handler = reload_log, .policy = _policy, 
.n_policy = 1 },
 };
 
 static struct ubus_object_type log_object_type =
-- 
2.8.1


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH 2/3] [ubox] syslog: change log buffer size

2016-06-03 Thread Dan Bugnar

Change the log buffer size and copy the messages.
Copy the messages from the oldest to newest using the log_list.
First time we calculate the size of the all entries. The log_entries_size
calculates the size indifferent of the positions of the newest and oldest.

If we want to increase the log buffer size is simple, we just copy from the 
oldest
message to the newest all the messages into the new buffer.

In case we shrink the buffer we go over messages and decrease the entries size
with the size of each message until the entries size is less or equal to the new
size we allocate the new buffer.

Signed-off-by: Dan Bugnar 
---
 log/syslog.c | 36 +++-
 log/syslog.h |  2 +-
 2 files changed, 28 insertions(+), 10 deletions(-)

diff --git a/log/syslog.c b/log/syslog.c
index 2042e93..e24c678 100644
--- a/log/syslog.c
+++ b/log/syslog.c
@@ -42,7 +42,7 @@
 #define PAD(x) (x % 4) ? (((x) - (x % 4)) + 4) : (x)
 
 static char *log_dev = LOG_DEFAULT_SOCKET;
-static int log_size = LOG_DEFAULT_SIZE;
+static int log_size = 0;
 static struct log_head *log, *log_end, *oldest, *newest;
 static int current_id = 0;
 static regex_t pat_prio;
@@ -213,6 +213,15 @@ syslog_open(void)
return 0;
 }
 
+static inline int 
+log_entries_size()
+{
+   if (newest > oldest)
+   return (newest - oldest);
+   else
+   return (log_end - oldest + newest - log);
+}
+
 struct log_head*
 log_list(int count, struct log_head *h)
 {
@@ -237,26 +246,38 @@ log_list(int count, struct log_head *h)
 }
 
 int
-log_buffer_init(int size)
+log_buffer_reinit(int size)
 {
+   if (size <= 0)
+   size = LOG_DEFAULT_SIZE;
+   if (log_size == size)
+   return 0;
+
struct log_head *_log = malloc(size);
 
if (!_log) {
+   oldest = newest = log = NULL;
fprintf(stderr, "Failed to initialize log buffer with size 
%d\n", log_size);
return -1;
}
 
memset(_log, 0, size);
 
-   if (log && ((log_size + sizeof(struct log_head)) < size)) {
+   if (log) {
struct log_head *start = _log;
struct log_head *end = ((void*) _log) + size;
struct log_head *l;
+   int entries_size = log_entries_size();
 
l = log_list(0, NULL);
while ((start < end) && l && l->size) {
-   memcpy(start, l, PAD(sizeof(struct log_head) + 
l->size));
-   start = (struct log_head *) >data[PAD(l->size)];
+   int copy_len = PAD(sizeof(struct log_head)) + l->size;
+   if (entries_size < size) {
+   memcpy(start, l, copy_len);
+   start = (struct log_head *) 
>data[l->size];
+   } else{
+   entries_size -= copy_len;
+   }
l = log_list(0, l);
}
free(log);
@@ -276,13 +297,10 @@ log_buffer_init(int size)
 void
 log_init(int _log_size)
 {
-   if (_log_size > 0)
-   log_size = _log_size;
-
regcomp(_prio, "^<([0-9]*)>(.*)", REG_EXTENDED);
regcomp(_tstamp, "^\[[ 0]*([0-9]*).([0-9]*)] (.*)", REG_EXTENDED);
 
-   if (log_buffer_init(log_size)) {
+   if (log_buffer_reinit(_log_size)) {
fprintf(stderr, "Failed to allocate log memory\n");
exit(-1);
}
diff --git a/log/syslog.h b/log/syslog.h
index 81a039f..ed5a41b 100644
--- a/log/syslog.h
+++ b/log/syslog.h
@@ -35,7 +35,7 @@ void log_shutdown(void);
 
 typedef void (*log_list_cb)(struct log_head *h);
 struct log_head* log_list(int count, struct log_head *h);
-int log_buffer_init(int size);
+int log_buffer_reinit(int size);
 void log_add(char *buf, int size, int source);
 void ubus_notify_log(struct log_head *l);
 
-- 
2.8.1


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCHv3 1/1] [brcm63xx] Add initial support for EVG2000

2016-06-03 Thread Graham Fairweather

Hi and thanks.

On 3 June 2016 at 12:07, Álvaro Fernández Rojas  wrote:
> Hello Graham,
>
> Pulled into my staging tree with some changes (whitespace fixes, cleanups...):
> https://git.lede-project.org/?p=lede/noltari/staging.git;a=shortlog;h=refs/heads/brcm63xx-next
>
> Regards,
> Álvaro.
>
> El 23/5/16 a las 0:56, Xotic750 escribió:
>> From: Graham Fairweather 
>>
>> This patch adds support for the Netgear EVG2000 VoIP Gateway to the
>> bcm63xx targets.
>> Ran 'make target/linux/refresh V=s' after update to kernel 4.4.10 from
>> 4.4.8 where the initial patch was added.
>> This device was not sold to the general public, but rather is/was
>> provided by telcos to customers in Sweden, Australia, Singapore and
>> other parts of asia.
>> System-On-Chip: Broadcom BCM6369 (2 * BMIPS4350 v3.1 / 400 MHz)
>> Flash size: 16 MiB
>> RAM size: 64 MiB
>> Wireless: BCM4322 802.11b/g/n (onboard)
>> Ethernet: Broadcom BCM53115
>> USB: 2 x USB 2.0
>> Known issues:
>>  - Unable to detect 53115 switch. This appear to be a problem with
>> probing for the PHY using MDIO and results in error 5. Doesn't seem to
>> be a problem with the configuration, and could use someone with
>> experience to have a look at it.
>>  - Uses the b43 driver as using the OpenWRT/LEDE broadcom-wl driver
>> fails to load the firmware for the 4322, so 802.11n is not supported.
>> The factory build uses a newer broadcom-wl driver.
>>  - No support for the 2 VoIP ports (not attempted)
>> More info on the device and the research can be found at:
>> https://wiki.openwrt.org/toh/netgear/evg2000
>> https://wikidevi.com/wiki/Netgear_EVG2000
>> https://github.com/Xotic750/mirror-lede/tree/evg2000
>> https://forum.openwrt.org/viewtopic.php?id=63950
>> Signed-off-by: Graham Fairweather 
>> ---
>>  .../linux/brcm63xx/base-files/etc/board.d/01_leds  |   7 ++
>>  .../brcm63xx/base-files/etc/board.d/02_network |   1 +
>>  target/linux/brcm63xx/base-files/etc/diag.sh   |   3 +
>>  .../base-files/etc/uci-defaults/09_fix_crc |   2 +-
>>  target/linux/brcm63xx/base-files/lib/brcm63xx.sh   |   3 +
>>  .../lib/preinit/05_init_interfaces_brcm63xx|   1 +
>>  target/linux/brcm63xx/dts/evg2000.dts  | 103 
>> +
>>  target/linux/brcm63xx/image/Makefile   |   2 +
>>  .../brcm63xx/patches-4.1/575-board_EVG2000.patch   |  62 +
>>  ...-m25p80-use-parsers-if-provided-in-flash-.patch |   2 +-
>>  ...CES-m25p80-add-support-for-limiting-reads.patch |   4 +-
>>  .../414-MTD-m25p80-allow-passing-pp_data.patch |   2 +-
>>  .../brcm63xx/patches-4.4/575-board_EVG2000.patch   |  62 +
>>  target/linux/brcm63xx/profiles/netgear.mk  |  10 ++
>>  14 files changed, 259 insertions(+), 5 deletions(-)
>>  create mode 100644 target/linux/brcm63xx/dts/evg2000.dts
>>  create mode 100644 target/linux/brcm63xx/patches-4.1/575-board_EVG2000.patch
>>  create mode 100644 target/linux/brcm63xx/patches-4.4/575-board_EVG2000.patch
>>
>> diff --git a/target/linux/brcm63xx/base-files/etc/board.d/01_leds 
>> b/target/linux/brcm63xx/base-files/etc/board.d/01_leds
>> index 8339254..4163214 100755
>> --- a/target/linux/brcm63xx/base-files/etc/board.d/01_leds
>> +++ b/target/linux/brcm63xx/base-files/etc/board.d/01_leds
>> @@ -24,6 +24,13 @@ dgnd3700v1_dgnd3800b)
>>   ucidef_set_led_usbdev "usb1" "USB1" "DGND3700v1_3800B:green:usb-back" 
>> "1-1"
>>   ucidef_set_led_usbdev "usb2" "USB2" "DGND3700v1_3800B:green:usb-front" 
>> "1-2"
>>   ;;
>> +evg2000)
>> + ucidef_set_led_netdev "lan" "LAN" "EVG2000:green:lan" "eth0"
>> + ucidef_set_led_netdev "wan" "WAN" "EVG2000:green:wan" "eth1"
>> + ucidef_set_led_netdev "wlan0" "WIFI" "EVG2000:green:wireless" "wlan0"
>> + ucidef_set_led_usbdev "usb1" "USB1" "EVG2000:green:voip1" "1-1"
>> + ucidef_set_led_usbdev "usb2" "USB2" "EVG2000:green:voip2" "1-2"
>> + ;;
>>  fast2704n)
>>   ucidef_set_led_netdev "wan" "WAN" "F@ST2704N:green:inet" "eth0.2"
>>   ;;
>> diff --git a/target/linux/brcm63xx/base-files/etc/board.d/02_network 
>> b/target/linux/brcm63xx/base-files/etc/board.d/02_network
>> index f96da08..83367c1 100755
>> --- a/target/linux/brcm63xx/base-files/etc/board.d/02_network
>> +++ b/target/linux/brcm63xx/base-files/etc/board.d/02_network
>> @@ -11,6 +11,7 @@ board_config_update
>>  case "$(brcm63xx_board_name)" in
>>
>>  cvg834g |\
>> +evg2000 |\
>>  rta770bw |\
>>  rta770w |\
>>  spw303v |\
>> diff --git a/target/linux/brcm63xx/base-files/etc/diag.sh 
>> b/target/linux/brcm63xx/base-files/etc/diag.sh
>> index b864964..6ac2459 100644
>> --- a/target/linux/brcm63xx/base-files/etc/diag.sh
>> +++ b/target/linux/brcm63xx/base-files/etc/diag.sh
>> @@ -70,6 +70,9 @@ set_state() {
>>   dgnd3700v1_dgnd3800b)
>>   status_led="DGND3700v1_3800B:green:power"
>>   ;;
>> + evg2000)
>> + status_led="EVG2000:green:power"
>> + ;;

Re: [LEDE-DEV] [PATCH libubox] blobmsg_json: add new functions blobmsg_format_json_value*

2016-06-03 Thread Matthias Schiffer

On 06/03/2016 11:05 AM, John Crispin wrote:
> 
> 
> On 01/06/2016 22:27, Matthias Schiffer wrote:
>> The current blobmsg_format_json* functions will return invalid JSON when
>> the "list" argument is given as false (blobmsg_format_element() will
>> output the name of the blob_attr as if the value is printed as part of a
>> JSON object).
>>
>> To avoid breaking software relying on this behaviour, introduce new
>> functions which will never print the blob_attr name and thus always
>> produce valid JSON.
> 
> what software relies on this function/behaviour ? maybe we should mark
> the current implementation as deprected and drop support in time X.
> producing broken json syntax seems very fragile.
> 
>   John

The most promiment usage is the output of `ubus list -v`, most other uses
seem to be just error messages.

I've found a number of other issues in blobmsg_json (more broken JSON
output, missing or broken allocation failure handling, ...). You can drop
this patch for now, I'll send a new version together with some other
patches next week.

Three more remarks/questions:

1) I'd like to add two more blobmsg datatypes, F32 and F64 for
single/double precision floating-point numbers, to complete the
JSON<->blobmsg mapping. I've already looked into possible platform-specific
encoding issues of floats, the only platform-specific part seems to be some
NaN encodings, which would need to be mapped to a generic NaN encoding.
(NaN is not valid JSON, so it wouldn't be important for blobmsg_json
anyways; json-c accepts NaN and +/- Infinity though).
Usecase: I'm currently implementing a configuration storage daemon as part
of my GSoC project. In particular, I think that geocoordinates would be
nice to store as floats.

2) blogmsg currently doesn't allow tables with empty keys. In JSON, the
empty string is not special and can be used as a key. I'd like to adjust
blobmsg to allow this.

3) Another thing I'm working on is a blobtree library. blobtrees are very
similar to blobmsg, but tables and arrays store just a list of pointers to
the child blobs. This allows efficient manipulation of such trees (for the
mentioned configuration storage daemon), while still making conversion from
and to blobmsg as simple as possible.

1) and 2) would allow blobmsg to store everything that json-c can (with the
caveat that json-c stores integers as int64 internally, while blobmsg_json
uses int32) - do you think these changes make sense?

Would there also be general interest in 3), so it might be integrated into
libubox?

Regards,
Matthias

> 
>>
>> Signed-off-by: Matthias Schiffer 
>> ---
>>  blobmsg_json.c | 49 -
>>  blobmsg_json.h | 14 ++
>>  2 files changed, 50 insertions(+), 13 deletions(-)
>>
>> diff --git a/blobmsg_json.c b/blobmsg_json.c
>> index 5713948..538c816 100644
>> --- a/blobmsg_json.c
>> +++ b/blobmsg_json.c
>> @@ -207,7 +207,7 @@ static void blobmsg_format_string(struct strbuf *s, 
>> const char *str)
>>  
>>  static void blobmsg_format_json_list(struct strbuf *s, struct blob_attr 
>> *attr, int len, bool array);
>>  
>> -static void blobmsg_format_element(struct strbuf *s, struct blob_attr 
>> *attr, bool array, bool head)
>> +static void blobmsg_format_element(struct strbuf *s, struct blob_attr 
>> *attr, bool without_name, bool head)
>>  {
>>  const char *data_str;
>>  char buf[32];
>> @@ -217,7 +217,7 @@ static void blobmsg_format_element(struct strbuf *s, 
>> struct blob_attr *attr, boo
>>  if (!blobmsg_check_attr(attr, false))
>>  return;
>>  
>> -if (!array && blobmsg_name(attr)[0]) {
>> +if (!without_name && blobmsg_name(attr)[0]) {
>>  blobmsg_format_string(s, blobmsg_name(attr));
>>  blobmsg_puts(s, ": ", s->indent ? 2 : 1);
>>  }
>> @@ -286,22 +286,26 @@ static void blobmsg_format_json_list(struct strbuf *s, 
>> struct blob_attr *attr, i
>>  blobmsg_puts(s, (array ? "]" : "}"), 1);
>>  }
>>  
>> +static void setup_strbuf(struct strbuf *s, struct blob_attr *attr, 
>> blobmsg_json_format_t cb, void *priv, int indent) {
>> +s->len = blob_len(attr);
>> +s->buf = malloc(s->len);
>> +s->pos = 0;
>> +s->custom_format = cb;
>> +s->priv = priv;
>> +s->indent = false;
>> +
>> +if (indent >= 0) {
>> +s->indent = true;
>> +s->indent_level = indent;
>> +}
>> +}
>> +
>>  char *blobmsg_format_json_with_cb(struct blob_attr *attr, bool list, 
>> blobmsg_json_format_t cb, void *priv, int indent)
>>  {
>>  struct strbuf s;
>>  bool array;
>>  
>> -s.len = blob_len(attr);
>> -s.buf = malloc(s.len);
>> -s.pos = 0;
>> -s.custom_format = cb;
>> -s.priv = priv;
>> -s.indent = false;
>> -
>> -if (indent >= 0) {
>> -s.indent = true;
>> -s.indent_level = indent;
>> -}
>> +setup_strbuf(, attr, cb, priv, indent);
>>  
>>  array = blob_is_extended(attr) &&

Re: [LEDE-DEV] [PATCHv3 1/1] [brcm63xx] Add initial support for EVG2000

2016-06-03 Thread Álvaro Fernández Rojas

Hello Graham,

Pulled into my staging tree with some changes (whitespace fixes, cleanups...):
https://git.lede-project.org/?p=lede/noltari/staging.git;a=shortlog;h=refs/heads/brcm63xx-next

Regards,
Álvaro.

El 23/5/16 a las 0:56, Xotic750 escribió:
> From: Graham Fairweather 
>
> This patch adds support for the Netgear EVG2000 VoIP Gateway to the
> bcm63xx targets.
> Ran 'make target/linux/refresh V=s' after update to kernel 4.4.10 from
> 4.4.8 where the initial patch was added.
> This device was not sold to the general public, but rather is/was
> provided by telcos to customers in Sweden, Australia, Singapore and
> other parts of asia.
> System-On-Chip: Broadcom BCM6369 (2 * BMIPS4350 v3.1 / 400 MHz)
> Flash size: 16 MiB
> RAM size: 64 MiB
> Wireless: BCM4322 802.11b/g/n (onboard)
> Ethernet: Broadcom BCM53115
> USB: 2 x USB 2.0
> Known issues:
>  - Unable to detect 53115 switch. This appear to be a problem with
> probing for the PHY using MDIO and results in error 5. Doesn't seem to
> be a problem with the configuration, and could use someone with
> experience to have a look at it.
>  - Uses the b43 driver as using the OpenWRT/LEDE broadcom-wl driver
> fails to load the firmware for the 4322, so 802.11n is not supported.
> The factory build uses a newer broadcom-wl driver.
>  - No support for the 2 VoIP ports (not attempted)
> More info on the device and the research can be found at:
> https://wiki.openwrt.org/toh/netgear/evg2000
> https://wikidevi.com/wiki/Netgear_EVG2000
> https://github.com/Xotic750/mirror-lede/tree/evg2000
> https://forum.openwrt.org/viewtopic.php?id=63950
> Signed-off-by: Graham Fairweather 
> ---
>  .../linux/brcm63xx/base-files/etc/board.d/01_leds  |   7 ++
>  .../brcm63xx/base-files/etc/board.d/02_network |   1 +
>  target/linux/brcm63xx/base-files/etc/diag.sh   |   3 +
>  .../base-files/etc/uci-defaults/09_fix_crc |   2 +-
>  target/linux/brcm63xx/base-files/lib/brcm63xx.sh   |   3 +
>  .../lib/preinit/05_init_interfaces_brcm63xx|   1 +
>  target/linux/brcm63xx/dts/evg2000.dts  | 103 
> +
>  target/linux/brcm63xx/image/Makefile   |   2 +
>  .../brcm63xx/patches-4.1/575-board_EVG2000.patch   |  62 +
>  ...-m25p80-use-parsers-if-provided-in-flash-.patch |   2 +-
>  ...CES-m25p80-add-support-for-limiting-reads.patch |   4 +-
>  .../414-MTD-m25p80-allow-passing-pp_data.patch |   2 +-
>  .../brcm63xx/patches-4.4/575-board_EVG2000.patch   |  62 +
>  target/linux/brcm63xx/profiles/netgear.mk  |  10 ++
>  14 files changed, 259 insertions(+), 5 deletions(-)
>  create mode 100644 target/linux/brcm63xx/dts/evg2000.dts
>  create mode 100644 target/linux/brcm63xx/patches-4.1/575-board_EVG2000.patch
>  create mode 100644 target/linux/brcm63xx/patches-4.4/575-board_EVG2000.patch
>
> diff --git a/target/linux/brcm63xx/base-files/etc/board.d/01_leds 
> b/target/linux/brcm63xx/base-files/etc/board.d/01_leds
> index 8339254..4163214 100755
> --- a/target/linux/brcm63xx/base-files/etc/board.d/01_leds
> +++ b/target/linux/brcm63xx/base-files/etc/board.d/01_leds
> @@ -24,6 +24,13 @@ dgnd3700v1_dgnd3800b)
>   ucidef_set_led_usbdev "usb1" "USB1" "DGND3700v1_3800B:green:usb-back" 
> "1-1"
>   ucidef_set_led_usbdev "usb2" "USB2" "DGND3700v1_3800B:green:usb-front" 
> "1-2"
>   ;;
> +evg2000)
> + ucidef_set_led_netdev "lan" "LAN" "EVG2000:green:lan" "eth0"
> + ucidef_set_led_netdev "wan" "WAN" "EVG2000:green:wan" "eth1"
> + ucidef_set_led_netdev "wlan0" "WIFI" "EVG2000:green:wireless" "wlan0"
> + ucidef_set_led_usbdev "usb1" "USB1" "EVG2000:green:voip1" "1-1"
> + ucidef_set_led_usbdev "usb2" "USB2" "EVG2000:green:voip2" "1-2"
> + ;;
>  fast2704n)
>   ucidef_set_led_netdev "wan" "WAN" "F@ST2704N:green:inet" "eth0.2"
>   ;;
> diff --git a/target/linux/brcm63xx/base-files/etc/board.d/02_network 
> b/target/linux/brcm63xx/base-files/etc/board.d/02_network
> index f96da08..83367c1 100755
> --- a/target/linux/brcm63xx/base-files/etc/board.d/02_network
> +++ b/target/linux/brcm63xx/base-files/etc/board.d/02_network
> @@ -11,6 +11,7 @@ board_config_update
>  case "$(brcm63xx_board_name)" in
>  
>  cvg834g |\
> +evg2000 |\
>  rta770bw |\
>  rta770w |\
>  spw303v |\
> diff --git a/target/linux/brcm63xx/base-files/etc/diag.sh 
> b/target/linux/brcm63xx/base-files/etc/diag.sh
> index b864964..6ac2459 100644
> --- a/target/linux/brcm63xx/base-files/etc/diag.sh
> +++ b/target/linux/brcm63xx/base-files/etc/diag.sh
> @@ -70,6 +70,9 @@ set_state() {
>   dgnd3700v1_dgnd3800b)
>   status_led="DGND3700v1_3800B:green:power"
>   ;;
> + evg2000)
> + status_led="EVG2000:green:power"
> + ;;
>   fast2504n)
>   status_led="fast2504n:green:ok"
>   ;;
> diff --git a/target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc 
>

Re: [LEDE-DEV] [PATCH] fix uClibc-ng scanf check

2016-06-03 Thread Alexey Brodkin

Hi Waldemar,

On Fri, 2016-06-03 at 04:23 +0200, Waldemar Brodkorb wrote:
> uClibc-ng tries to be compatible with GNU libc and defines
> __GLIBC__ and pretend to be version 2.2.
> We once changed it to 2.10, but then some hard to fix problems
> in different software packages (gcc) occured.
> It would be better if we disable the special GNU libc checks
> for uClibc-ng here. uClibc-ng implements the required scanf
> functionality.
> 
> Signed-off-by: Waldemar Brodkorb 
> ---
>  configure.ac | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/configure.ac b/configure.ac
> index f36b18c..4661c0d 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -581,7 +581,7 @@ AC_CACHE_VAL([scanf_cv_alloc_modifier],
>   #include 
>   #include 
>  
> - #ifdef __GLIBC__
> + #if defined(__GLIBC__) && !defined(__UCLIBC__)
>  
>   #if !(__GLIBC_PREREQ(2, 7))
>   #error %m is not available

Even though this is a very minor and clean change I don't like this
approach. We're again implicitly assume something.

IMHO much better approach would be to include a compile test for
small source that uses scanf() with "%as"/"%ms".

That way we may remove all dependencies on either GLIBC/UCLIBC/MUSL etc.

-Alexey
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] git.openwrt.org site half broken

2016-06-03 Thread Etienne Champetier

2016-06-03 11:13 GMT+02:00 John Crispin :
>
>
> On 02/06/2016 13:20, Etienne Champetier wrote:
>> Hi,
>>
>> someone messed with git.openwrt.org nginx config, i can't get the js and css.
>>
>> see https://git.openwrt.org/project/static/gitweb.css (doesn't look
>> like a css :) )
>>
>> Cheers
>> Etienne
>>
>
> that url looks weird.
> -> https://git.openwrt.org/static/gitweb.css
> works and for me the service seems to be functional.

Indeed, i don't know were i found
https://git.openwrt.org/project/
right url is
https://git.openwrt.org/

>
> John

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCHv4 1/1] [brcm63xx] Fix the logged CPU variant

2016-06-03 Thread Álvaro Fernández Rojas

NACK, this doesn't add any funcionality and original firmwares show 
these SoCs as their generic CPU IDs (e.g: 6368 for the 6369).


El 23/5/16 a las 0:46, Xotic750 escribió:

From: Graham Fairweather 

This patch fixes the logged detected CPU ID when an equivalent is used,
like in the case where we have a bcm6369 and configuration for a
bcm6368 is used.
So, it will display 'Detected Broadcom 0x6369 CPU revision b2' instead of
'Detected Broadcom 0x6368 CPU revision b2'.
More info can be found at:
https://forum.openwrt.org/viewtopic.php?id=64621
https://github.com/Xotic750/mirror-lede/tree/fix_cpu_id
Signed-off-by: Graham Fairweather 
---
  .../330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch  | 9 +
  .../330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch  | 9 +
  2 files changed, 18 insertions(+)

diff --git 
a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
 
b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
index 661abf6..23491aa 100644
--- 
a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
+++ 
b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
@@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant 
helper
bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT;
   
   	switch (bcm63xx_cpu_id) {

+@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void)
+   bcm63xx_memory_size = detect_memory_size();
+
+   printk(KERN_INFO "Detected Broadcom 0x%04x CPU revision %02x\n",
+- bcm63xx_cpu_id, bcm63xx_cpu_rev);
++ bcm63xx_cpu_variant, bcm63xx_cpu_rev);
+   printk(KERN_INFO "CPU frequency is %u MHz\n",
+  bcm63xx_cpu_freq / 100);
+   printk(KERN_INFO "%uMB of RAM installed\n",
  --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h
  +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h
  @@ -19,6 +19,7 @@
diff --git 
a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
 
b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
index 661abf6..330a9e6 100644
--- 
a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
+++ 
b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
@@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant 
helper
bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT;
   
   	switch (bcm63xx_cpu_id) {

+@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void)
+   bcm63xx_memory_size = detect_memory_size();
+
+   pr_info("Detected Broadcom 0x%04x CPU revision %02x\n",
+-  bcm63xx_cpu_id, bcm63xx_cpu_rev);
++  bcm63xx_cpu_variant, bcm63xx_cpu_rev);
+   pr_info("CPU frequency is %u MHz\n",
+   bcm63xx_cpu_freq / 100);
+   pr_info("%uMB of RAM installed\n",
  --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h
  +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h
  @@ -19,6 +19,7 @@



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.

2016-06-03 Thread John Crispin



On 01/06/2016 20:21, Ben Greear wrote:
> On 06/01/2016 11:07 AM, John Crispin wrote:
>> Hi Ben,
>>
>> also inclined to reject this one. it will open up the pandoras box and
>> we will end up maintaining piles of diffconfig files. it would make
>> morse sense to document what the script does inside web.git as a "how to
>> build" or "getting started" page
> 
> I do not have much history with LEDE/WRT, but is the diffconfig output
> really that fragile?
> 
> I will be willing to maintain the x86-64 and probably Ventana
> diffconfigs, and even if it totally fails, you have not lost
> any functionality since the main infrastructure is unchanged.

for how long and will all the other people submitting these files also
provide LTS ? normally activism fades after a few months. we can see
this will board support and package maintenance. i think this will be a
burden.

adding a "how to build" page to web.git is a good idea and we can
consider to put all the diffconfig files some place. but i think that
source.git is not the right place.

John


> 
> I think I could further improve the buildme.sh to automatically
> pull in the feeds based on the packages in the diffconfig too,
> which should further automate building and make the buildme.sh
> more generic for different platforms.
> 
> For jow's idea, putting it in a web page may be better than nothing,
> but then it just means anyone wanting to use this type of thing
> has more work to do, and for newbies, that can be all the difference
> between success and failure.
> 
> I still think you should consider letting this patch in.  I can
> re-do it based on removing the 1/2 patch, so the diffconfig gets
> bigger, but we can still build usable apu2 images out of the box.
> 
> Either way, thanks for considering the patch.
> 
> Thanks,
> Ben
> 

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] git.openwrt.org site half broken

2016-06-03 Thread John Crispin



On 02/06/2016 13:20, Etienne Champetier wrote:
> Hi,
> 
> someone messed with git.openwrt.org nginx config, i can't get the js and css.
> 
> see https://git.openwrt.org/project/static/gitweb.css (doesn't look
> like a css :) )
> 
> Cheers
> Etienne
> 

that url looks weird.
-> https://git.openwrt.org/static/gitweb.css
works and for me the service seems to be functional.

John


> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH libubox] blobmsg_json: add new functions blobmsg_format_json_value*

2016-06-03 Thread John Crispin



On 01/06/2016 22:27, Matthias Schiffer wrote:
> The current blobmsg_format_json* functions will return invalid JSON when
> the "list" argument is given as false (blobmsg_format_element() will
> output the name of the blob_attr as if the value is printed as part of a
> JSON object).
> 
> To avoid breaking software relying on this behaviour, introduce new
> functions which will never print the blob_attr name and thus always
> produce valid JSON.

what software relies on this function/behaviour ? maybe we should mark
the current implementation as deprected and drop support in time X.
producing broken json syntax seems very fragile.

John

> 
> Signed-off-by: Matthias Schiffer 
> ---
>  blobmsg_json.c | 49 -
>  blobmsg_json.h | 14 ++
>  2 files changed, 50 insertions(+), 13 deletions(-)
> 
> diff --git a/blobmsg_json.c b/blobmsg_json.c
> index 5713948..538c816 100644
> --- a/blobmsg_json.c
> +++ b/blobmsg_json.c
> @@ -207,7 +207,7 @@ static void blobmsg_format_string(struct strbuf *s, const 
> char *str)
>  
>  static void blobmsg_format_json_list(struct strbuf *s, struct blob_attr 
> *attr, int len, bool array);
>  
> -static void blobmsg_format_element(struct strbuf *s, struct blob_attr *attr, 
> bool array, bool head)
> +static void blobmsg_format_element(struct strbuf *s, struct blob_attr *attr, 
> bool without_name, bool head)
>  {
>   const char *data_str;
>   char buf[32];
> @@ -217,7 +217,7 @@ static void blobmsg_format_element(struct strbuf *s, 
> struct blob_attr *attr, boo
>   if (!blobmsg_check_attr(attr, false))
>   return;
>  
> - if (!array && blobmsg_name(attr)[0]) {
> + if (!without_name && blobmsg_name(attr)[0]) {
>   blobmsg_format_string(s, blobmsg_name(attr));
>   blobmsg_puts(s, ": ", s->indent ? 2 : 1);
>   }
> @@ -286,22 +286,26 @@ static void blobmsg_format_json_list(struct strbuf *s, 
> struct blob_attr *attr, i
>   blobmsg_puts(s, (array ? "]" : "}"), 1);
>  }
>  
> +static void setup_strbuf(struct strbuf *s, struct blob_attr *attr, 
> blobmsg_json_format_t cb, void *priv, int indent) {
> + s->len = blob_len(attr);
> + s->buf = malloc(s->len);
> + s->pos = 0;
> + s->custom_format = cb;
> + s->priv = priv;
> + s->indent = false;
> +
> + if (indent >= 0) {
> + s->indent = true;
> + s->indent_level = indent;
> + }
> +}
> +
>  char *blobmsg_format_json_with_cb(struct blob_attr *attr, bool list, 
> blobmsg_json_format_t cb, void *priv, int indent)
>  {
>   struct strbuf s;
>   bool array;
>  
> - s.len = blob_len(attr);
> - s.buf = malloc(s.len);
> - s.pos = 0;
> - s.custom_format = cb;
> - s.priv = priv;
> - s.indent = false;
> -
> - if (indent >= 0) {
> - s.indent = true;
> - s.indent_level = indent;
> - }
> + setup_strbuf(, attr, cb, priv, indent);
>  
>   array = blob_is_extended(attr) &&
>   blobmsg_type(attr) == BLOBMSG_TYPE_ARRAY;
> @@ -321,3 +325,22 @@ char *blobmsg_format_json_with_cb(struct blob_attr 
> *attr, bool list, blobmsg_jso
>  
>   return s.buf;
>  }
> +
> +char *blobmsg_format_json_value_with_cb(struct blob_attr *attr, 
> blobmsg_json_format_t cb, void *priv, int indent)
> +{
> + struct strbuf s;
> +
> + setup_strbuf(, attr, cb, priv, indent);
> +
> + blobmsg_format_element(, attr, true, false);
> +
> + if (!s.len) {
> + free(s.buf);
> + return NULL;
> + }
> +
> + s.buf = realloc(s.buf, s.pos + 1);
> + s.buf[s.pos] = 0;
> +
> + return s.buf;
> +}
> diff --git a/blobmsg_json.h b/blobmsg_json.h
> index cd9ed33..9dfc02d 100644
> --- a/blobmsg_json.h
> +++ b/blobmsg_json.h
> @@ -42,4 +42,18 @@ static inline char *blobmsg_format_json_indent(struct 
> blob_attr *attr, bool list
>   return blobmsg_format_json_with_cb(attr, list, NULL, NULL, indent);
>  }
>  
> +char *blobmsg_format_json_value_with_cb(struct blob_attr *attr,
> + blobmsg_json_format_t cb, void *priv,
> + int indent);
> +
> +static inline char *blobmsg_format_json_value(struct blob_attr *attr)
> +{
> + return blobmsg_format_json_value_with_cb(attr, NULL, NULL, -1);
> +}
> +
> +static inline char *blobmsg_format_json_value_indent(struct blob_attr *attr, 
> int indent)
> +{
> + return blobmsg_format_json_value_with_cb(attr, NULL, NULL, indent);
> +}
> +
>  #endif
> 

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] urandom-seed: add initial implementation

2016-06-03 Thread John Crispin

Hi Etienne,

comment inline ...

On 02/06/2016 23:21, Etienne CHAMPETIER wrote:
> This package:
> 1) seed /dev/urandom with a saved seed as early as possible
> (using /lib/preinit/81_urandom_seed)
> 2) save a new seed using getrandom() so we are sure /dev/urandom
>pool is initialized (using /etc/init.d/urandom_seed)
> 
> seed size is 512 bytes (ie /proc/sys/kernel/random/poolsize / 8)
> it's the same size as in ubuntu 14.04 and all systemd systems
> 
> seed file is /etc/urandom.seed (need a writable path)
> 
> seeding /dev/urandom doesn't change entropy estimation, so we still have
> "random: ubus urandom read with 4 bits of entropy available"
> messages in the logs, but we can now ignore them
> 
> Once tested on enough configuration (jffs2/ext4/ubifs/...)
> this package should be added to DEFAULT_PACKAGES
> 
> We could also add an urandom.seed at build time to improve first boot
> 
> Signed-off-by: Etienne CHAMPETIER 
> ---
>  package/utils/urandom-seed/Makefile| 53 
>  .../urandom-seed/files/81_urandom_seed.preinit | 15 ++
>  package/utils/urandom-seed/files/getrandom.c   | 58 
> ++
>  package/utils/urandom-seed/files/urandom_seed.init | 19 +++
>  4 files changed, 145 insertions(+)
>  create mode 100644 package/utils/urandom-seed/Makefile
>  create mode 100644 package/utils/urandom-seed/files/81_urandom_seed.preinit
>  create mode 100644 package/utils/urandom-seed/files/getrandom.c
>  create mode 100644 package/utils/urandom-seed/files/urandom_seed.init
> 
> diff --git a/package/utils/urandom-seed/Makefile 
> b/package/utils/urandom-seed/Makefile
> new file mode 100644
> index 000..ac58bfc
> --- /dev/null
> +++ b/package/utils/urandom-seed/Makefile
> @@ -0,0 +1,53 @@
> +#
> +# Copyright (C) 2016 Etienne CHAMPETIER 
> +#
> +# This is free software, licensed under the GNU General Public License v2.
> +# See /LICENSE for more information.
> +#
> +
> +include $(TOPDIR)/rules.mk
> +
> +PKG_NAME:=urandom-seed
> +PKG_RELEASE:=1
> +PKG_LICENSE:=GPL-2.0
> +PKG_LICENSE_FILES:=COPYING
> +PKG_BUILD_DIR := $(BUILD_DIR)/$(PKG_NAME)_$(PKG_RELEASE)
> +PKG_FLAGS:=nonshared
> +
> +include $(INCLUDE_DIR)/package.mk
> +
> +define Package/urandom-seed
> +  SECTION:=utils
> +  CATEGORY:=Base system
> +  TITLE:=Seed /dev/urandom on startup
> +  MAINTAINER:=Etienne CHAMPETIER 
> +endef
> +
> +define Package/urandom-seed/description
> +This package takes care of loading a previously saved seed into /dev/urandom,
> +and save a new seed from getrandom()
> +endef
> +
> +define Build/Prepare
> + mkdir -p $(PKG_BUILD_DIR)
> +endef
> +
> +define Build/Configure
> +endef
> +
> +define Build/Compile
> + $(TARGET_CC) $(TARGET_CFLAGS) ./files/getrandom.c -o 
> $(PKG_BUILD_DIR)/getrandom
> +endef
> +
> +define Package/urandom-seed/install
> + $(INSTALL_DIR) $(1)/usr/bin
> + $(INSTALL_BIN) $(PKG_BUILD_DIR)/getrandom $(1)/usr/bin/
> +
> + $(INSTALL_DIR) $(1)/lib/preinit
> + $(INSTALL_DATA) ./files/81_urandom_seed.preinit 
> $(1)/lib/preinit/81_urandom_seed
> +
> + $(INSTALL_DIR) $(1)/etc/init.d
> + $(INSTALL_BIN) ./files/urandom_seed.init $(1)/etc/init.d/urandom_seed
> +endef
> +
> +$(eval $(call BuildPackage,urandom-seed))
> diff --git a/package/utils/urandom-seed/files/81_urandom_seed.preinit 
> b/package/utils/urandom-seed/files/81_urandom_seed.preinit
> new file mode 100644
> index 000..27ff587
> --- /dev/null
> +++ b/package/utils/urandom-seed/files/81_urandom_seed.preinit
> @@ -0,0 +1,15 @@
> +#!/bin/sh
> +
> +do_urandom_seed() {
> +S=/etc/urandom.seed
> +U=/dev/urandom
> +
> +[ -c $U ] || { echo "Something is wrong with $U"; return; }
> +[ -f $S ] || { echo "Seed file not found: $S"; return; }
> +[ -O $S -a -G $S -a ! -x $S ] || { echo "Wrong owner / permissions for 
> $S"; return; }
> +
> +echo "Seeding $U with $S"
> +cat $S > $U
> +}
> +
> +boot_hook_add preinit_main do_urandom_seed
> diff --git a/package/utils/urandom-seed/files/getrandom.c 
> b/package/utils/urandom-seed/files/getrandom.c
> new file mode 100644
> index 000..2093ef8
> --- /dev/null
> +++ b/package/utils/urandom-seed/files/getrandom.c
> @@ -0,0 +1,58 @@
> +/*
> + * Copyright (C) 2016 Etienne Champetier 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +#define _GNU_SOURCE
> +#include 
> +#include 
> +#include 
>

Re: [LEDE-DEV] [PATCH] fix uClibc-ng scanf check

2016-06-03 Thread John Crispin

Hi Waldemar

On 03/06/2016 04:23, Waldemar Brodkorb wrote:
> uClibc-ng tries to be compatible with GNU libc and defines
> __GLIBC__ and pretend to be version 2.2.
> We once changed it to 2.10, but then some hard to fix problems
> in different software packages (gcc) occured.
> It would be better if we disable the special GNU libc checks
> for uClibc-ng here. uClibc-ng implements the required scanf
> functionality.
> 
> Signed-off-by: Waldemar Brodkorb 
> ---
>  configure.ac | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/configure.ac b/configure.ac
> index f36b18c..4661c0d 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -581,7 +581,7 @@ AC_CACHE_VAL([scanf_cv_alloc_modifier],
>   #include 
>   #include 
>  
> - #ifdef __GLIBC__
> + #if defined(__GLIBC__) && !defined(__UCLIBC__)
>  
>   #if !(__GLIBC_PREREQ(2, 7))
>   #error %m is not available
> 


this is the raw patch. please send a patch that adds this patch at the
right place inside the tree.

John

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] ar71xx kernel size starts getting oversized

Re: [LEDE-DEV] mmc driver for openwrt on fonera 2100

Re: [LEDE-DEV] Meeting on TR-069 Work - Friday, June 10 - 7 AM PT

[LEDE-DEV] Meeting on TR-069 Work - Friday, June 10 - 7 AM PT

Re: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.

Re: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.

Re: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.

Re: [LEDE-DEV] [PATCH] fix uClibc-ng scanf check

Re: [LEDE-DEV] international keyboard layout support

Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH libubox] blobmsg_json: add new functions blobmsg_format_json_value*

Re: [LEDE-DEV] international keyboard layout support

Re: [LEDE-DEV] [PATCH] package/devel/gdb: Add support of ARC gdb

Re: [LEDE-DEV] mmc driver for openwrt on fonera 2100

Re: [LEDE-DEV] mmc driver for openwrt on fonera 2100

Re: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.

Re: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.

Re: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.

Re: [LEDE-DEV] [PATCH 1/3] [ubox] remove unnecessary size struct between messages

Re: [LEDE-DEV] [PATCH] urandom-seed: add initial implementation

Re: [LEDE-DEV] [PATCH] urandom-seed: add initial implementation

[LEDE-DEV] [PATCH 1/3] [ubox] remove unnecessary size struct between messages

[LEDE-DEV] [PATCH 3/3] [ubox] logd: add ubus reload method

[LEDE-DEV] [PATCH 2/3] [ubox] syslog: change log buffer size

Re: [LEDE-DEV] [PATCHv3 1/1] [brcm63xx] Add initial support for EVG2000

Re: [LEDE-DEV] [PATCH libubox] blobmsg_json: add new functions blobmsg_format_json_value*

Re: [LEDE-DEV] [PATCHv3 1/1] [brcm63xx] Add initial support for EVG2000

Re: [LEDE-DEV] [PATCH] fix uClibc-ng scanf check

Re: [LEDE-DEV] git.openwrt.org site half broken

Re: [LEDE-DEV] [PATCHv4 1/1] [brcm63xx] Fix the logged CPU variant

Re: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.

Re: [LEDE-DEV] git.openwrt.org site half broken

Re: [LEDE-DEV] [PATCH libubox] blobmsg_json: add new functions blobmsg_format_json_value*

Re: [LEDE-DEV] [PATCH] urandom-seed: add initial implementation

Re: [LEDE-DEV] [PATCH] fix uClibc-ng scanf check

34 matches

Site Navigation

Mail list logo

Footer information