[LEDE-DEV] [PATCH] lantiq: Shortcut non-pppoa interfaces in dsl_notify

[Oswald Buddenhagen]

No need to query 'up' and 'auto' when they are not going to be used.

Signed-off-by: Oswald Buddenhagen <oswald.buddenha...@gmx.de>
---
 target/linux/lantiq/base-files/sbin/dsl_notify.sh | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/target/linux/lantiq/base-files/sbin/dsl_notify.sh 
b/target/linux/lantiq/base-files/sbin/dsl_notify.sh
index ba197f1..11ada92 100755
--- a/target/linux/lantiq/base-files/sbin/dsl_notify.sh
+++ b/target/linux/lantiq/base-files/sbin/dsl_notify.sh
@@ -31,22 +31,24 @@ interfaces=`ubus list network.interface.\* | cut -d"." -f3`
 for ifc in $interfaces; do
 
json_load "$(ifstatus $ifc)"
-   json_get_var up up
-
-   config_get_bool auto "$ifc" auto 1
 
json_get_var proto proto
+   if [ "$proto" != "pppoa" ]; then
+   continue
+   fi
 
+   json_get_var up up
+   config_get_bool auto "$ifc" auto 1
if [ "$DSL_INTERFACE_STATUS" = "UP" ]; then
-   if [ "$proto" = "pppoa" ] && [ "$up" != 1 ] && [ "$auto" = 1 ]; 
then
+   if [ "$up" != 1 ] && [ "$auto" = 1 ]; then
( sleep 1; ifup "$ifc" ) &
fi
else
-   if [ "$proto" = "pppoa" ] && [ "$up" = 1 ] && [ "$auto" = 1 ]; 
then
+   if [ "$up" = 1 ] && [ "$auto" = 1 ]; then
( sleep 1; ifdown "$ifc" ) &
else
json_get_var autostart autostart
-   if [ "$proto" = "pppoa" ] && [ "$up" != 1 ] && [ 
"$autostart" = 1 ]; then
+   if [ "$up" != 1 ] && [ "$autostart" = 1 ]; then
( sleep 1; ifdown "$ifc" ) &
fi
fi
-- 
2.8.3.1.g1cc7b6a


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

Re: [LEDE-DEV] externalizing package management?

[Oswald Buddenhagen]

On Wed, Jan 11, 2017 at 11:00:04AM +0100, Jo-Philipp Wich wrote:
> > in my understanding, sysupgrade images (and uimages) are a pretty
> > uniform archive format,
> 
> Actually they're not. There are factory and sysupgrade images which are
> renamed tars, there are trx images, there are FIT images, proprietary
> vendor formats, images containing images and whole lot of other types.
> 
well, that complicates things a bit.
but somehow sysupgrade itself is able to deal with them. so the
worst-case appears to be that the image wouldn't be re-packed, and thus
end up bigger than if it would be actually created from scratch. that's
not worse than if the packages are installed manually.
or am i missing some relevant detail again?

> > a single generic tool should be able to work with all targets, over
> > extended periods of time, and would need to support a rather limited
> > number of features to accomplish the goal of building images from the
> > "regular" image+package downloads that are already available.
> 
> The only real solution is something GNU make based in order to be able
> to re-use the image format knowledge encoded in the per target
> Makefiles. Anything else requires duplication of the image build logic
> which can, and will, quickly diverge from whats in Master.
> 
actually, not the only solution: it's also possible to use a yet
higher-level description, and generate makefile fragments from that.
if this was abstract enough, it could be used as a recipe for unpacking
the images as well, without specifying it separately. obviously, the
backends would need to duplicate the available transforms, but the
amount of work required doesn't seem _extraordinary_ if the goal is
deemed worthwhile.

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

Re: [LEDE-DEV] how to make sysupgrade not drop user-installed packages

[Oswald Buddenhagen]

On Wed, Jan 11, 2017 at 10:54:10AM +0100, Jo-Philipp Wich wrote:
> > there doesn't appear to be anything hard about having the build bots
> > include a file into /etc which contains the _current_ repository
> > url, subdirectory, and image name.
> 
> you forget that up until very recently the same kernel and rootfs was
> used for many different images only varying in filename, image header
> and kernel command line.
>
well, i didn't forget it, i never knew it. ;)

