Re: [OpenWrt-Devel] [RFC] Pre-seeded files/directories for UBIFS

[Ralph Sennhauser]

Hi Richard

On Sun, 21 May 2017 10:40:05 +0200
Richard Weinberger <rich...@nod.at> wrote:

> Geert,
> 
> Am 21.05.2017 um 10:37 schrieb Geert Uytterhoeven:
> > On Sat, May 20, 2017 at 9:36 PM, Ralph Sennhauser
> > <ralph.sennhau...@gmail.com> wrote:  
> >> There is also the size consideration. Unless a seeded ubifs can get
> >> close to squashfs in terms of compression there would still be a
> >> use-case for squashfs with an ubifs overlay. My current root as
> >> ubifs instead of squashfs is 76.8% bigger.  
> > 
> > As seeded files are stored and kept unmodified, they could be
> > stored in compressed form?  
> 
> This is what UBIFS already does.

Right, or it would be some 400-500% difference.

Another advantage of the squashfs with overlay came to mind. OpenWrt
doesn't do a factory reset per se but boots into a "failsafe" mode which
just doesn't mount the overlay. This allows to fix the overlay (some
screwed up config value which prevents connection) or to reset the
password for example without having to reinstall packages and
reconfigure the device from ground up. Wiping the overlay is basically
the last resort.

With the expectation distributions to use the same approach for as many
devices possible I see the seeded ubifs running out of users fast. Some
commercial vendor backporting it to a 3.10 kernel maybe?

If the seeded ubifs could be generalized to snapshot support ala btrfs
that would change things a lot as it would enable uses far beyond just
factory reset. No idea how feasible that is but might be worth
considering instead.

Ralph

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

Re: [OpenWrt-Devel] [RFC] Pre-seeded files/directories for UBIFS

[Ralph Sennhauser]

Hi Richard,

On Sat, 20 May 2017 21:57:36 +0200
Richard Weinberger <rich...@nod.at> wrote:

> Ralph,
> 
> Am 20.05.2017 um 21:36 schrieb Ralph Sennhauser:
> >>> These days I had an interesting discussion with Christoph about
> >>> overlayfs and its burden. The main use-case of overlayfs in
> >>> combination with UBIFS is having a squashfs as lower and UBIFS as
> >>> upper directory. Such that all changes to the read-only squashfs
> >>> go into UBIFS. Upon a factory reset all files within the UBIFS
> >>> will be removed  and the merged directory is clean again.
> >>> Christoph argued that such a functionality  could be achieved
> >>> without overlayfs if the filesystem supported something like
> >>> pre-seeded  files or directories. This would lower memory
> >>> pressure and complexity.
> >>
> >> As you may know, OpenWrt/LEDE have been using this scheme for many
> >> years now (before it was named overlayfs, this was called mini
> >> fanout overlay ~10 yrs ago) with squashfs + jffs2 before on P-NOR
> >> flashes. There are still devices like those that benefit from
> >> squashfs(ro)+jffs2(rw), so while bringing a similar functionality
> >> using UBIFS exclusively would be interesting, it would still make
> >> Linux distribution want to support a more generic scheme which is
> >> using overlayfs as well.
> >>  
> > 
> > There is also the size consideration. Unless a seeded ubifs can get
> > close to squashfs in terms of compression there would still be a
> > use-case for squashfs with an ubifs overlay. My current root as
> > ubifs instead of squashfs is 76.8% bigger.  
> 
> You seem to misunderstand this feature, the goal is not to void all
> uses of squashfs.
> I'm pretty sure for the LEDE usecase squashfs is the better choice.

Probably depends on the device but is beyond the point. Just wanted to
mention in response to the main point being the factory reset of the
squashfs + ubifs overlay setup that size is just as important or even
more important at least for some.

Whether you want to implement and maintain another solution to the
factory reset problem in ubifs which falls short of full snapshot
support is up to you.

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

Re: [OpenWrt-Devel] [RFC] Pre-seeded files/directories for UBIFS

[Ralph Sennhauser]

On Sat, 20 May 2017 11:39:33 -0700
Florian Fainelli  wrote:

> Hello,
> 
> On 05/20/2017 09:12 AM, Richard Weinberger wrote:
> > Hi!
> > 
> > These days I had an interesting discussion with Christoph about
> > overlayfs and its burden. The main use-case of overlayfs in
> > combination with UBIFS is having a squashfs as lower and UBIFS as
> > upper directory. Such that all changes to the read-only squashfs go
> > into UBIFS. Upon a factory reset all files within the UBIFS will be
> > removed  and the merged directory is clean again. Christoph argued
> > that such a functionality  could be achieved without overlayfs if
> > the filesystem supported something like pre-seeded  files or
> > directories. This would lower memory pressure and complexity.  
> 
> As you may know, OpenWrt/LEDE have been using this scheme for many
> years now (before it was named overlayfs, this was called mini fanout
> overlay ~10 yrs ago) with squashfs + jffs2 before on P-NOR flashes.
> There are still devices like those that benefit from
> squashfs(ro)+jffs2(rw), so while bringing a similar functionality
> using UBIFS exclusively would be interesting, it would still make
> Linux distribution want to support a more generic scheme which is
> using overlayfs as well.
> 

There is also the size consideration. Unless a seeded ubifs can get
close to squashfs in terms of compression there would still be a
use-case for squashfs with an ubifs overlay. My current root as ubifs
instead of squashfs is 76.8% bigger.

> > 
> > Today I had a thought about this and I'm pretty sure we can
> > implement this in UBIFS with not too much effort. The basic idea is
> > marking files or whole directories as seed upon mkfs.ubifs time.
> > If these files will be changed at run-time, the original contents
> > will stay on the medium and at any time these files can be reverted
> > back to their seed state. This includes file contents, attributes
> > and extended attributes. I can think of an UBIFS specific IOCTL to
> > put files into seed state and to revert them again.
> > 
> > Since UBIFS is already a pure copy-on-write filesystem, all we have
> > to do is teaching the index tree about seeds. We could add a flag
> > to the UBIFS key which indicates that the node behind this key is
> > seeded. i.e. file "foo" is seeded and the corresponding inode
> > number is 0x1234, then every key of every UBIFS node that belongs
> > to that file will wear the new flag UBIFS_SEED_KEY.
> > ubifs_ino_node: 0x1234 | UBIFS_INO_KEY | UBIFS_SEED_KEY
> > ubifs_data_node: 0x1234 |  | UBIFS_DATA_KEY |
> > UBIFS_SEED_KEY
> > 
> > The inode itself will have a flag which denotes whether this file
> > is seeded and whether some modifications have happened. This will
> > allow us to lookup directly in the index tree with UBIFS_SEED_KEY
> > set or no. Otherwise we'd have to do two lookups every time.
> > 
> > If a seeded node faces a modification it will stay referenced in
> > the index tree and a copy without UBIFS_SEED_KEY is made. Upon next
> > lookup the new node will be used automatically. Reverting to the
> > original state means purging all nodes that don't have the
> > UBIFS_SEED_KEY flag.
> > 
> > There are corner cases to consider, mostly for lookup of data nodes.
> > Currently a missing data node denotes a hole in a file.
> > With seeded files a missing data node can also mean that we need to
> > fall back to a UBIFS_SEED_KEY lookup.
> > 
> > Storing UBIFS_SEED_KEY itself into the UBIFS key is also not
> > trivial since almost all bits of the 32bit tuple are in use. But
> > I'm sure we find some way to encode it.
> > 
> > Another thing to consider are seeded directory entries. This
> > requires us to implement our own whiteout mechanism. But this could
> > also be re-used for overlayfs whiteouts.
> > 
> > That said, I consider this feature as doable but not trivial.
> > Artem, Adrian, you designed UBIFS, what do you think?
> > Maybe I missed some major show-stopper. :)
> > 
> > Thanks,
> > //richard
> > 
> > __
> > Linux MTD discussion mailing list
> > http://lists.infradead.org/mailman/listinfo/linux-mtd/
> >   
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] [ar71xx] ag71xx: add support for port mirroring

[Ralph Sennhauser]

On Wed, 26 Apr 2017 21:52:44 +0200
Milan Krstić  wrote:

> This exposes hardware port mirroring in ag71xx driver (e.g.
> TL-WR841ND) via swconfig API. It's my first patch ever so any
> feedback is welcome.

Hi Milan,

Comments like the last sentence belong after the --- below, so it isn't
part of the commit message.