> The squashfs was not repacked for each individual device image, which
> made it impossible to add an individual file into /etc/ for each
> device specific image.
> 
even that wouldn't have been an obstacle, as the image name could be
passed on the command line as well.

not that this would be relevant at this time. my point is simply that
embedding the required meta-data isn't the hard part.

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

Re: [LEDE-DEV] externalizing package management?

[Oswald Buddenhagen]

On Sun, Jan 08, 2017 at 08:42:25PM +0100, Jo-Philipp Wich wrote:
> the imagebuilder should support all that already and it likely fills the
> "powerful desktop tools" part your concept requires.
> 
i answered that in my other mail already.

anyway, specifically regarding the existing imagebuilder, i'm not really
satisfied. it's a big download which is specific to each target, and
requires pretty much a complete build environment. of course, it's the
obvious choice to minimize development effort, but as a user i'd expect
something ... nicer.

in my understanding, sysupgrade images (and uimages) are a pretty
uniform archive format, just like the feed packages are. that means that
a single generic tool should be able to work with all targets, over
extended periods of time, and would need to support a rather limited
number of features to accomplish the goal of building images from the
"regular" image+package downloads that are already available.

> Given the recent advances with Linux support on Windows 10 plus Docker
> etc. it shouldn't be too hard to bundle an ImageBuilder with some
> Desktop ui and an RPC client to remote-control the router via SSH or
> HTTPS-UBUS-RPC.
> 
that's way too new-fangled for my taste. :D
a simple desktop application (built with the cross-platform toolkit of
the developer's choice) would do just fine. all the steps that deal with
the archives can be handled in-process by linked libraries (most of the
code is already librarized). offer three pre-built binaries for the
major desktops. "regular" linux distros would package it for you as well.

of course, over time the scope of that application could be extended
into a generic openwrt installer which can actually flash uboot and
everything on top. that would actually provide significant added value
over the purely on-device update mechanism proposed in the other thread,
and could potentially significantly increase the user base of openwrt.

a different aspect would be developing it into a complete desktop-based
"luci" (basically an extended version of the initial idea of this
thread), but that seems kinda unreasonable to me.

> Do you plan to work on something like that?
> 
given current realities of the size of my todo list and available spare
time, the best i can hope for is to inspire Someone Else (TM) to pick up
some of my ideas ...

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

Re: [LEDE-DEV] how to make sysupgrade not drop user-installed packages

[Oswald Buddenhagen]

On Sun, Jan 08, 2017 at 08:38:04PM +0100, Jo-Philipp Wich wrote:
> Right now it cannot be provided unless we provide suitable meta data for
> that on the server side or - preferably - inside the image itself.
> 
i actually had that typed out already, but deleted it because it seems
like a complete no-brainer to me. there doesn't appear to be anything
hard about having the build bots include a file into /etc which contains
the _current_ repository url, subdirectory, and image name.

whenever the de-facto policy changes in an ordered way, there should be
a transition phase where the images are available at both locations, but
already point to the new one.

and when the download fails because the policy changes unexpectedly (or
the user neglected to trigger the process for too long), the interactive
variant of the tool can just ask for the information it found outdated.
even in this worst case, that system is still *a lot* more convenient
(and thus less likely to contribute to unpatched CPEs) than what exists
now.

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

Re: [LEDE-DEV] externalizing package management?

[Oswald Buddenhagen]

On Sun, Jan 08, 2017 at 02:16:55PM +0100, Stefan Lippers-Hollmann wrote:
> Using imagebuilder (and keeping the existing configs, which is the 
> default for sysupgrade) seems to tick all of your boxes, doesn't it?
> 
not quite. obviously, wrapping the image builder into a script solves
the upgrade problem i started out with, and is in fact functionally
equivalent with the browser-based proposal i made (except that it
requires expertize most "regular" users won't have).
however, this thread is concerned with _interactive_ use. the idea is to
make management of the device as comfortable as of a desktop system. the
question how changes are committed to the device is of secondary concern
from a user perspective.

On Sun, Jan 08, 2017 at 02:39:05PM +0100, Stefan Lippers-Hollmann wrote:
> On the other end of the spectrum, high-end (mostly armhf based) devices
> are starting to roll up the market with flash in the multiple hundreds
> or even gigabyte regions[1], finally making full in-place upgrades and 
> on-device package management an option (only limited by opkg's abilities 
> and the in-place upgrade/ downgrade paths provided by the current 
> packaging practices (maintainer scripts, library versioning, etc.), so 
> for these you might even want/ need a(n even) more universal package 
> manager on the devices themselves).
> 
packaging practices aren't a concern here. typically, an upgrade would
start out with creating a new volume inside a CoW file system, doing all
modifications inside it, and later switching to it atomically.
the limiting factor here is the boot loader, as with the above model,
the kernel needs to be within that file system if it's supposed to be
covered as well. a less ambitious approach is deploying the kernel to
separate ubi volumes, which is what is actually already being done by
some devices.

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

[LEDE-DEV] externalizing package management?

[Oswald Buddenhagen]

moin,

openwrt aims to be a "proper" linux distribution, and therefore comes
with on-device package management.

but we know that to be a problem for the more space-constrained devices.
also, the space constraints make the package manager pretty dumb by
modern standards. both issues have been raised in recent threads.

so how about optionally externalizing (package) management?

a typical admin session would look like this:
- select target device
- sync with device
  - to connect with pre-existing devices.
  - to still support direct on-device modifications, though it's
conceivable to build images which don't provide the tools for that.
  - to support multiple management machines, even if realistically
speaking most devices are administered from a single desktop/laptop
anyway.
- do modifications with powerful desktop tools
- sync back to device
  - individual files
  - or create and flash image
- tell device to reboot, or at least (re-)load some services (the latter
  is obviously a lot more work to implement)

the syncing itself should be probably just done via ssh (mostly fish, as
known from midnight commander), as it also offers the option to invoke
sysupgrade, reboot, and to start/reload services without using an
additional protocol.

with this concept, it would be also possible to integrate the
kernel/rootfs into the package management, which would improve
usability. and obviously, it would nicely solve the system upgrade
problem, which is how i arrived here in the first place.

thoughts?

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

Re: [LEDE-DEV] how to make sysupgrade not drop user-installed packages

[Oswald Buddenhagen]

On Sat, Jan 07, 2017 at 11:31:01PM +0100, Magnus Kroken wrote:
> On 07.01.2017 19.04, Oswald Buddenhagen wrote:
> > the idea would be to simply dump the list of user-installed packages into
> > a config file which is preserved by sysupgrade. now, firstboot would see
> > that file and start opgk with it - that's usually going to just work, as
> > the network configuration is preserved as well.
> 
> 1. This relies on all packages and kernel modules needed to connect to 
> the internet being part of the image.
>
this is true, but not a deal breaker. the fact that not all users would
benefit from the feature doesn't mean that it shouldn't be provided. the
implementation is certainly cheap enough.

> 2. If you do build a custom image without all your packages, packages 
> you download from LEDE servers may be incompatible for various reasons - 
> kernel version, library versions, compile-time defined options and so on.
> 
it seems rather obvious to me that the feature's configuration would be
customized with the image itself.

> the default packages should be limited to what is useful and necessary
> to almost everyone - otherwise everyone would have lots of useless
> packages in their image that take up valuable space
>
that's correct, though i'd be surprised if supporting all reasonably
common _basic_ network access technologies would require more than a few
tens of kilobytes.

> (and devices with 4MB flash would be unsupported).
> 
well, you're losing that fight anyway.

> > of course, this immediately prompts the next question: why doesn't
> > luci's flash operations page have an auto-download option for the
> > sysupgrade image? the locations of the package feeds are also inside
> > the image, and automating the integrity check isn't rocket science,
> > either.
> 
> There have been recent discussions about a web interface to the image
> builder, based on or similar to Meshkit by Freifunk [1].

> LuCI/sysupgrade could add a feature to connect to this service, submit
> a list of installed packages and other needed information, and
> automatically download an image built with these packages.
> 
that's an interesting concept, but i don't think it scales. i'd limit it
to a pre-defined set of network configurations (which could be
referenced from an ISP table). packages beyond network access should be
still obtained separately. that makes it somewhat realistic to cache the
images and distribute them to multiple users.


anyway, there are more options besides downloading pre-built complete
images (which inherently requires lots of server infrastructure) and
amending the installation after the upgrade (which inherently has a
bootstrap problem if the image lacks required features):

- let the upgrade process download the required packages and append
  their unpacked contents to the freshly flashed image *before* reboot.
  that's what sysupgrade does to preserve the config files anyway.

- modern browsers actually provide pretty much a complete operating
  system environment. that means that it would be feasible to do the
  image building (from downloaded images and packages) within the client
  browser, and upload a complete image to the device for flashing.
  obviously, this comes with some caveats:
  - you can't do unattended upgrades this way. i guess many openwrt
users would prefer it that way, but having the option to fully
automate it (and even default to it within stable series) seems
desirable.
  - i guess most openwrt developers aren't sufficiently familiar with
these technologies to pull this off in reasonable time and to
maintain it.


and now i had yet another idea, which would solve the upgrade problem
for me nicely ... i'll start another thread.

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

[LEDE-DEV] how to make sysupgrade not drop user-installed packages

[Oswald Buddenhagen]

moin,

i'm wondering what could be done about the nuisance that after a
sysupgrade one needs to manually re-install the user-installed packages.
the documented process is pretty much algorithmic, so it seems like a
shame that it's not (mostly) automated.

the idea would be to simply dump the list of user-installed packages into
a config file which is preserved by sysupgrade. now, firstboot would see
that file and start opgk with it - that's usually going to just work, as
the network configuration is preserved as well. on top of that, luci
could offer a button in the software manager to manually trigger the
process in case the fully automated restoration didn't work out.

scripts for doing just that have been posted years ago, so i'm wondering
why such a mechanism wasn't integrated upstream. am i missing something,
or did just nobody think it important enough to do?


of course, this immediately prompts the next question: why doesn't
luci's flash operations page have an auto-download option for the
sysupgrade image? the locations of the package feeds are also inside the
image, and automating the integrity check isn't rocket science, either.

of course, it sort of makes sense to have a copy of the last working
sysupgrade image outside the router, and that's basically a side effect
of the manual process (unless one is dumb enough to delete/overwrite the
previous image). however, the option to download a sysupgrade image for
the running system could be provided as another backup option -
extracting/recreating it from the flash shouldn't be that hard, i guess?

thoughts?

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

Re: [LEDE-DEV] [PATCH 6/6] lantiq: use ath9k device tree bindings binding/owl-loader

[Oswald Buddenhagen]

On Wed, Nov 23, 2016 at 07:36:33AM +0100, Bastian Bittorf wrote:
> * Martin Blumenstingl  [23.11.2016 07:22]:
> > +   case $board in
> 
> better: "$board"
> 
no, not better. the case discriminator is not word-split (and quoting
even breaks on some ancient shell).

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

Re: [LEDE-DEV] [PATCH v2] uboot-envtools: remove function vals and fix indentation

[Oswald Buddenhagen]

this commit message is cryptic; i had to read the patch to understand
what you mean. there seems to be a pattern. ;)

also, technically speaking, you're not _fixing_ the indentation, as it
was canonical. you're using a less known shell feature to _improve_ it.
(fwiw, i dislike that the syntax _requires_ tabs. that's ok in this
script, as it uses tabs anyway, but it's limiting.)


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

Re: [LEDE-DEV] Call defines for minifying scripting languages

[Oswald Buddenhagen]

On Mon, Oct 03, 2016 at 01:00:19PM +0200, Jan-Tarek Butt wrote:
> My Idea ist to create calldefs to minify all scriptes there are 
> interpreted by run time.
> 
> 1. Reducing memory size on firmware images.
>
this is absolutely negligible. as others already pointed out, scripts
compress quite well. also, they are actually only a rather small
fraction of the image's total size.

> 2. Strip out all comments (which makes us able to do better code
> commenting)
>
you mean, we can make the scripts *yet bigger* because it won't
negatively affect the image's size. except that point 1, so this isn't
actually a limiting factor. writing said comments and keeping them
up-to-date is the problem.

> 3. and so on.
> 
i think mostly "whatever". ;)

i'll also pre-emptively point out that minification has a rather
insignificant impact on run time - the only thing that is slowed down is
the tokenization/parsing, and that is again rather insiginificant
compared to everything else executing a script involves.

but hey, make some actual measurements - maybe you'll surprise me.


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

Re: [LEDE-DEV] Speedport W504V | ARV8539PW22 - gets very hot !

[Oswald Buddenhagen]

On Sat, Oct 01, 2016 at 12:49:49PM +0200, Dennis Schneck wrote:
> I have a Speedport W504V | ARV8539PW22, but i gets very hot (without
> doing anything, only power on some minutes).
>
define "very hot".
the box has a power consumption of around 5w when the dsl connection is
down, and goes up to almost 10w when it comes up. this produces a rather
significant amount of heat.

i find this actually quite disappointing.
the o2 box 4421 consumes around 7w with dsl on. it's based on the same
soc (danube), so it's probably better because it contains way less
auxiliary hardware.
the old speedport w701v based on the ar7 soc consumes around 6w despite
having roughly the same auxiliary hardware as the w504v. the lower max
bitrate (16mbit/s vs. 26mbit/s) is certainly the key here.
and vdsl2 modems typically consume something in the range of 15w. the
other end probably has a comparable consumption, so a single subscriber
weights in with ~30w non-stop power consumption (let's face it, most
people never turn off their modems). this makes the faster dsl variants
an ecologically rather questionable technology ...

fwiw, if anyone has ideas for tuning options how to limit power
consumption, i'm all ears. my connection is artificially limited to
~7mbit/s raw dsl bandwidth anyway.

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

Re: [LEDE-DEV] [patch master 15/15] read without -r will mangle backslashes

[Oswald Buddenhagen]

re subject: many of your commit message summaries don't comply with the
imperative style generally expected.

in the descriptions, you should mention what "terrible" things the patches
prevent in practice, including when the answer is "nothing" and thus the
change is just a clarification.


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

Re: [LEDE-DEV] [patch master 14/15] Expressions don't expand in single quotes, use double quotes for that

[Oswald Buddenhagen]

On Sat, Oct 01, 2016 at 12:49:23AM +0200, Lars Kruse wrote:
> I think, this is just a change based on style preferences, or?
> Using single quotes specifically for situation where expansion is not intended
> feels quite explicite and clear to me - thus personally I would prefer to 
> stick
> with single quotes instead of double quotes combined with escaping.
>
+1

> Or did I miss the point of your change?
> 
> Cheers,
> Lars
> 

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

Re: [LEDE-DEV] [patch master 13/15] To read lines rather than words, pipe/redirect to a 'while read' loop

[Oswald Buddenhagen]

On Sat, Oct 01, 2016 at 12:44:36AM +0200, Lars Kruse wrote:
> Am Fri, 30 Sep 2016 22:02:27 +0200 schrieb Jan-Tarek Butt :
> 
> > ---
> >  scripts/deptest.sh | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/scripts/deptest.sh b/scripts/deptest.sh
> > index 8c859ef..0b0e7a9 100755
> > --- a/scripts/deptest.sh
> > +++ b/scripts/deptest.sh
> > @@ -86,9 +86,9 @@ test_package() # $1=pkgname
> > [ -n "$pkg" -a -z "$(echo "$pkg" | grep -e '/')" -a "$pkg" != "." -a 
> > "$pkg" != ".." ] || \ die "Package name \"$pkg\" contains illegal 
> > characters"
> > local SELECTED=
> > -   for conf in $(grep CONFIG_PACKAGE tmp/.packagedeps | grep -E "[ 
> > /]$pkg\$" | sed -e 's,package-$(\(CONFIG_PACKAGE_.*\)).*,\1,'); do
> > +   while IFS= read -r conf; do
> > grep "$conf=" .config > /dev/null && SELECTED=1 && break
> > -   done
> > +   done < "$(grep CONFIG_PACKAGE tmp/.packagedeps | grep -E "[ /]$pkg\$" | 
> > sed -e 's,package-$(\(CONFIG_PACKAGE_.*\)).*,\1,')"
> 
> Is this really doing what it looks like?
>   ... < "$(command)"
> This should try to read from a file named like the output of "command" - and
> not the lines of command's output.
> 
> I guess, the following approach should do the right thing:
> 
>   grep CONFIG_PACKAGE tmp/.packagedeps | grep -E > "[ /]$pkg\$" | sed -e 
> 's,package-$(\(CONFIG_PACKAGE_.*\)).*,\1,') | while IFS= read -r conf; do
> ...
>   done
> 
this won't work, because it makes the loop body a subshell, and thus the
assignment of SELECTED will get lost.

to achieve the goal with minimal effort, adding

  local IFS=$'\n'

prior to the loop should be sufficient.

ps: please configure your mailer to not wrap quotes.

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

Re: [LEDE-DEV] [patch master 12/15] use * instead of @ to concatenate

[Oswald Buddenhagen]

On Sat, Oct 01, 2016 at 12:37:24AM +0200, Lars Kruse wrote:
> Am Fri, 30 Sep 2016 22:02:26 +0200 schrieb Jan-Tarek Butt :
> 
> > -   cc="$@"
> > +   cc="$*"
> 
> as far as I understand $* and $@, there should be no difference in this
> context, or?
> 
which is exactly the reason to do it: to not suggest it could do more.

btw, the quotes around the assignment are superfluous, by language
definition.

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

Re: [LEDE-DEV] [patch master 08/15] Use $(..) instead of legacy `..`

[Oswald Buddenhagen]

On Fri, Sep 30, 2016 at 10:02:22PM +0200, Jan-Tarek Butt wrote:
> diff --git a/scripts/deptest.sh b/scripts/deptest.sh
> - for pkg in `cat tmp/.packagedeps  | grep CONFIG_PACKAGE | grep -v 
> curdir | sed -e 's,.*[/=]\s*,,' | sort -u`; do
> + for pkg in $(cat tmp/.packagedeps  | grep CONFIG_PACKAGE | grep -v 
> curdir | sed -e 's,.*[/=]\s*,,' | sort -u); do
>
you should remove the excess space while you're at it.