> 
> Signed-off-by: Milan Krstic 
> ---
>  .../net/ethernet/atheros/ag71xx/ag71xx_ar7240.c| 154
> +
>  1 file changed, 154 insertions(+)
> 
> diff --git
> a/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_ar7240.c
> b/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_ar7240.c
> index c5aed0d..da9c0dd 100644
> ---
> a/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_ar7240.c
> +++
> b/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_ar7240.c
> @@ -77,6 +77,7 @@
> 
>  #define AR7240_REG_CPU_PORT 0x78
>  #define AR7240_MIRROR_PORT_S 4
> +#define AR7240_MIRROR_PORT_M BITM(4)
>  #define AR7240_CPU_PORT_EN BIT(8)
> 
>  #define AR7240_REG_MIB_FUNCTION0 0x80
> @@ -1013,6 +1014,134 @@ ar7240_get_port_stats(struct switch_dev *dev,
> int port,
>   return 0;
>  }
> 
> +static int
> +ar7240_set_mirror_monitor_port(struct switch_dev *dev,
> +   const struct switch_attr *attr,
> +   struct switch_val *val)
> +{
> + struct ar7240sw *as = sw_to_ar7240(dev);
> + struct mii_bus *mii = as->mii_bus;
> +
> + int port = val->value.i;
> +
> + if (port > 15)
> + return -EINVAL;
> +
> + ar7240sw_reg_rmw(mii, AR7240_REG_CPU_PORT,
> + AR7240_MIRROR_PORT_M << AR7240_MIRROR_PORT_S,
> + port << AR7240_MIRROR_PORT_S);
> +
> + return 0;
> +}
> +
> +static int
> +ar7240_get_mirror_monitor_port(struct switch_dev *dev,
> +   const struct switch_attr *attr,
> +   struct switch_val *val)
> +{
> + struct ar7240sw *as = sw_to_ar7240(dev);
> + struct mii_bus *mii = as->mii_bus;
> +
> + u32 ret;
> +
> + ret = ar7240sw_reg_read(mii, AR7240_REG_CPU_PORT);
> + val->value.i = (ret >> AR7240_MIRROR_PORT_S) & AR7240_MIRROR_PORT_M;
> +
> + return 0;
> +}
> +
> +static int
> +ar7240_set_mirror_rx(struct switch_dev *dev, const struct switch_attr
> *attr,
> + struct switch_val *val)
> +{
> + struct ar7240sw *as = sw_to_ar7240(dev);
> + struct mii_bus *mii = as->mii_bus;
> +
> + int port = val->port_vlan;
> +
> + if (port >= dev->ports)
> + return -EINVAL;
> +
> + if (val && val->value.i == 1)
> + ar7240sw_reg_set(mii, AR7240_REG_PORT_CTRL(port),
> + AR7240_PORT_CTRL_MIRROR_RX);
> + else
> + ar7240sw_reg_rmw(mii, AR7240_REG_PORT_CTRL(port),
> + AR7240_PORT_CTRL_MIRROR_RX, 0);
> +
> + return 0;
> +}
> +
> +static int
> +ar7240_get_mirror_rx(struct switch_dev *dev, const struct switch_attr
> *attr,
> + struct switch_val *val)
> +{
> + struct ar7240sw *as = sw_to_ar7240(dev);
> + struct mii_bus *mii = as->mii_bus;
> +
> + u32 ctrl;
> +
> + int port = val->port_vlan;
> +
> + if (port >= dev->ports)
> + return -EINVAL;
> +
> + ctrl = ar7240sw_reg_read(mii, AR7240_REG_PORT_CTRL(port));
> +
> + if ((ctrl & AR7240_PORT_CTRL_MIRROR_RX) ==
> AR7240_PORT_CTRL_MIRROR_RX)
> + val->value.i = 1;
> + else
> + val->value.i = 0;
> +
> + return 0;
> +}
> +
> +static int
> +ar7240_set_mirror_tx(struct switch_dev *dev, const struct switch_attr
> *attr,
> + struct switch_val *val)
> +{
> + struct ar7240sw *as = sw_to_ar7240(dev);
> + struct mii_bus *mii = as->mii_bus;
> +
> + int port = val->port_vlan;
> +
> + if (port >= dev->ports)
> + return -EINVAL;
> +
> + if (val && val->value.i == 1)
> + ar7240sw_reg_set(mii, AR7240_REG_PORT_CTRL(port),
> + AR7240_PORT_CTRL_MIRROR_TX);
> + else
> + ar7240sw_reg_rmw(mii, AR7240_REG_PORT_CTRL(port),
> + AR7240_PORT_CTRL_MIRROR_TX, 0);
> +
> + return 0;
> +}
> +
> +static int
> +ar7240_get_mirror_tx(struct switch_dev *dev, const struct switch_attr
> *attr,
> + struct switch_val *val)
> +{
> + struct ar7240sw *as = sw_to_ar7240(dev);
> + struct mii_bus *mii = as->mii_bus;
> +
> + u32 ctrl;
> +
> + int port = val->port_vlan;
> +
> + if (port >= dev->ports)
> + return -EINVAL;
> +
> + ctrl = ar7240sw_reg_read(mii, AR7240_REG_PORT_CTRL(port));
> +
> + if ((ctrl & AR7240_PORT_CTRL_MIRROR_TX) ==
> AR7240_PORT_CTRL_MIRROR_TX)
> + val->value.i = 1;
> + else
> + val->value.i = 0;
> +
> + return 0;
> +}
> +
>  static struct switch_attr ar7240_globals[] = {
>   {
>   .type = SWITCH_TYPE_INT,
> @@ -1022,9 +1151,34 @@ static struct switch_attr ar7240_globals[] = {
>   .get = ar7240_get_vlan,
>   .max = 1
>   },
> + {
> + .type = SWITCH_TYPE_INT,
> + .name = "mirror_monitor_port",
> + .description = "Mirror monitor port",
> + .set = ar7240_set_mirror_monitor_port,
> + .get = ar7240_get_mirror_monitor_port,
> + .max = 15
> + },
>  };
> 
>  static struct switch_attr ar7240_port[] = {
> + {
> + .type = SWITCH_TYPE_INT,
> + .name = "enable_mirror_rx",
> + .description = "Enable mirroring of RX packets",
> + .set = ar7240_set_mirror_rx,
> + .get = 

Re: [OpenWrt-Devel] dnscrypt-proxy package missing in snapshot

[Ralph Sennhauser]

On Mon, 13 Feb 2017 21:03:07 +0530
Mangesh Bhamre  wrote:

> Hi Alex,
> 
> Looking at build log -
> http://buildbot.openwrt.org:8010/broken_packages/ramips.mt7620/dnscrypt-proxy/compile.txt
> 
> Tar ball is available on download.dnscrypt.org . Build download fails
> for some SSL issue.

The site has HSTS enabled. Might that be the issue?

Maybe just updating PKG_SOURCE_URL to use https might be all that
is needed. There was another user having issues with a redirect and
samba. I think he was using Ubuntu.

Ralph

> 
> Also, tar ball is missing on mirror2.openwrt.org and
> downloads.openwrt.org/sources
> 
> Not sure, how mirror2 or download.openwrt.org gets updated.  Any help
> in getting is appreciated.
> 
> Regards,
> Mangesh
> 
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Adding host Java support to the buildbots

[Ralph Sennhauser]

On Fri, 30 Dec 2016 06:52:32 -0800
Dana Myers <k...@comcast.net> wrote:

> On 12/29/2016 11:50 PM, Ralph Sennhauser wrote:
> > Hi Dana
> >
> > On Thu, 29 Dec 2016 12:30:37 -0800
> > Dana Myers <k...@comcast.net> wrote:
> >  
> >> In reference to https://github.com/openwrt/packages/pull/3686
> >>
> >> We've added OpenWRT support for:
> >>
> >> * JamVM 2.0: Java JVM
> >> * GNU Classpath 2.0: Java class library  
> > There is no classpath 2.0  
> 
> Right you are - serves me right for spewing version numbers off the
> top of my head from something I initially did two years :-) It's
> classpath 0.99
> >  
> >> * RXTX Java serial communications library
> >>
> >> However, the build bots won't build these packages yet because
> >> a host Java compiler is required. To build these packages, I
> >> install:  
> > The main reason to use jamvm with gnu classpath is you can
> > bootstrap it without a jdk, right? If you already require a host
> > jdk why not go for jamvm with the openjdk classpath to get full
> > java support?  
> 
> I don't understand the question about bootstrapping and host vs
> target JDK. Host JDK is used specifically for javac to compile Java
> to bytecodes; target has no dependency on JDK otherwise.

Well, if you require openjdk-7-jdk on the build host you sidestep
bootstrapping java all together (c compiler & source code -> build) in
which case jamvm with openjdk classpath is as easy to get as with gnu
classpath but the latter only supports part of 1.5 & 1.6.

The question boils down to why you settle for something inferior when
you can have something much better.

> 
> Classpath was, for many years, the only library supported by JamVM,
> is much smaller than OpenJDK (valuable on resource-constrained
> systems) and remains the default library supported by JamVM. For the
> purposes of my project from which I contributed, Classpath is
> adequate and appears to avoid concerns about encumbrance of the
> target builds/devices with OpenJDK. Most specifically, however, was
> the apparent lack of support for MIPS32 which is a show-stopper for
> the AR71xx architecture I'm using.

Another alternative to hotspot on mips would be cacao, again with
openjdk classpath. Though jamvm certainly is a vaild pick.

What encumbrance concerns do you have in mind? Debian also ships the
binaries as in openjdk-7-jdk.

I don't object to jamvm with gnu classpath, just that I was wondering
why you'd pick it over the alternatives. Basically it's adding java
support that is hardly usable this days apart of a few specialized
cases.

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

Re: [OpenWrt-Devel] Adding host Java support to the buildbots

[Ralph Sennhauser]

Hi Dana

On Thu, 29 Dec 2016 12:30:37 -0800
Dana Myers  wrote:

> In reference to https://github.com/openwrt/packages/pull/3686
> 
> We've added OpenWRT support for:
> 
> * JamVM 2.0: Java JVM
> * GNU Classpath 2.0: Java class library

There is no classpath 2.0

> * RXTX Java serial communications library
> 
> However, the build bots won't build these packages yet because
> a host Java compiler is required. To build these packages, I
> install:

The main reason to use jamvm with gnu classpath is you can bootstrap it
without a jdk, right? If you already require a host jdk why not go for
jamvm with the openjdk classpath to get full java support?

> 
>  openjdk-7-jdk
> 
> (which also pulls in openjdk-7-jre and openjdk-7-jre-headless)
> 
> What needs to be done to add openjdk-7-jdk to the build bots?
> 
> Thank you,
> Dana
> 
> danak6jq@github
> k...@comcast.net
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH RFC firewall3] musl-compat: avoid kernel header conflicts

[Ralph Sennhauser]

On Mon, 7 Nov 2016 07:39:19 +0100
Ralph Sennhauser <ralph.sennhau...@gmail.com> wrote:

> On Sun, 6 Nov 2016 19:07:01 +0100
> Szabolcs Nagy <n...@port70.net> wrote:
> 
> > * Ralph Sennhauser <ralph.sennhau...@gmail.com> [2016-11-06 10:59:43
> > +0100]:  
> > > The conflict between Musls net/if.h and linux/if.h is an old well
> > > known one and taken care of by a series of linux-headers patches
> > > in OpenWrt. Since Linux 4.8-rc5 Firewall3 also indirectly pulls in
> > > linux/in.h and linux/in6.h leading to new conflicts.
> > 
> > can you check if
> > http://www.openwall.com/lists/musl/2016/10/18/1
> > works for you?  
> 
> Hi
> 
> That is an interesting find. It won't be able to magically fix all the
> packages but could help a lot in fixing them in a cleaner manner. Will
> take me a while to have a in depth look at this one and it's impact.
> Thou as it's suggested by Rich Felker I guess investing some of my
> time wont be wasted.
> 
> Thanks
> Ralph

Hi,

Tested musl commit 04983f227238 (make netinet/in.h suppress clashing
definitions from kernel headers) and a patch by Felix Janda
https://lkml.org/lkml/2016/11/11/210 . This fixes arptables and
conntrack-tools for kernels 4.8 and later. For netifd, ebtables and ppp
this fixes the netinet/in.h related issues without reordering of any
headers.

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

Re: [OpenWrt-Devel] [PATCH RFC firewall3] musl-compat: avoid kernel header conflicts

[Ralph Sennhauser]

On Sun, 6 Nov 2016 19:07:01 +0100
Szabolcs Nagy <n...@port70.net> wrote:

> * Ralph Sennhauser <ralph.sennhau...@gmail.com> [2016-11-06 10:59:43
> +0100]:
> > The conflict between Musls net/if.h and linux/if.h is an old well
> > known one and taken care of by a series of linux-headers patches in
> > OpenWrt. Since Linux 4.8-rc5 Firewall3 also indirectly pulls in
> > linux/in.h and linux/in6.h leading to new conflicts.  
> 
> can you check if
> http://www.openwall.com/lists/musl/2016/10/18/1
> works for you?

Hi

That is an interesting find. It won't be able to magically fix all the
packages but could help a lot in fixing them in a cleaner manner. Will
take me a while to have a in depth look at this one and it's impact.
Thou as it's suggested by Rich Felker I guess investing some of my time
wont be wasted.

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

Re: [OpenWrt-Devel] [PATCH RFC firewall3] musl-compat: avoid kernel header conflicts

[Ralph Sennhauser]

Hi Jo

On Sun, 6 Nov 2016 20:48:58 +0100
Jo-Philipp Wich  wrote:

> Hi again,
> 
> > Will see if I find another solution...  
> 
> I managed to find a solution that works for me on a Linux 4.6.0 system
> with glibc, a Linux 4.6.0 system with unpatched musl and a Linux 4.4
> system with patched kernel headers.
> 

Well, this doesn't make it less dubious of a hack but as I'm the one
who ultimately suggested such no complaints from me. Thanks for making
it glibc compatible.

> I pushed this change along with a few others that should aid in
> portability to the repository now.
> 
> Feedback appreciated.
> 
> ~ Jo

About xt_id, that's how I'd have done it from the start, so thumbs up on
that one. Even less vendor lock-in. In fact after the last weeks changes
you can take firewall3 to pretty much any Linux distro and it still be
useful, well, while iptables still lasts that is.

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

[OpenWrt-Devel] [PATCH RFC firewall3] musl-compat: avoid kernel header conflicts

[Ralph Sennhauser]

The conflict between Musls net/if.h and linux/if.h is an old well known
one and taken care of by a series of linux-headers patches in OpenWrt.
Since Linux 4.8-rc5 Firewall3 also indirectly pulls in linux/in.h and
linux/in6.h leading to new conflicts.

As Firewall3 is fine with just the libc headers prevent inclusion of the
corresponding kernel headers.

Signed-off-by: Ralph Sennhauser <ralph.sennhau...@gmail.com>
---

Jo,

this certainly isn't the most elegant solution but at least it's immediately
obvious what it is about.

Firewall3 is one of only a few remaining packages still having issues with Musl
and vanilla kernel and apart from netifd the only significant one in base. So
fixing this issue one way or another is desirable.

This is also the last issue that needs to be addressed for me to run vanilla
Firewall3 again.

Ralph


 iptables.h | 3 +++
 options.h  | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/iptables.h b/iptables.h
index bcd302d..8e0089e 100644
--- a/iptables.h
+++ b/iptables.h
@@ -19,6 +19,9 @@
 #ifndef __FW3_IPTABLES_H
 #define __FW3_IPTABLES_H
 
+#define _LINUX_IF_H
+#define _LINUX_IN_H
+#define _LINUX_IN6_H
 #include 
 #include 
 #include 
diff --git a/options.h b/options.h
index 6c9c0b2..307c5af 100644
--- a/options.h
+++ b/options.h
@@ -32,6 +32,8 @@
 #include 
 #include 
 #include 
+#define _LINUX_IN_H
+#define _LINUX_IN6_H
 #include 
 #include 
 
-- 
2.7.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH firewall3] iptables: optional loading of static extensions

[Ralph Sennhauser]

Make loading of static extensions optional to support vanilla iptables
in it's default configuration by setting DISABLE_STATIC_EXTENSIONS
instead of hackery.

In case iptables is built with --disable-static libext.a, libext4.a and
libext6.a which OpenWrt installs in the form of libiptext.so,
libiptext4.so, libiptext6.so to save a couple more bytes are of no use
or non-existent one could say. So this commit avoids requiring a
tampered with iptables.

Signed-off-by: Ralph Sennhauser <ralph.sennhau...@gmail.com>
---
 CMakeLists.txt | 12 +---
 iptables.c |  4 
 iptables.h |  2 ++
 3 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 00d1444..e2a88e7 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -7,11 +7,17 @@ SET(iptc_libs   ip4tc)
 
 SET(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS "")
 
-LIST(APPEND ext_libs iptext)
-LIST(APPEND ext_libs iptext4)
+IF (NOT DISABLE_STATIC_EXTENSIONS)
+  LIST(APPEND ext_libs iptext)
+  LIST(APPEND ext_libs iptext4)
+  IF (NOT DISABLE_IPV6)
+LIST(APPEND ext_libs iptext6)
+  ENDIF()
+ELSE()
+  ADD_DEFINITIONS(-DDISABLE_STATIC_EXTENSIONS)
+ENDIF()
 
 IF (NOT DISABLE_IPV6)
-  LIST(APPEND ext_libs iptext6)
   LIST(APPEND iptc_libs ip6tc)
 ELSE()
   ADD_DEFINITIONS(-DDISABLE_IPV6)
diff --git a/iptables.c b/iptables.c
index fc22d1a..66baa0a 100644
--- a/iptables.c
+++ b/iptables.c
@@ -69,6 +69,7 @@ get_kernel_version(void)
kernel_version = 0x1 * x + 0x100 * y + z;
 }
 
+#ifndef DISABLE_STATIC_EXTENSIONS
 static void fw3_init_extensions(void)
 {
init_extensions();
@@ -78,6 +79,7 @@ static void fw3_init_extensions(void)
init_extensions6();
 #endif
 }
+#endif
 
 struct fw3_ipt_handle *
 fw3_ipt_open(enum fw3_family family, enum fw3_table table)
@@ -117,7 +119,9 @@ fw3_ipt_open(enum fw3_family family, enum fw3_table table)
}
 
fw3_xt_reset();
+#ifndef DISABLE_STATIC_EXTENSIONS
fw3_init_extensions();
+#endif
 
if (xext.register_match)
for (i = 0; i < xext.mcount; i++)
diff --git a/iptables.h b/iptables.h
index bcd302d..23f8c03 100644
--- a/iptables.h
+++ b/iptables.h
@@ -42,10 +42,12 @@
 # error "Unsupported xtables version"
 #endif
 
+#ifndef DISABLE_STATIC_EXTENSIONS
 /* libipt*ext.so interfaces */
 extern void init_extensions(void);
 extern void init_extensions4(void);
 extern void init_extensions6(void);
+#endif
 
 /* Required by certain extensions like SNAT and DNAT */
 extern int kernel_version;
-- 
2.7.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH firewall3] iptables: fix loading standard target

[Ralph Sennhauser]

On Sat, 5 Nov 2016 17:58:49 +0100
Jo-Philipp Wich  wrote:

> Hi Ralph,
> 
> thanks - applied with minor code style change in 010723e.
> 
> ~ Jo
> 

Hi Jo,

fixup looks good.

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

[OpenWrt-Devel] [PATCH firewall3] iptables: fix loading standard target

[Ralph Sennhauser]

In case iptables is built with --disable-static xt_standard needs to be
loaded just like the other extensions.

Signed-off-by: Ralph Sennhauser <ralph.sennhau...@gmail.com>
---
 iptables.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/iptables.c b/iptables.c
index 95fc0d4..bbd2b00 100644
--- a/iptables.c
+++ b/iptables.c
@@ -630,8 +630,15 @@ find_target(struct fw3_ipt_rule *r, const char *name)
 {
struct xtables_target *t;
 
-   if (is_chain(r->h, name))
-   return xtables_find_target(XT_STANDARD_TARGET, 
XTF_LOAD_MUST_SUCCEED);
+   if (is_chain(r->h, name)) {
+   t = xtables_find_target(XT_STANDARD_TARGET, XTF_DONT_LOAD);
+   if (t) {
+   return t;
+   } else {
+   load_extension(r->h, "standard");
+   return xtables_find_target(XT_STANDARD_TARGET, 
XTF_LOAD_MUST_SUCCEED);
+   }
+   }
 
t = xtables_find_target(name, XTF_DONT_LOAD);
 
-- 
2.7.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH firewall3] iptables: add support for version 1.6.0

[Ralph Sennhauser]

Account for the struct xtables_globals change and add API version 11 to
the supported APIs.