> diff --git a/scripts/mkits.sh b/scripts/mkits.sh
> - echo "Usage: `basename "$0"` -A arch -C comp -a addr -e entry" \
> +  echo "Usage: $(basename "$0") -A arch -C comp -a addr -e entry" \
>   "-v version -k kernel [-D name -d dtb] -o its_file"
>   echo -e "\t-A ==> set architecture to 'arch'"
>
indentation botch.


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

Re: [LEDE-DEV] [patch master 05/15] Use cd ... || exit in case cd fails

[Oswald Buddenhagen]

On Sat, Oct 01, 2016 at 12:05:16AM +0200, Lars Kruse wrote:
> Am Fri, 30 Sep 2016 22:02:19 +0200 schrieb Jan-Tarek Butt :
> > -   libdirs="$libdirs $(cd "$libdir"; pwd)/"
> > +   libdirs="$libdirs $(cd "$libdir" || exit;
> > pwd)/" fi
> 
> I am not sure, if this script is supposed to break on every missing libdir (I
> do not know the context). Thus maybe " && " would be better instead ";"?
>
note that all cases in this patch (except those i pointed out in the
other mail) are commands within $() or (), i.e., subshells. thus, the
exit calls all only exit that respective scope.
and it's true that in most cases using '&&' instead of '|| exit;' would
be more elegant.

another implication of that is that complete error handling would imply
a lot more "visual noise". e.g.:

libdirs="$libdirs $(cd "$libdir" && pwd)/" || exit

(this assumes that the exit code of the nested command persists through
the assignment, which it is supposed to do).


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

Re: [LEDE-DEV] [patch master 05/15] Use cd ... || exit in case cd fails

[Oswald Buddenhagen]

On Fri, Sep 30, 2016 at 10:02:19PM +0200, Jan-Tarek Butt wrote:
> diff --git a/scripts/get_source_date_epoch.sh 
> b/scripts/get_source_date_epoch.sh
> -[ -n "$TOPDIR" ] && cd "$TOPDIR"
> +[ -n "$TOPDIR" ] && cd "$TOPDIR" || exit
> diff --git a/scripts/getver.sh b/scripts/getver.sh
> -[ -n "$TOPDIR" ] && cd "$TOPDIR"
> +[ -n "$TOPDIR" ] && cd "$TOPDIR" || exit
>  
these two are plain broken, as the script would just exit if TOPDIR is
empty. you need to use braces.


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

Re: [LEDE-DEV] [patch master 01/15] Double quote to prevent globbing and word splitting

[Oswald Buddenhagen]

On Fri, Sep 30, 2016 at 11:50:09PM +0200, Lars Kruse wrote:
> Am Fri, 30 Sep 2016 22:02:15 +0200 schrieb Jan-Tarek Butt :
> > -   for pattern in $(eval echo $spec); do
> > -   find $libdirs -name "$pattern.so*" | sort -u
> > +   for pattern in $(eval echo "$spec"); do
> > +   find "$libdirs" -name "$pattern.so*" | sort -u
> 
> Just out of curiosity: do you know, what could be the purpose of the "eval"
> construct above?
> I would assume that:
>  for pattern in $spec; do
> behaves exactly like:
>  for pattern in $(eval echo $spec); do
> 
nope. $spec may contain brace expansions, which would not be processed
without the eval. (note that regular file globs *are* processed even
without it).