Signed-off-by: Ralph Sennhauser <ralph.sennhau...@gmail.com>
---
 iptables.c | 6 ++
 iptables.h | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/iptables.c b/iptables.c
index 2a0d0ee..95fc0d4 100644
--- a/iptables.c
+++ b/iptables.c
@@ -29,12 +29,18 @@ static struct xtables_globals xtg = {
.option_offset = 0,
.program_version = "4",
.orig_opts = base_opts,
+#if XTABLES_VERSION_CODE > 10
+   .compat_rev = xtables_compatible_revision,
+#endif
 };
 
 static struct xtables_globals xtg6 = {
.option_offset = 0,
.program_version = "6",
.orig_opts = base_opts,
+#if XTABLES_VERSION_CODE > 10
+   .compat_rev = xtables_compatible_revision,
+#endif
 };
 
 static struct {
diff --git a/iptables.h b/iptables.h
index 892a0d4..bcd302d 100644
--- a/iptables.h
+++ b/iptables.h
@@ -34,7 +34,7 @@
 #define FW3_ID_MASK0xff00
 
 /* xtables interface */
-#if (XTABLES_VERSION_CODE == 10)
+#if (XTABLES_VERSION_CODE == 10 || XTABLES_VERSION_CODE == 11)
 # include "xtables-10.h"
 #elif (XTABLES_VERSION_CODE == 5)
 # include "xtables-5.h"
-- 
2.7.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] check: upgrade to 0.10.0

[Ralph Sennhauser]

On Wed, 21 Sep 2016 11:25:23 +0200
Eduardo Abinader  wrote:

> updated new package url and solved some issues:
> https://github.com/libcheck/check/releases/tag/0.10.0
> 
> Signed-off-by: Eduardo Abinader 
> ---
>  libs/check/Makefile | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/libs/check/Makefile b/libs/check/Makefile
> index eb735ee..21a35c9 100644
> --- a/libs/check/Makefile
> +++ b/libs/check/Makefile
> @@ -8,12 +8,12 @@
>  include $(TOPDIR)/rules.mk
>  
>  PKG_NAME:=check
> -PKG_VERSION:=0.9.14
> -PKG_RELEASE:=2
> +PKG_VERSION:=0.10.0
> +PKG_RELEASE:=3

In case you bump version, reset release. Bump release if you make
changes without version bump.

>  
>  PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
> -PKG_SOURCE_URL:=@SF/check
> -PKG_MD5SUM:=38263d115d784c17aa3b959ce94be8b8
> +PKG_SOURCE_URL:=https://github.com/libcheck/check/releases/tag/$(PKG_VERSION)
> +PKG_MD5SUM:=53c5e5c77d090e103a17f3ed7fd7d8b8
>  
>  PKG_LICENSE:=LGPL-2.1+
>  PKG_LICENSE_FILES:=COPYING.LESSER
> @@ -27,7 +27,7 @@ define Package/check
>SECTION:=libs
>CATEGORY:=Libraries
>TITLE:=Unit testing framework for C
> -  URL:=http://check.sourceforge.net/
> +  URL:=https://libcheck.github.io/check/
>DEPENDS:= +libpthread +librt
>  endef
>  
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 4/4] kernel: add kmod-fs-ubifs

[Ralph Sennhauser]

Signed-off-by: Ralph Sennhauser <ralph.sennhau...@gmail.com>
---
 package/kernel/linux/modules/fs.mk | 17 +
 1 file changed, 17 insertions(+)

diff --git a/package/kernel/linux/modules/fs.mk 
b/package/kernel/linux/modules/fs.mk
index bb9ecc4..8fe4473 100644
--- a/package/kernel/linux/modules/fs.mk
+++ b/package/kernel/linux/modules/fs.mk
@@ -436,6 +436,23 @@ endef
 $(eval $(call KernelPackage,fs-squashfs))
 
 
+define KernelPackage/fs-ubifs
+  SUBMENU:=$(FS_MENU)
+  TITLE:=UBIFS file system support
+  KCONFIG:=CONFIG_UBIFS_FS
+  FILES:=$(LINUX_DIR)/fs/ubifs/ubifs.ko
+  AUTOLOAD:=$(call AutoLoad,30,ubifs,1)
+  DEPENDS:=+kmod-ubi
+  $(call AddDepends/nls)
+endef
+
+define KernelPackage/fs-ubifs/description
+ UBIFS is a file system for flash devices which works on top of UBI.
+endef
+
+$(eval $(call KernelPackage,fs-ubifs))
+
+
 define KernelPackage/fs-udf
   SUBMENU:=$(FS_MENU)
   TITLE:=UDF filesystem support
-- 
2.7.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 3/4] kernel: add kmod-ubi

[Ralph Sennhauser]

Signed-off-by: Ralph Sennhauser <ralph.sennhau...@gmail.com>
---
 package/kernel/linux/modules/block.mk | 21 +
 1 file changed, 21 insertions(+)

diff --git a/package/kernel/linux/modules/block.mk 
b/package/kernel/linux/modules/block.mk
index d7f5ca4..99ace6c 100644
--- a/package/kernel/linux/modules/block.mk
+++ b/package/kernel/linux/modules/block.mk
@@ -579,6 +579,27 @@ endef
 $(eval $(call KernelPackage,nbd))
 
 
+define KernelPackage/ubi
+  SUBMENU:=$(BLOCK_MENU)
+  TITLE:=Unsorted block images
+  KCONFIG:= \
+   CONFIG_MTD_UBI \
+   CONFIG_MTD_UBI_BLOCK=y
+  FILES:=$(LINUX_DIR)/drivers/mtd/ubi/ubi.ko
+  AUTOLOAD:=$(call AutoLoad,30,ubi,1)
+endef
+
+define KernelPackage/ubi/description
+ UBI is a software layer above MTD layer which admits of LVM-like
+ logical volumes on top of MTD devices, hides some complexities of
+ flash chips like wear and bad blocks and provides some other useful
+ capabilities. Please, consult the MTD web site for more details
+ (www.linux-mtd.infradead.org).
+endef
+
+$(eval $(call KernelPackage,ubi))
+
+
 define KernelPackage/scsi-core
   SUBMENU:=$(BLOCK_MENU)
   TITLE:=SCSI device support
-- 
2.7.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/4] kernel: update config for ubi and ubifs

[Ralph Sennhauser]

Signed-off-by: Ralph Sennhauser <ralph.sennhau...@gmail.com>
---
 target/linux/generic/config-3.18 | 5 +
 target/linux/generic/config-4.1  | 5 +
 target/linux/generic/config-4.4  | 5 +
 3 files changed, 15 insertions(+)

diff --git a/target/linux/generic/config-3.18 b/target/linux/generic/config-3.18
index b4e283e..b03cf56 100644
--- a/target/linux/generic/config-3.18
+++ b/target/linux/generic/config-3.18
@@ -2286,6 +2286,10 @@ CONFIG_MTD_SPLIT_SUPPORT=y
 # CONFIG_MTD_SWAP is not set
 # CONFIG_MTD_TESTS is not set
 # CONFIG_MTD_UBI is not set
+CONFIG_MTD_UBI_BEB_LIMIT=20
+# CONFIG_MTD_UBI_FASTMAP is not set
+# CONFIG_MTD_UBI_GLUEBI is not set
+CONFIG_MTD_UBI_WL_THRESHOLD=4096
 # CONFIG_MTD_UIMAGE_SPLIT is not set
 # CONFIG_MUTEX_SPIN_ON_OWNER is not set
 # CONFIG_MV643XX_ETH is not set
@@ -4036,6 +4040,7 @@ CONFIG_TTY=y
 # CONFIG_TWL6040_CORE is not set
 # CONFIG_TYPHOON is not set
 # CONFIG_UACCESS_WITH_MEMCPY is not set
+# CONFIG_UBIFS_FS_ADVANCED_COMPR is not set
 # CONFIG_UCB1400_CORE is not set
 # CONFIG_UDF_FS is not set
 CONFIG_UDF_NLS=y
diff --git a/target/linux/generic/config-4.1 b/target/linux/generic/config-4.1
index eb2c249..77d2cf1 100644
--- a/target/linux/generic/config-4.1
+++ b/target/linux/generic/config-4.1
@@ -2380,6 +2380,10 @@ CONFIG_MTD_SPLIT_SUPPORT=y
 # CONFIG_MTD_SWAP is not set
 # CONFIG_MTD_TESTS is not set
 # CONFIG_MTD_UBI is not set
+CONFIG_MTD_UBI_BEB_LIMIT=20
+# CONFIG_MTD_UBI_FASTMAP is not set
+# CONFIG_MTD_UBI_GLUEBI is not set
+CONFIG_MTD_UBI_WL_THRESHOLD=4096
 # CONFIG_MTD_UIMAGE_SPLIT is not set
 CONFIG_MULTIUSER=y
 # CONFIG_MUTEX_SPIN_ON_OWNER is not set
@@ -4205,6 +4209,7 @@ CONFIG_TTY=y
 # CONFIG_TWL6040_CORE is not set
 # CONFIG_TYPHOON is not set
 # CONFIG_UACCESS_WITH_MEMCPY is not set
+# CONFIG_UBIFS_FS_ADVANCED_COMPR is not set
 # CONFIG_UCB1400_CORE is not set
 # CONFIG_UDF_FS is not set
 CONFIG_UDF_NLS=y
diff --git a/target/linux/generic/config-4.4 b/target/linux/generic/config-4.4
index 24b8c48..20af570 100644
--- a/target/linux/generic/config-4.4
+++ b/target/linux/generic/config-4.4
@@ -2367,6 +2367,10 @@ CONFIG_MTD_SPLIT_SUPPORT=y
 # CONFIG_MTD_SWAP is not set
 # CONFIG_MTD_TESTS is not set
 # CONFIG_MTD_UBI is not set
+CONFIG_MTD_UBI_BEB_LIMIT=20
+# CONFIG_MTD_UBI_FASTMAP is not set
+# CONFIG_MTD_UBI_GLUEBI is not set
+CONFIG_MTD_UBI_WL_THRESHOLD=4096
 # CONFIG_MTD_UIMAGE_SPLIT is not set
 CONFIG_MULTIUSER=y
 # CONFIG_MUTEX_SPIN_ON_OWNER is not set
@@ -4235,6 +4239,7 @@ CONFIG_TTY=y
 # CONFIG_TYPHOON is not set
 # CONFIG_UACCESS_WITH_MEMCPY is not set
 # CONFIG_UBIFS_ATIME_SUPPORT is not set
+# CONFIG_UBIFS_FS_ADVANCED_COMPR is not set
 # CONFIG_UCB1400_CORE is not set
 # CONFIG_UDF_FS is not set
 CONFIG_UDF_NLS=y
-- 
2.7.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/4] kernel: fix ubi automount patches

[Ralph Sennhauser]

When building ubi as a module modpost failes due to ROOT_DEV being
undefined. Daniel Golle suggested to add a guard to the code for
CONFIG_MTD_ROOTFS_ROOT_DEV which only is usable in case ubi is builtin
anyway.

While at it replace the deprecated config_enabled macros.

Suggested-by: Daniel Golle <dan...@makrotopia.org>
Signed-off-by: Ralph Sennhauser <ralph.sennhau...@gmail.com>
---
 .../patches-3.18/491-ubi-auto-create-ubiblock-device-for-rootfs.patch   | 2 +-
 .../patches-3.18/493-ubi-set-ROOT_DEV-to-ubiblock-rootfs-if-unset.patch | 2 +-
 .../patches-4.1/491-ubi-auto-create-ubiblock-device-for-rootfs.patch| 2 +-
 .../patches-4.1/493-ubi-set-ROOT_DEV-to-ubiblock-rootfs-if-unset.patch  | 2 +-
 .../patches-4.4/491-ubi-auto-create-ubiblock-device-for-rootfs.patch| 2 +-
 .../patches-4.4/493-ubi-set-ROOT_DEV-to-ubiblock-rootfs-if-unset.patch  | 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git 
a/target/linux/generic/patches-3.18/491-ubi-auto-create-ubiblock-device-for-rootfs.patch
 
b/target/linux/generic/patches-3.18/491-ubi-auto-create-ubiblock-device-for-rootfs.patch
index b152fba..f380ece 100644
--- 
a/target/linux/generic/patches-3.18/491-ubi-auto-create-ubiblock-device-for-rootfs.patch
+++ 
b/target/linux/generic/patches-3.18/491-ubi-auto-create-ubiblock-device-for-rootfs.patch
@@ -61,7 +61,7 @@ Signed-off-by: Daniel Golle <dan...@makrotopia.org>
goto err_remove;
  
 +  /* auto-attach "rootfs" volume if existing and non-ubifs */
-+  if (config_enabled(CONFIG_MTD_ROOTFS_ROOT_DEV))
++  if (IS_ENABLED(CONFIG_MTD_ROOTFS_ROOT_DEV) && 
IS_BUILTIN(CONFIG_MTD_UBI))
 +  ubiblock_create_auto_rootfs();
 +
/*
diff --git 
a/target/linux/generic/patches-3.18/493-ubi-set-ROOT_DEV-to-ubiblock-rootfs-if-unset.patch
 
b/target/linux/generic/patches-3.18/493-ubi-set-ROOT_DEV-to-ubiblock-rootfs-if-unset.patch
index 46917d1..74be482 100644
--- 
a/target/linux/generic/patches-3.18/493-ubi-set-ROOT_DEV-to-ubiblock-rootfs-if-unset.patch
+++ 
b/target/linux/generic/patches-3.18/493-ubi-set-ROOT_DEV-to-ubiblock-rootfs-if-unset.patch
@@ -25,7 +25,7 @@ Signed-off-by: Daniel Golle <dan...@makrotopia.org>
dev->gd->disk_name, dev->ubi_num, dev->vol_id, vi->name);
 +
 +  if (!strcmp(vi->name, "rootfs") &&
-+  config_enabled(CONFIG_MTD_ROOTFS_ROOT_DEV) &&
++  IS_ENABLED(CONFIG_MTD_ROOTFS_ROOT_DEV) && 
IS_BUILTIN(CONFIG_MTD_UBI) &&
 +  ROOT_DEV == 0) {
 +  pr_notice("ubiblock: device ubiblock%d_%d (%s) set to be root 
filesystem\n",
 +dev->ubi_num, dev->vol_id, vi->name);
diff --git 
a/target/linux/generic/patches-4.1/491-ubi-auto-create-ubiblock-device-for-rootfs.patch
 
b/target/linux/generic/patches-4.1/491-ubi-auto-create-ubiblock-device-for-rootfs.patch
index 433d77b..541da1f 100644
--- 
a/target/linux/generic/patches-4.1/491-ubi-auto-create-ubiblock-device-for-rootfs.patch
+++ 
b/target/linux/generic/patches-4.1/491-ubi-auto-create-ubiblock-device-for-rootfs.patch
@@ -61,7 +61,7 @@ Signed-off-by: Daniel Golle <dan...@makrotopia.org>
ubiblock_create_from_param();
  
 +  /* auto-attach "rootfs" volume if existing and non-ubifs */
-+  if (config_enabled(CONFIG_MTD_ROOTFS_ROOT_DEV))
++  if (IS_ENABLED(CONFIG_MTD_ROOTFS_ROOT_DEV) && 
IS_BUILTIN(CONFIG_MTD_UBI))
 +  ubiblock_create_auto_rootfs();
 +