whether quotes are added here or not doesn't matter at all, because
eval sees all arguments as a single string anyway - if you wanted to
quote/escape anything, the string itself would have to contain the
quotes/backslashes. so if it's about good style, this should be written
as eval "echo $spec".

fwiw, i also used $(eval echo $foo) for whitespace normalization before.
ugly, but short and effective.


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

Re: [LEDE-DEV] [RFC] lantiq: fix ath5k EEPROM loading

[Oswald Buddenhagen]

On Tue, Aug 23, 2016 at 09:14:36PM +0200, Mathias Kresin wrote:
> With 12fe4b579801ea812b64fc7e689716cd39c895ec I switched the ath5k
> eeprom extraction to an alternate code path. Unfortunately this code
> seams to be broken since ages and broke the ath5k EEPROM extraction.
> 
i have no particular opinion about this patch itself, but it reminds me
of something i stumbled over in my meanders into wifi driver land:
the fact that the platform driver hooks are there at all, and eeprom
content *files* are used is, ehm, suboptimal. a much more elegant
solution would be using the memory directly, and configuring it via a
proper pci device:

diff --git a/target/linux/lantiq/dts/ARV7506PW11.dts 
b/target/linux/lantiq/dts/ARV7506PW11.dts
index 1c38c88..61f726a 100644
--- a/target/linux/lantiq/dts/ARV7506PW11.dts
+++ b/target/linux/lantiq/dts/ARV7506PW11.dts
@@ -61,7 +61,7 @@
reg = <0x44 0x3B>;
};

-   partition@7f {
+   board_config: partition@7f {
label = "board_config";
reg = <0x7f 0x1>;
read-only;
@@ -143,6 +143,11 @@
pci@E105400 {
status = "okay";
gpio-reset = < 21 0>;
+
+   wmac@e,0 {
+   reg = <0x7000 0 0 0 0>;
+   ralink,mtd-eeprom = <_config 0x410>;
+   };
};

};
===

the interesting thing is that all the necessary bits and pieces for that
are *in principle* already there, except for two catches:
- according to my reading of the implementation, the ralink,mtd-eeprom
  node wouldn't be actually read without a fake ralink,eeprom one, or
  something like that. that's just a matter of correctly re-nesting the
  code paths.
  - i had only a very cursory look over the ath*k drivers, but it
appears that they work mostly the same way in this regard.
- the "somewhat" bigger problem is that there is no pci device tree
  support for mips in the first place - as of 4.4, it's implemented only
  for powerpc and sparc. but there doesn't appear to be a real reason
  for that other than "nobody's done it", as the device tree code is in
  principle just as generic as pci itself.

any takers? :D

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