/*
diff --git 
a/target/linux/generic/patches-4.1/493-ubi-set-ROOT_DEV-to-ubiblock-rootfs-if-unset.patch
 
b/target/linux/generic/patches-4.1/493-ubi-set-ROOT_DEV-to-ubiblock-rootfs-if-unset.patch
index 1873752..6a8a2ce 100644
--- 
a/target/linux/generic/patches-4.1/493-ubi-set-ROOT_DEV-to-ubiblock-rootfs-if-unset.patch
+++ 
b/target/linux/generic/patches-4.1/493-ubi-set-ROOT_DEV-to-ubiblock-rootfs-if-unset.patch
@@ -25,7 +25,7 @@ Signed-off-by: Daniel Golle <dan...@makrotopia.org>
 dev->ubi_num, dev->vol_id, vi->name);
 +
 +  if (!strcmp(vi->name, "rootfs") &&
-+  config_enabled(CONFIG_MTD_ROOTFS_ROOT_DEV) &&
++  IS_ENABLED(CONFIG_MTD_ROOTFS_ROOT_DEV) && 
IS_BUILTIN(CONFIG_MTD_UBI) &&
 +  ROOT_DEV == 0) {
 +  pr_notice("ubiblock: device ubiblock%d_%d (%s) set to be root 
filesystem\n",
 +dev->ubi_num, dev->vol_id, vi->name);
diff --git 
a/target/linux/generic/patches-4.4/491-ubi-auto-create-ubiblock-device-for-rootfs.patch
 
b/target/linux/generic/patches-4.4/491-ubi-auto-create-ubiblock-device-for-rootfs.patch
index da31112..b073797 100644
--- 
a/target/linux/generic/patches-4.4/491-ubi-auto-create-ubiblock-device-for-rootfs.patch
+++ 
b/target/linux/generic/patches-4.4/491-ubi-auto-create-ubiblock-device-for-rootfs.patch
@@ -61,7

[OpenWrt-Devel] [PATCH v3 0/4] Add kmod-ubi and kmod-fs-ubifs

[Ralph Sennhauser]

This series adds support for building ubi and ubifs as modules if not
already builtin.

I use kmod-ubi for creating a block device from the squasfs in the
initramfs using module parameters as there is no busybox ubiblock
applet yet. If ubi is made available as module so obvioulsy should
ubifs.

Changes since V1:
  * kmod-ubifs -> kmod-fs-ubifs in commit message

Changes since V2:
  * Fix building ubi as module for some tartgets
  * Update kernel configs for non ubi targets
  * Reset series to have a clean history


Ralph Sennhauser (4):
  kernel: fix ubi automount patches
  kernel: update config for ubi and ubifs
  kernel: add kmod-ubi
  kernel: add kmod-fs-ubifs

 package/kernel/linux/modules/block.mk   | 21 +
 package/kernel/linux/modules/fs.mk  | 17 +
 target/linux/generic/config-3.18|  5 +
 target/linux/generic/config-4.1 |  5 +
 target/linux/generic/config-4.4 |  5 +
 ...ubi-auto-create-ubiblock-device-for-rootfs.patch |  2 +-
 ...i-set-ROOT_DEV-to-ubiblock-rootfs-if-unset.patch |  2 +-
 ...ubi-auto-create-ubiblock-device-for-rootfs.patch |  2 +-
 ...i-set-ROOT_DEV-to-ubiblock-rootfs-if-unset.patch |  2 +-
 ...ubi-auto-create-ubiblock-device-for-rootfs.patch |  2 +-
 ...i-set-ROOT_DEV-to-ubiblock-rootfs-if-unset.patch |  2 +-
 11 files changed, 59 insertions(+), 6 deletions(-)

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

Re: [OpenWrt-Devel] [PATCH v2 0/2] kernel: add kmod-ubi and kmod-fs-ubifs

[Ralph Sennhauser]

On Thu, 25 Aug 2016 13:07:43 +0200
Daniel Golle <dan...@makrotopia.org> wrote:

> On Thu, Aug 25, 2016 at 12:50:59PM +0200, Ralph Sennhauser wrote:
> > Hi Daniel,
> > 
> > On Thu, 25 Aug 2016 10:53:34 +0200
> > Daniel Golle <dan...@makrotopia.org> wrote:
> > 
> > [snip]
> >   
> > > Are you planning to switch to initramfs and then load the ubi and
> > > ubifs modules in order to get a persistent rootfs?!
> > > Remember that otherwise, these modules are needed to be built-in
> > > to the kernel in order to mount the rootfs during boot.  
> > 
> > I use an initramfs to mount root indeed. This is just an
> > alternative to 7 patches in generic and mvebu to do the same.
> > 
> > The kernel partition is 6MB, so there is plenty space and using
> > busybox works fine except there is no ubiblock applet. To work
> > around this I build ubi as a module instead of built-in and use
> > module parameter to create a blockdevice from the squashfs volume
> > for use by the overlayfs.  
> 
> Does the memory used for the initramfs get freed once you switched to
> the 'real' rootfs? If so, this would indeed be a quite good
> alternative to the current way and also provide other pre-init
> features such as failsafe-mode.
> 
> I'll also be working on improving the patch-situation, afaik it's
> currently 3 patches which are not yet upstream to handle mounting

In case of mvebu at least generic/995-mangle_bootargs.patch and
mvebu/100-find_active_root.patch are required as well. Unless of course
you use an initramfs.

Cheers
Ralph


> ubifs as well as creating ubiblock and selecting it as root_dev for
> squashfs. I'm planning to implement parsing the root= cmdline
> parameter in the same way UBIFS does, so in case of non-ubifs rootfs,
> a ubiblock can be auto-created based on the volume specified in the
> cmdline. This will improve the situation eg. for dual-boot, as the
> volume name to-be-mounted will no longer need to be hard-coded into
> the kernel. Once this is done, the remaining patches can be replaced
> with those fit-for-upstream versions.
> 
> 
> Cheers
> 
> 
> Daniel
> 
> 
> 
> > 
> > Cheers
> > Ralph  
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH/RFC 0/3] UBI: unify mouting rootfs based on cmdline parameter

[Ralph Sennhauser]

On Sun, 28 Aug 2016 13:44:48 +0200
Daniel Golle <dan...@makrotopia.org> wrote:

> Hi Richard,
> 
> On Sun, Aug 28, 2016 at 11:28:18AM +0200, Richard Weinberger wrote:
> > Ralph,
> > 
> > On 28.08.2016 11:19, Ralph Sennhauser wrote:  
> > >>> On the other hand an initramfs can carry the logic to figure out
> > >>> which to mount and is what I use for my self. The busybox based
> > >>> implementation I use adds a tad over 300Kb to the uImage,
> > >>> perfectly acceptable in my case.
> > >>
> > >> When your minimal initramfs consumes 300KiB you're doing
> > >> something wrong. As I said in another thread, for your special
> > >> purpose you'd need to create a minitmal userspace for initramfs,
> > >> no fancy (eg)libc, just a bare minimum /init program which does
> > >> the mount probing. Shouldn’t be more than a few system calls.  
> 
> That would indeed be nice, however, I fail to see how this can work
> with little effort *before* having devtmpfs ready. Also, we'll need a
> non-standard kernel parameter (usually "real_root=") to pass the
> selected rootfs down to our to-be-implemented micro-sized initramfs.

There is no such requirement, an initramfs lets you do with root= what
you want.

> 
> > >>
> > >> Thanks,
> > >> //richard  
> > > 
> > > Well, I use busybox because I'm lazy and still get away with only
> > > 300Kb. And as I said there is plenty space on my device. (6M per
> > > uImage OEM firmware configuration)  
> > 
> > So, problem solved. Use an initramfs. :-)  
> 
> I agree this might be acceptable for some, but certainly not all
> cases.

It's not guaranteed to be solved, but it looks a lot like it is. I
suggest you pick a target that can be solved with dtb and one that
needs an initramfs and experiment with it. The comments I came across
in the openwrt sources wrt initramfs are often misguided.

Once you have an example that can't be reasonably addressed with
either dtb or initramfs would be the time to resume here.

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

Re: [OpenWrt-Devel] [PATCH/RFC 0/3] UBI: unify mouting rootfs based on cmdline parameter

[Ralph Sennhauser]

Hi Richard,

On Sun, 28 Aug 2016 10:12:31 +0200
Richard Weinberger <rich...@nod.at> wrote:

> Ralph,
> 
> On 28.08.2016 09:10, Ralph Sennhauser wrote:
> > Using CONFIG_CMDLINE or the dtb isn't an option either for dual
> > firmware devices. You'd have to provide two images, one for each
> > partition so the rootfs belonging to the kernel gets mounted.
> > Sounds like a recipe for disaster.  
> 
> With "image" you mean the uImage?

uImage - padding to 6MB - ubinized rootfs. A firmware image as is
flashed by users.

Linksys set it up so that if one firmware image is broken there is a
good chance the bootloader will attempt to boot the other.

> Well, then you need to add the cmdline to the DT.
> If your bootloader does not support DT loading and you need to append
> it to uImage, yes, you'll have to two uImage for these devices.

Two uImages / firmware images is probably more problematic than asking
the user to fix the kernel parameters passed by u-boot.

> Or a initramfs...
> 
> But IMHO it still does not justify adding these hacks to the kernel.
> 

Those hacks can be justified if there is a case an initramfs or
CONFIG_CMDLINE/dtb doesn't work. I can't think of such a case right
now.

> > On the other hand an initramfs can carry the logic to figure out
> > which to mount and is what I use for my self. The busybox based
> > implementation I use adds a tad over 300Kb to the uImage, perfectly
> > acceptable in my case.  
> 
> When your minimal initramfs consumes 300KiB you're doing something
> wrong. As I said in another thread, for your special purpose you'd
> need to create a minitmal userspace for initramfs, no fancy (eg)libc,
> just a bare minimum /init program which does the mount probing.
> Shouldn’t be more than a few system calls.
> 
> Thanks,
> //richard

Well, I use busybox because I'm lazy and still get away with only 300Kb.
And as I said there is plenty space on my device. (6M per uImage OEM
firmware configuration)

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

Re: [OpenWrt-Devel] [PATCH/RFC 0/3] UBI: unify mouting rootfs based on cmdline parameter

[Ralph Sennhauser]

Hi Richard,

On Sat, 27 Aug 2016 22:43:45 +0200
Richard Weinberger  wrote:

> Daniel,
> 
> On 27.08.2016 21:43, Daniel Golle wrote:
> > Hi!
> > 
> > In an attempts to fix the flaws of the current set of UBI-related
> > patches we are carrying in OpenWrt, I re-wrote the way mounting the
> > rootfs from UBI in OpenWrt/LEDE works. The main requirement I face
> > which cannot be easily addressed using other means which are already
> > available in the kernel is the fact that UBIFS and squashfs-on-UBI
> > require different parameters to be set on the cmdline, e.g.
> > for UBIFS: ubi.mtd=ubi root=ubi0:rootfs rootfstype=ubifs
> > for squashfs: ubi.mtd=ubi ubiblock=0,1 root=/dev/ubiblock0_1
> > rootfstype=squashfs
> > 
> > The idea behind this patchset is to provide a single syntax which
> > allows mouting rootfs in both cases. To achieve that, the parsing of
> > the volume name string from UBIFS is moved to UBI, so it can be
> > reused by other in-kernel users. This is then used by
> > init/do_mounts.c to create a ubiblock device if the filesystem on
> > the device is non-UBIFS. To actually set this device to be
> > ROOT_DEV, ubiblock_create is extended to allow passing-back the
> > created ubiblock device.
> > 
> > With those changes, a single set of cmdline parameters is
> > sufficient to mount either UBIFS or any other block filesystem
> > by creating a ubiblock device:
> > ubi.mtd=ubi root=ubi0:rootfs rootfstype=ubifs,squashfs  
> 
> well, this all boils down to the point we have already been.
> I will tell you do set the cmdline correctly, either via bootloader
> or devicetree, or use an initramfs.
> 
> I can understand that OpenWrt/LEDE sometimes has to start from a
> hostile bootloader which doesn't let you changing the cmdline.
> But you can still set (and override) it either using CONFIG_CMDLINE or
> in your device tree.
> For advanced booting you can also use a inittamfs.
> 
> So, what do I miss?
> 
> Thanks,
> //richard

Using CONFIG_CMDLINE or the dtb isn't an option either for dual firmware
devices. You'd have to provide two images, one for each partition so
the rootfs belonging to the kernel gets mounted. Sounds like a recipe
for disaster.

On the other hand an initramfs can carry the logic to figure out which
to mount and is what I use for my self. The busybox based implementation
I use adds a tad over 300Kb to the uImage, perfectly acceptable in my
case.

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

Re: [OpenWrt-Devel] [PATCH v2 0/2] kernel: add kmod-ubi and kmod-fs-ubifs

[Ralph Sennhauser]

On Fri, 26 Aug 2016 15:05:58 +0200
Daniel Golle  wrote:

> Hi Ralph,
> 
> the use of global variable ROOT_DEV is not guarded properly in the
> patch auto-creating a ubiblock though this code needs to be
> prevented from running when built as a module.
> Please try rebuilding with the patch attached, if it resolves the
> issue I'll commit a proper fix for that on LEDE's source.git
> 
> Cheers
> 
> Daniel
> 

Hi Daniel,

I added the same guard to
493-ubi-set-ROOT_DEV-to-ubiblock-rootfs-if-unset.patch which then
allowed me to get the x86 image built.

So once committed I reset and resend my mini series including the
config update.

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

Re: [OpenWrt-Devel] [PATCH v2 0/2] kernel: add kmod-ubi and kmod-fs-ubifs

[Ralph Sennhauser]

Hi Daniel,

On Fri, 26 Aug 2016 15:05:58 +0200
Daniel Golle <dan...@makrotopia.org> wrote:

> Hi Ralph,
> 
> the use of global variable ROOT_DEV is not guarded properly in the
> patch auto-creating a ubiblock though this code needs to be
> prevented from running when built as a module.
> Please try rebuilding with the patch attached, if it resolves the
> issue I'll commit a proper fix for that on LEDE's source.git
> 

thanks for looking into it that fast, will give the patch a try later
today and report back.

May I ask you why you do no handle setting ROOT_DEV in init/do_mounts
instead of ubi/block? It isn't immediately obvious to me.

Cheers
Ralph

> Cheers
> 
> Daniel
> 
> On Fri, Aug 26, 2016 at 11:46:05AM +0200, Ralph Sennhauser wrote:
> > On Thu, 25 Aug 2016 12:53:41 +0200
> > Ralph Sennhauser <ralph.sennhau...@gmail.com> wrote:
> >   
> > > Hi Zoltan,
> > > 
> > > On Thu, 25 Aug 2016 07:40:56 +0200
> > > Zoltan HERPAI <wigy...@uid0.hu> wrote:
> > >   
> > > > Daniel Golle wrote:
> > > > > On Wed, Aug 24, 2016 at 11:28:40PM +0200, Zoltan HERPAI wrote:
> > > > > 
> > > > >> Ralph Sennhauser wrote:
> > > > >>   
> > > > >>> I use kmod-ubi for creating a block device from the squasfs
> > > > >>> using module parameters as there is no busybox ubiblock
> > > > >>> applet yet. If ubi is made available as module so obvioulsy
> > > > >>> should ubifs.
> > > > >>>
> > > > >>> This completes the addition of kmod-fs-squashfs in commit
> > > > >>> 5163389b9c3b302a0d53df9a70294da5cbc08ada
> > > > >>>
> > > > >>> --
> > > > >>> V2: kmod-ubifs -> kmod-fs-ubifs in commit message
> > > > >>> 
> > > > >> Hi Ralph,
> > > > >>
> > > > >> With this configuration, these packages will try to get
> > > > >> built on targets where UBI support is not available, and
> > > > >> failing those builds due to the missing UBI config symbols.
> > > > >> Can you try to make these packages depend on the ubifs
> > > > >> feature ? 
> > > > >
> > > > > Well, I reckon on most if not all targets with 'ubifs' feature
> > > > > set, UBI and UBIFS is built-in the kernel anyway...
> > > > > 
> > > > True - there still are a couple config variables need to be
> > > > taken care of.
> > > > 
> > > > -w-
> > > > 
> > > 
> > > Slipped my mind that there are config updates needed for targets
> > > not yet enabling ubi/ubifs. Will send a fixed series later.
> > > 
> > > Thanks to you and Daniel for the review.
> > > 
> > > Cheers
> > > Ralph  
> > 
> > While it shouldn't be an issue to build those packages for any
> > targets this is currently broken due to
> > CONFIG_MTD_ROOTFS_ROOT_DEV=y. Unsetting allows to build for x86 for
> > example, i.e get past modposts ROOT_DEV unset! for ubi.ko
> > 
> > Haven't had a chance to look into how to tackle this issue. Fixing
> > the openwrt patches (which are supposed to be dropped ;)) or making
> > CONFIG_MTD_ROOTFS_ROOT_DEV opt-in or a third solution I haven't
> > thought up yet.
> > 
> > Anyway just adding the missing config symbols isn't enough.
> > 
> > Cheers
> > Ralph  
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2 0/2] kernel: add kmod-ubi and kmod-fs-ubifs

[Ralph Sennhauser]

On Thu, 25 Aug 2016 12:53:41 +0200
Ralph Sennhauser <ralph.sennhau...@gmail.com> wrote:

> Hi Zoltan,
> 
> On Thu, 25 Aug 2016 07:40:56 +0200
> Zoltan HERPAI <wigy...@uid0.hu> wrote:
> 
> > Daniel Golle wrote:  
> > > On Wed, Aug 24, 2016 at 11:28:40PM +0200, Zoltan HERPAI wrote:
> > >   
> > >> Ralph Sennhauser wrote:
> > >> 
> > >>> I use kmod-ubi for creating a block device from the squasfs
> > >>> using module parameters as there is no busybox ubiblock applet
> > >>> yet. If ubi is made available as module so obvioulsy should
> > >>> ubifs.
> > >>>
> > >>> This completes the addition of kmod-fs-squashfs in commit
> > >>> 5163389b9c3b302a0d53df9a70294da5cbc08ada
> > >>>
> > >>> --
> > >>> V2: kmod-ubifs -> kmod-fs-ubifs in commit message
> > >>>   
> > >> Hi Ralph,
> > >>
> > >> With this configuration, these packages will try to get built on
> > >> targets where UBI support is not available, and failing those
> > >> builds due to the missing UBI config symbols. Can you try to make
> > >> these packages depend on the ubifs feature ?
> > >> 
> > >
> > > Well, I reckon on most if not all targets with 'ubifs' feature
> > > set, UBI and UBIFS is built-in the kernel anyway...
> > >   
> > True - there still are a couple config variables need to be taken
> > care of.
> > 
> > -w-
> >   
> 
> Slipped my mind that there are config updates needed for targets not
> yet enabling ubi/ubifs. Will send a fixed series later.
> 
> Thanks to you and Daniel for the review.
> 
> Cheers
> Ralph

While it shouldn't be an issue to build those packages for any targets
this is currently broken due to CONFIG_MTD_ROOTFS_ROOT_DEV=y. Unsetting
allows to build for x86 for example, i.e get past modposts ROOT_DEV
unset! for ubi.ko

Haven't had a chance to look into how to tackle this issue. Fixing the
openwrt patches (which are supposed to be dropped ;)) or making
CONFIG_MTD_ROOTFS_ROOT_DEV opt-in or a third solution I haven't thought
up yet.

Anyway just adding the missing config symbols isn't enough.

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

Re: [OpenWrt-Devel] [PATCH v2 0/2] kernel: add kmod-ubi and kmod-fs-ubifs

[Ralph Sennhauser]

On Thu, 25 Aug 2016 13:07:43 +0200
Daniel Golle <dan...@makrotopia.org> wrote:

> On Thu, Aug 25, 2016 at 12:50:59PM +0200, Ralph Sennhauser wrote:
> > Hi Daniel,
> > 
> > On Thu, 25 Aug 2016 10:53:34 +0200
> > Daniel Golle <dan...@makrotopia.org> wrote:
> > 
> > [snip]
> >   
> > > Are you planning to switch to initramfs and then load the ubi and
> > > ubifs modules in order to get a persistent rootfs?!
> > > Remember that otherwise, these modules are needed to be built-in
> > > to the kernel in order to mount the rootfs during boot.  
> > 
> > I use an initramfs to mount root indeed. This is just an
> > alternative to 7 patches in generic and mvebu to do the same.
> > 
> > The kernel partition is 6MB, so there is plenty space and using
> > busybox works fine except there is no ubiblock applet. To work
> > around this I build ubi as a module instead of built-in and use
> > module parameter to create a blockdevice from the squashfs volume
> > for use by the overlayfs.  
> 
> Does the memory used for the initramfs get freed once you switched to
> the 'real' rootfs? If so, this would indeed be a quite good
> alternative to the current way and also provide other pre-init
> features such as failsafe-mode.
> 

If you clean up properly before switch_root it won't take up any space,
that's a property of tmpfs, but you might find use for keeping it
populated anyway.

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

Re: [OpenWrt-Devel] [PATCH v2 0/2] kernel: add kmod-ubi and kmod-fs-ubifs

[Ralph Sennhauser]

Hi Zoltan,

On Thu, 25 Aug 2016 07:40:56 +0200
Zoltan HERPAI <wigy...@uid0.hu> wrote:

> Daniel Golle wrote:
> > On Wed, Aug 24, 2016 at 11:28:40PM +0200, Zoltan HERPAI wrote:
> > 
> >> Ralph Sennhauser wrote:
> >>   
> >>> I use kmod-ubi for creating a block device from the squasfs using
> >>> module parameters as there is no busybox ubiblock applet yet. If
> >>> ubi is made available as module so obvioulsy should ubifs.
> >>>
> >>> This completes the addition of kmod-fs-squashfs in commit
> >>> 5163389b9c3b302a0d53df9a70294da5cbc08ada
> >>>
> >>> --
> >>> V2: kmod-ubifs -> kmod-fs-ubifs in commit message
> >>> 
> >> Hi Ralph,
> >>
> >> With this configuration, these packages will try to get built on
> >> targets where UBI support is not available, and failing those
> >> builds due to the missing UBI config symbols. Can you try to make
> >> these packages depend on the ubifs feature ?
> >>   
> >
> > Well, I reckon on most if not all targets with 'ubifs' feature set,
> > UBI and UBIFS is built-in the kernel anyway...
> > 
> True - there still are a couple config variables need to be taken
> care of.
> 
> -w-
> 

Slipped my mind that there are config updates needed for targets not yet
enabling ubi/ubifs. Will send a fixed series later.

Thanks to you and Daniel for the review.

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

[OpenWrt-Devel] [PATCH] strace: bump to 4.13

[Ralph Sennhauser]

Fixes broken btrfs support in 4.12

Signed-off-by: Ralph Sennhauser <ralph.sennhau...@gmail.com>
---
 package/devel/strace/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/package/devel/strace/Makefile b/package/devel/strace/Makefile
index 6d9a7be..688f403 100644
--- a/package/devel/strace/Makefile
+++ b/package/devel/strace/Makefile
@@ -1,5 +1,5 @@
 #
-# Copyright (C) 2006-2012 OpenWrt.org
+# Copyright (C) 2006-2016 OpenWrt.org
 #
 # This is free software, licensed under the GNU General Public License v2.
 # See /LICENSE for more information.
@@ -10,9 +10,9 @@ include $(INCLUDE_DIR)/kernel.mk
 
 PKG_NAME:=strace
 
-PKG_VERSION:=4.12
+PKG_VERSION:=4.13
 PKG_RELEASE:=1
-PKG_MD5SUM:=efb8611fc332e71ec419c53f59faa93e
+PKG_MD5SUM:=4b78c7febdd24c79d5147824d1a080a3
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 PKG_SOURCE_URL:=@SF/$(PKG_NAME)
-- 
2.7.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] perf: drop sched_getcpu wrapper

[Ralph Sennhauser]

Current musl already provides sched_getcpu

Signed-off-by: Ralph Sennhauser <ralph.sennhau...@gmail.com>
---
 package/devel/perf/musl-compat.h | 17 -
 1 file changed, 17 deletions(-)

diff --git a/package/devel/perf/musl-compat.h b/package/devel/perf/musl-compat.h
index 8ce97be..83aa00a 100644
--- a/package/devel/perf/musl-compat.h
+++ b/package/devel/perf/musl-compat.h
@@ -7,7 +7,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #undef _IOWR
 #undef _IOR
@@ -40,21 +39,5 @@ static inline long sysconf_wrap(int name)
 
 #define sysconf(_n) sysconf_wrap(_n)
 
-static inline int compat_sched_getcpu(void)
-{
-#ifdef __NR_getcpu
-   unsigned int val;
-
-   if (syscall(__NR_getcpu, ))
-   return -1;
-
-   return val;
-#else
-   return -1;
-#endif
-}
-
-#define sched_getcpu compat_sched_getcpu
-
 #endif
 #endif
-- 
2.7.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] perf: fix automagic libcrypto dependency

[Ralph Sennhauser]

Signed-off-by: Ralph Sennhauser <ralph.sennhau...@gmail.com>
---
 package/devel/perf/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/devel/perf/Makefile b/package/devel/perf/Makefile
index ec4e3c2..0ec2bba 100644
--- a/package/devel/perf/Makefile
+++ b/package/devel/perf/Makefile
@@ -49,6 +49,7 @@ MAKE_FLAGS = \
NO_LIBNUMA=1 \
NO_GTK2=1 \
NO_LIBAUDIT=1 \
+   NO_LIBCRYPTO=1 \
CROSS_COMPILE="$(TARGET_CROSS)" \
CC="$(TARGET_CC)" \
LD="$(TARGET_CROSS)ld" \
-- 
2.7.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2 2/2] kernel: add kmod-fs-ubifs

[Ralph Sennhauser]

Signed-off-by: Ralph Sennhauser <ralph.sennhau...@gmail.com>
---
 package/kernel/linux/modules/fs.mk | 17 +
 1 file changed, 17 insertions(+)

diff --git a/package/kernel/linux/modules/fs.mk 
b/package/kernel/linux/modules/fs.mk
index bb9ecc4..8fe4473 100644
--- a/package/kernel/linux/modules/fs.mk
+++ b/package/kernel/linux/modules/fs.mk
@@ -436,6 +436,23 @@ endef
 $(eval $(call KernelPackage,fs-squashfs))
 
 
+define KernelPackage/fs-ubifs
+  SUBMENU:=$(FS_MENU)
+  TITLE:=UBIFS file system support
+  KCONFIG:=CONFIG_UBIFS_FS
+  FILES:=$(LINUX_DIR)/fs/ubifs/ubifs.ko
+  AUTOLOAD:=$(call AutoLoad,30,ubifs,1)
+  DEPENDS:=+kmod-ubi
+  $(call AddDepends/nls)
+endef
+
+define KernelPackage/fs-ubifs/description
+ UBIFS is a file system for flash devices which works on top of UBI.
+endef
+
+$(eval $(call KernelPackage,fs-ubifs))
+
+
 define KernelPackage/fs-udf
   SUBMENU:=$(FS_MENU)
   TITLE:=UDF filesystem support
-- 
2.7.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2 1/2] kernel: add kmod-ubi

[Ralph Sennhauser]

Signed-off-by: Ralph Sennhauser <ralph.sennhau...@gmail.com>
---
 package/kernel/linux/modules/block.mk | 21 +
 1 file changed, 21 insertions(+)

diff --git a/package/kernel/linux/modules/block.mk 
b/package/kernel/linux/modules/block.mk
index d7f5ca4..99ace6c 100644
--- a/package/kernel/linux/modules/block.mk
+++ b/package/kernel/linux/modules/block.mk
@@ -579,6 +579,27 @@ endef
 $(eval $(call KernelPackage,nbd))
 
 
+define KernelPackage/ubi
+  SUBMENU:=$(BLOCK_MENU)
+  TITLE:=Unsorted block images
+  KCONFIG:= \
+   CONFIG_MTD_UBI \
+   CONFIG_MTD_UBI_BLOCK=y
+  FILES:=$(LINUX_DIR)/drivers/mtd/ubi/ubi.ko
+  AUTOLOAD:=$(call AutoLoad,30,ubi,1)
+endef
+
+define KernelPackage/ubi/description
+ UBI is a software layer above MTD layer which admits of LVM-like
+ logical volumes on top of MTD devices, hides some complexities of
+ flash chips like wear and bad blocks and provides some other useful
+ capabilities. Please, consult the MTD web site for more details
+ (www.linux-mtd.infradead.org).
+endef
+
+$(eval $(call KernelPackage,ubi))
+
+
 define KernelPackage/scsi-core
   SUBMENU:=$(BLOCK_MENU)
   TITLE:=SCSI device support
-- 
2.7.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2 0/2] kernel: add kmod-ubi and kmod-fs-ubifs

[Ralph Sennhauser]

I use kmod-ubi for creating a block device from the squasfs using module
parameters as there is no busybox ubiblock applet yet. If ubi is made
available as module so obvioulsy should ubifs.

This completes the addition of kmod-fs-squashfs in commit
5163389b9c3b302a0d53df9a70294da5cbc08ada

--
V2: kmod-ubifs -> kmod-fs-ubifs in commit message

Ralph Sennhauser (2):
  kernel: add kmod-ubi
  kernel: add kmod-fs-ubifs

 package/kernel/linux/modules/block.mk | 21 +
 package/kernel/linux/modules/fs.mk| 17 +
 2 files changed, 38 insertions(+)

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

[OpenWrt-Devel] [PATCH 2/2] kernel: add kmod-ubifs

[Ralph Sennhauser]

Signed-off-by: Ralph Sennhauser <ralph.sennhau...@gmail.com>
---
 package/kernel/linux/modules/fs.mk | 17 +
 1 file changed, 17 insertions(+)

diff --git a/package/kernel/linux/modules/fs.mk 
b/package/kernel/linux/modules/fs.mk
index bb9ecc4..8fe4473 100644
--- a/package/kernel/linux/modules/fs.mk
+++ b/package/kernel/linux/modules/fs.mk
@@ -436,6 +436,23 @@ endef
 $(eval $(call KernelPackage,fs-squashfs))
 
 
+define KernelPackage/fs-ubifs
+  SUBMENU:=$(FS_MENU)
+  TITLE:=UBIFS file system support
+  KCONFIG:=CONFIG_UBIFS_FS
+  FILES:=$(LINUX_DIR)/fs/ubifs/ubifs.ko
+  AUTOLOAD:=$(call AutoLoad,30,ubifs,1)
+  DEPENDS:=+kmod-ubi
+  $(call AddDepends/nls)
+endef
+
+define KernelPackage/fs-ubifs/description
+ UBIFS is a file system for flash devices which works on top of UBI.
+endef
+
+$(eval $(call KernelPackage,fs-ubifs))
+
+
 define KernelPackage/fs-udf
   SUBMENU:=$(FS_MENU)
   TITLE:=UDF filesystem support
-- 
2.7.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 0/2] kernel: add kmod-ubi and kmod-ubifs

[Ralph Sennhauser]

I use kmod-ubi for creating a block device from the squasfs as there
is no busybox ubiblock applet yet. If ubi is made available as module
so obvioulsy should ubifs.

This completes the addition of kmod-squashfs in commit
5163389b9c3b302a0d53df9a70294da5cbc08ada

--

Ralph Sennhauser (2):
  kernel: add kmod-ubi
  kernel: add kmod-ubifs

 package/kernel/linux/modules/block.mk | 21 +
 package/kernel/linux/modules/fs.mk| 17 +
 2 files changed, 38 insertions(+)

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

[OpenWrt-Devel] [PATCH 1/2] kernel: add kmod-ubi

[Ralph Sennhauser]

Signed-off-by: Ralph Sennhauser <ralph.sennhau...@gmail.com>
---
 package/kernel/linux/modules/block.mk | 21 +
 1 file changed, 21 insertions(+)

diff --git a/package/kernel/linux/modules/block.mk 
b/package/kernel/linux/modules/block.mk
index d7f5ca4..99ace6c 100644
--- a/package/kernel/linux/modules/block.mk
+++ b/package/kernel/linux/modules/block.mk
@@ -579,6 +579,27 @@ endef
 $(eval $(call KernelPackage,nbd))
 
 
+define KernelPackage/ubi
+  SUBMENU:=$(BLOCK_MENU)
+  TITLE:=Unsorted block images
+  KCONFIG:= \
+   CONFIG_MTD_UBI \
+   CONFIG_MTD_UBI_BLOCK=y
+  FILES:=$(LINUX_DIR)/drivers/mtd/ubi/ubi.ko
+  AUTOLOAD:=$(call AutoLoad,30,ubi,1)
+endef
+
+define KernelPackage/ubi/description
+ UBI is a software layer above MTD layer which admits of LVM-like
+ logical volumes on top of MTD devices, hides some complexities of
+ flash chips like wear and bad blocks and provides some other useful
+ capabilities. Please, consult the MTD web site for more details
+ (www.linux-mtd.infradead.org).
+endef
+
+$(eval $(call KernelPackage,ubi))
+
+
 define KernelPackage/scsi-core
   SUBMENU:=$(BLOCK_MENU)
   TITLE:=SCSI device support
-- 
2.7.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel