[OpenWrt-Devel] Opensource users asking for code on a github account you censored
https://forum.openwrt.org/viewtopic.php?pid=340239#p340239 Look at that. It implies github doesn't support open-source. They support gay marriage activists having sex with 22 month old Russian infant instead. Restore my account before I do massive damage to your PR Luke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] tdestroy in musl works differently to glibc?
Slowly getting the accel-pppd package done...
Lots of missing headers, as their usually are with musl vs glibc and a
problem relating to atomic memory ops are already fixed as openwrt
people bumped into the same issue with rtorrent.
https://github.com/rakshasa/rtorrent/issues/156
error: '__free_fn_t' undeclared (first use in this function)
that's used with tdestroy (search.h) with glibc, where's
the docs on tdestroy with musl?
Other's have run into this:
http://www.openwall.com/lists/musl/2014/09/09/5
http://fossies.org/dox/musl-1.1.15/tdestroy_8c.html
vs
http://www.delorie.com/gnu/docs/glibc/libc_146.html
Normally I'd spend some more time trying to patch alone. Already got 3
down and 67% of it building.
TARGET_CFLAGS+= -D_GNU_SOURCE and __free_fn_t still isn't declared.
Alsa-lib has it's own bundled include/search.h that includes the
necessary typedef __free_fn_t
#ifdef __USE_GNU
/* Callback type for function to free a tree node. If the keys are atomic
data this function should do nothing. */
typedef void (*__free_fn_t) __PMT ((void *__nodep));
/* Destroy the whole tree, call FREEFCT for each node or leaf. */
extern void tdestroy __PMT ((void *__root, __free_fn_t __freefct));
#endif
This is the code needing fixing:
static void l2tp_tunnel_free_sessions(struct l2tp_conn_t *conn)
{
void *sessions = conn->sessions;
conn->sessions = NULL;
tdestroy(sessions, (__free_fn_t)l2tp_session_free);
/* Let l2tp_session_free() handle the session counter and
* the reference held by the tunnel.
*/
}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] fix include/cmake.mk so it allows out of source tree builds
If you change PKG_BUILD_DIR it could work - but then you can't patch the source directory. https://github.com/openwrt/openwrt/pull/41 Some packages need out of source tree building with cmake, for example when building kernel modules. See an example here: https://sourceforge.net/p/accel-ppp/code/ci/master/tree/README This adds a new variable that can be used in Makefiles $(CMAKE_BINARY_DIR) Signed-off-by: Luke McKee hojur...@gmail.com @nbd168 agrees, patching the include is the only way to go. This also needs to get merged into LEDE or a new package I'm working on accel-ppp (give me a week of testing etc) won't work. diff --git a/include/cmake.mk b/include/cmake.mk index 009c6c2..d75b3ef 100644 --- a/include/cmake.mk +++ b/include/cmake.mk @@ -6,7 +6,8 @@ ifneq ($(findstring c,$(OPENWRT_VERBOSE)),) MAKE_FLAGS+=VERBOSE=1 endif -CMAKE_SOURCE_DIR:=. +CMAKE_BINARY_DIR?=$(PKG_BUILD_DIR) +CMAKE_SOURCE_DIR?=. ifeq ($(CONFIG_EXTERNAL_TOOLCHAIN),) cmake_tool=$(TOOLCHAIN_DIR)/bin/$(1) @@ -35,7 +36,7 @@ CMAKE_HOST_FIND_ROOT_PATH:=$(STAGING_DIR)/host;$(STAGING_DIR_HOST) CMAKE_SHARED_LDFLAGS:=-Wl,-Bsymbolic-functions define Build/Configure/Default - (cd $(PKG_BUILD_DIR); \ + (cd $(CMAKE_BINARY_DIR); \ CFLAGS="$(TARGET_CFLAGS) $(EXTRA_CFLAGS)" \ CXXFLAGS="$(TARGET_CFLAGS) $(EXTRA_CFLAGS)" \ LDFLAGS="$(TARGET_LDFLAGS) $(EXTRA_LDFLAGS)" \ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] pppd: Someone please fix the Makefile to install net/pppd_defs.h so my pull request for rp-pppoe can go through
https://github.com/openwrt/packages/pull/2974 Attention @jow- @champtar Also users with historical interest with rp-pppoe http://git.openwrt.org/?p=packages.git;a=history;f=net/rp-pppoe;h=c4c326bf49614aa8ef4ef224b747af01100ef242;hb=HEAD @hauke @nbd168 Quote: 6bcfc3a For this package to compile, it just needs openwrt pppd to install net/ppp_defs.h into the staging area that requires a small modification to package pppd Makefile openwrt/openwrt@5de3ef3 < i.e. this change to pppd Makefile : https://github.com/openwrt/openwrt/commit/5de3ef3 > from pull request: openwrt/openwrt#15 Could the package maintainer please expedite this, as @jow said every package should copy the file from pppd and patch it in which is just insane. rp-pppoe is not recommended for production environments nearly everone on the internet as an access concentrator, but it's better than nothing (what openwrt has now). In the near future I'll also try to merge accel-ppp, that is much better as it supports snmp, doesn't fork pppd processes and is completely kernel mode only. Changes made. 1) Stopped building installing the pppoe client (usermode) & rp-pppoe.so as it's already provided by pppd to prevent conflicts. 2) Did a fix for musl 1.1 compatibility inspired by: e76f394 3) Saw a very large free memory limit hardcoded into rp-pppoe that was ignored if you bought the commercial verison. Lowered it to a more conservative value considering musl apps compiled with -Os 3) Saw a very large free memory limit hardcoded into rp-pppoe that was ignored if you bought the commercial verison. Lowered it to a more conserative value considering musl apps compiled with -Os 3) Saw a very large free memory limit hard-coded into rp-pppoe that was ignored if you bought the commercial verison. Lowered it to a more conserative value considering compiling with musl & -Os have much less memory demands 4) changed the default options 5) Overrode configure to use the already installed rp-pppoe.so, the location of this library and even the mtu 1492 (if larger than 1500 is set) is hardcoded in the pppoe-server binary There is no uci or procd init scripts support yet. Most people wont want this and will use their own ppp if-up/down scripts to manage how their want their PPPOE access concentrator set up. If there is demand for this I will do it, if I get package maintainer status for this one. Compile-tested: Openwrt Buildroot, gcc 5.0, fortify, RELRO, SSP conserative Run-Tested: Not yet, but great care was taken the package was configured correctly reviewing the source, config.h and the defines. You may leave the pull request open until my testing is complete. I rather just get it out there now the minority of openwrt users who are interested in using this. Signed-off-by: Luke McKee hojur...@gmail.com https://dev.openwrt.org/ticket/21350 Seven months ago someone nagged for this to be fixed. That makes only two people that want this :) >Changed 7 months ago by @nbd168 >Resolution set to wontfix >Status changed from new to closed >rp-pppoe is unmaintained, no changes will be made until it is cleaned up and >submitted to the github repo. DONE. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] ar71xx: add tp-link 841nd-v9-vn board - 8mbit flash isp oem variant
https://github.com/openwrt/openwrt/pull/29 https://github.com/openwrt/openwrt/pull/29/commits/84c616f66390230a2938f8db691e8093f1669ec2 Please see the commit message or the forum. This has been run-tested on the new hardware which is basically the same as a v9 board just with the larger flash size https://forum.openwrt.org/viewtopic.php?id=65786 Users can install factory.bin's via tp-link firmware, or use sysupgrade - both tested successfully. As you can see from the factory rom extracted via uboot, it really does have different HWID's used by tp-link to distinguish the OEM order for larger flash size. They add a 1 at the end of the HWID to denote that. If a user bricks a tp-link 841nd v9 , the factory bootloader has a tftp recovery method as demonstrated. In any case -v9-vn firmware will not install on -v9 firwmare and visa versa. There isn't much need for pico''s patched u-boot I think, except for the frills of a web-browser to upgrade the flash and loosing your Ethernet mac address. https://www.youtube.com/watch?v=0k1sxwX5pMk ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] procd ubox jsonfilter: dev question. how to properly handle interface changes per instance only in init scripts
https://github.com/hojuruku/openwrt-packages/blob/mini_snmpd/net/mini_snmpd/files/mini_snmpd.init
any comments on the script. I'd like some feedback on how to do per
instance restarts if an interface changes.
i just updated it. its nearly done just for knowing how to
properly do per instance interface restarts so the daemons are only
reloaded if the interface they are bound to changes, whilst the other
instances are not restarted
The script is now using /sbin/validate_data / uci_validate_section()
to take configuration from uci.
You'll notice in the comments there are some issues with ash (no array
variables - not fixable)
And one with jsonfilter and the other with /sbin/validate_data not
properly handling setting default variables. Will these get upstream
fixes?
root@wifi:/etc/init.d# /etc/init.d/mini_snmpd start
{ "name": "mini_snmpd", "script": "\/etc\/init.d\/mini_snmpd",
"instances": { "instance1": { "command": [ "\/usr\/bin\/mini_snmpd",
"-n", "-c", "public", "-C", "Luke McKee ", "-t",
"2", "-a", "-d \/overlay,\/tmp", "-i loopback,lan,wan" ], "stdout":
true, "stderr": true, "respawn": [ "600", "10", "10" ] } },
"triggers": [ [ "config.change", [ "if", [ "eq", "package",
"mini_snmpd" ], [ "run_script", "\/etc\/init.d\/mini_snmpd", "reload"
] ] ] ], "validate": [ { "package": "mini_snmpd", "type":
"mini_snmpd", "data": { "enabled": "bool", "ipv6": "bool", "debug":
"bool", "auth": "bool", "community": "rangelength(1,32)", "contact":
"maxlength(255)", "location": "maxlength(255)", "listen_interface":
"(uciname)", "udp_port": "port", "tcp_port": "port", "vendor_oid":
"string", "mib_timeout": "and(min(1),uinteger)", "disks":
"list(directory)", "interfaces": "list(uciname)" } } ] }
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH] netifd: remove wireless device when device fails to setup
The I think said patch would break scripts that see what devices are available as in CONFIGURED, and set up procd triggers to reload when the device is fixed or comes back online and gets given an IP address. If DFS pulls down a wifi then it should change ubus interface state to down, not remove the whole interface from ubus. E.g. the mini_upnpd script I wrote or sysntpd script from busybox. https://github.com/hojuruku/openwrt-packages/blob/mini_snmpd/net/mini_snmpd/files/mini_snmpd.init https://lists.openwrt.org/pipermail/openwrt-devel/2016-July/041930.html Many init scripts may need to be rewritten if this patch is accepted, to use uci instead of ubus / jsonfilter (used by default for network_ functions now too in /lib/functions which means 95% of all init scripts) to see if an interface is CONFIGURED - not up. On 2016-07-01 11:50, Eduardo Abinader wrote: > Hi Felix, > > 1) Just set a non-allowed DFS channel for DE, for instance. > 2) Enable wireless; it fails > 3) Change to a valid channel; the wdev is not set up. > > There is also a leftover on /etc/init.d/network reload. > I think it should call /sbin/wifi instead of /sbin/wifi reload. No, it should not. /sbin/wifi restarts wireless unconditionally, whereas wifi reload only restarts if the configuration changed. I understand the issue now, but in my opinion this fix is not correct. It eliminates the state of the wireless device entirely, thus not giving the user the chance to see that netifd failed to bring it up. I think the main issue is the handling of the autostart flag and its multiple uses. It gets used to prevent auto-restart after error, but it is also used to indicate that the user wanted to shut down the wireless interface. I think for the error case we need to leave autostart alone and use a separate flag (which gets cleared if the configuration gets updated). That way the state would be preserved and a restart would be triggered on actual config changes. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] coova-chilli: Fix UCI parse error
I'm interested in coova chilli too I will be making use of it again soon like I did 3/6 years ago :) There is a pull request to update it to the latest version: https://github.com/openwrt/packages/pull/2737/commits/f3898d3e2be47c414882b93d8f54e7bd919c4628 Previous message (by thread): On Wed, Jul 06, 2016 at 07:03:43PM +0530, Rajan Vaja wrote: > UCI commands report errors in parsing coova-chilli > sample configuration file. Fix this issue by using > proper format in configuration. This package is maintained in the openwrt-packages Github repository: https://github.com/openwrt/packages/tree/master/net/coova-chilli So, you should send a pull request there. Baptiste ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] mini_snmpd: coming back to openwrt soon & other matters
Hey Devs, mini_snmpd went to oldpackages because the original developer's page went offline a few years ago, however it's been taken up by a new maintainer who's implemented all the previous 1.2b openwrt patches in a more ingenious way. The other fork isn't worth considering. http://troglobit.github.io/mini-snmpd.html Here's my first attempt at writing a procd init script that isn't properly documented on openwrt or lede, both marked WIP. https://wiki.openwrt.org/inbox/procd-init-scripts https://www.lede-project.org/docs/procd.html https://github.com/hojuruku/openwrt-packages/blob/mini_snmpd/net/mini_snmpd/files/mini_snmpd.init The script uses all the features of mini_snmpd unlike the old one and can even be bound to a dynamic interface like a ppp link and restart as needed. Also shellcheck.net is awesome! Some questions I still have outstanding before I do the pull request, I asked on lede-dev but nobody answered because I outed myself as someone who doesn't support gay marriage then got banned for taking the bait when a few pushed on the issue and said it's homophobic to critize my family's persecution by the mafia. I won't spout my story, but here's my fathers http://truthnews.com.au/web/radio/story/cultural_marxism_101 2nd hour. Mine involves never seeing my first born child due to the actions of a now convicted gay pedophile police officer (see videos on http://youtube.com/hojuruku) Speaking of bait I only went to #lede-dev because there are people on FreeNode #openwrt all day long like plntk that are constantly poaching openwrt users and saying they need to run lede trunk to solve all their wifi troubles. Also with Lede-devs trying turn a offer for hosting into a offer for 2TB of space or more for a continuous integration compute cluster things might be getting interesting soon. If it wasn't for IRC I wouldn't have tried it. Skyrider: well - the last comment refers to lede (an openwrt fork/spinoff) -you can see the progress at https://lede-project.org/ - the wireless drivers recently changed again (in the last week) - and since that unit is new I would advise to use a trunk/snapshot image and then report if you have issues My two cents on the split is openwrt.org should put someone full time like ffmpeg vs libav with the same problem did constantly merging in all of lede's changes + all openwrt changes. After alot of work the rival will eventually be put to bed by their parent. I know libav will be. It's in sabayon they are considering removing it and going back soon. OK now those init script questions for Crispin or anyone else who knows procd 1) should I use logger in procd or does procd have some other way of logging messages from init scripts? echo is good? 2) Is there any real benefit to doing a #procd_add_validation validate_section_mini_snmpd? What's it for? Luci uses it? More info please? 3) No documentation on seccomp apart from a LKML post, need more. mini_snmpd could do with a patch to run as nobody after binding to the interface, but would that work? can it stat the filesystem free space if it doesn't have access to the mountpoint? 4) I might have found a strange bug with jsonfilter. It's adding whitespaces to variable results it returns it can break things: https://github.com/troglobit/mini-snmpd/issues/4 5) anything else wrong with the script before I add the validation code (needs documentation) and do the pull request? To make my pppoe lan party trend take off in Vietnam thanks to lax security on the fibre GPONs - all I need to do is fix rp-ppoe (again another oldpackages) and get some VN special openwrt TP-LINK OEM modified routers working. If anyone has experience adding new TP-Link routers to openwrt you can get the split factory firmware (not available for download on their website). Also how may I go about petitioning TP-Link to give me some OEM only firmware. Apart from a single white sticker on the box it came in it looks exactly like a regular TP-Link 841nd v9.2 - just different flash I think. https://forum.openwrt.org/viewtopic.php?pid=330161#p330161 Cheers, Luke i got the got tghe init script going. Is there any benefit or reason for having procd do uci validation. Would the luci folks want that? procd has no developer documentation so it was fun working it out. here's the code https://github.com/hojuruku/openwrt-packages/blob/mini_snmpd/net/mini_snmpd/files/mini_snmpd.init i don't know what is the point what is your chances of taking a pull request when I'm done. the lede guys hate me because i disrespected those who abuse infants. it would be funny if blogic was just like the guy who created systemd :P oh sorry. you were discussing non lede related things in public irc and you were asked to stop but did continue after you bring it up. yeah who cares if i'm in the same boat as snowden and assange. no big deal. i bet those two guys better shut their gobs too http://bit.ly/aurefugee2 - UNHCR confirmed political refugee. the channel is a developer c
[OpenWrt-Devel] [RFD] Future - suggestion for the teleconference
Suggestion for the teleconference: Talkshoe.com Talkshoe is free. It has a web client too with a chat log when the conference call starts. Someone make an account. It's got SIP and a US number. That way nobody get's everyone ease's IP addresses and nobody can play funny buggers with a firewall to make people miss the meeting. Someone from LEDE should be the MC seeing they don't block/ban/mute peoples.. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] procd: patch to support busybox mkfs.ext2
m.storchak at gmail dot com wrote:
Is there a reason to use full path specification? Why can't
mkfs.ext{2|4} be called and whichever is found first in PATH gets
executed? In this case only one of e2fsprogs and busybox implementations
should be required. Let busybox be default, but please leave an option
to use full e2fsprogs and disable mkfs.ext* in busybox.
Something like DEPENDS:= ... +!BUSYBOX_CONFIG_MKFS_EXT2:e2fsprogs
Oh for the love of god. I'm fixing something that's in my opinion
completely useless for 90% of the openwrt market due to size constraints to put
libext2fs and e2fsprogs in rootfs and can't be used as is.
Look at a technical level zram-swap works better, so as far as I'm concerned
roll back this whole d$#$ feature. It's a niche market for those who want to
have scripts to opkg -d ram install stuff and updated their profile to include
LD_LIBRARY_PATH=/tmp/lib:/tmp/usr/lib or reconfigured their overlayfs.
Addressing your concerns:
1) If you format with mkfs.ext4 you have the added overhead of writing to the
ram twice for a journal, you don't need because it's in ram. So #1 we won't be
calling mkfs.ext4, and as someone else suggested we won't call tune2fs because
busybox doesn't support trimming ext4 features like someone else said.
2) Your second point:
DEPENDS work like that for packages, but I'm not sure if they work in
define Package/procd/config
stanzas - for the second time.
so I passed the buck to the maintainer who's job is to do the Makefile.
Depends for Package/xyz/config is undocumented at openwrt dev dogs.
3) I'm not a C programmer but I RTFM
http://linux.die.net/man/2/execve,
You've got to fork before you can run another process, unix semantics.
So now your proposed mod asks the patch to adds all this unnecessary crap to
see first see files exist and they are executable.
Bash scans the path for you - C doesn't. We'll if you really really want to use
the bloat ware in rootfs image, then this patch will work, without busybox's
20k mkfs.ext2. Ext2 uses 7k ram (compressed). The journal is going to add
double the compression/cpu overhead too, and waste a bit of ram. You'll be
using more then 7k with ext4.
execve() also allows executable shell scripts (assuming you have the kernel
bin_fmt enabled for it)
So if you really really want to use this patch without busybox mkfs.ext2 and
use the fatter one...
put
#/bin/ash
until [ -z "$1" ]
do
MKFS_ARGS="$MKFS_ARGS $1 "
shift
done
/usr/sbin/mkfs.ext2 ${MKFS_ARGS}
In the place of /sbin/mkfs.ext2
Considering that 95% of openwrt users are consumer routers with 4-8mb flash
do we install 500k of stripped compressed code for mkfs.ext2 from e2fsprogs.
For the extra 20k busybox bloat (I h haven't measured it's 40k of source)
what's wrong with having two mkfs.ext2's if you are so obsessed with putting
bloatware in your image. Most routers aren't formatting ext4 fs. I was bitching
about using ext4 vs ext2, but relented.
Does anyone remember when openwrt ran in a 2MB image on a WRT54G?
On top of this patchwork at lede chomped up my patch for no good reason when i
used thunderbird in text mode..
http://patchwork.ozlabs.org/patch/643714/
I can see why the openwrt-devs get grumpy at working with everyone ;)
And before anyone grumbles about LZ4, I got half the upload speed using LZ4
sshing a openwrt image /tmp so LZO will be even worse (the default as it was
before this patch). 1.6MB per second.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH V3] Re: procd: patch to support busybox mkfs.ext2
ault n
prompt "Mount /tmp using zram."
endmenu
&
ifeq ($(CONFIG_PROCD_ZRAM_TMPFS_LZ4),y)
CMAKE_OPTIONS += -DZRAM_TMPFS_LZ4=1
endif
Signed-off-by: Luke McKee
--- a/initd/zram.c2016-07-03 06:39:51.01130 +0700
+++ b/initd/zram.c2016-07-03 07:00:34.143492847 +0700
@@ -82,7 +82,7 @@
int
mount_zram_on_tmp(void)
{
-char *mkfs[] = { "/usr/sbin/mkfs.ext4", "-b", "4096", "-F", "-L",
"TEMP", "-m", "0", "/dev/zram0", NULL };
+char *mkfs[] = { "/sbin/mkfs.ext2", "-b", "4096", "-F", "-L",
"TEMP", "-m", "0", "/dev/zram0", NULL };
FILE *fp;
long zramsize;
pid_t pid;
@@ -94,6 +95,15 @@
}
mkdev("*", 0600);
+#ifdef ZRAM_TMPFS_LZ4
+fp = fopen("/sys/block/zram0/comp_algorithm", "r+");
+if (fp == NULL) {
+ERROR("Can't open /sys/block/zram0/comp_algorithm: %s\n",
strerror(errno));
+return errno;
+}
+fprintf(fp, "%s", "lz4" );
+fclose(fp);
+#endif
zramsize = proc_meminfo() / 2;
fp = fopen("/sys/block/zram0/disksize", "r+");
@@ -107,10 +116,10 @@
pid = fork();
if (!pid) {
execvp(mkfs[0], mkfs);
-ERROR("Can't exec /sbin/mkfs.ext4\n");
+ERROR("Can't exec /sbin/mkfs.ext2\n");
exit(-1);
} else if (pid <= 0) {
-ERROR("Can't exec /sbin/mkfs.ext4\n");
+ERROR("Can't exec /sbin/mkfs.ext2\n");
return -1;
} else {
waitpid(pid, NULL, 0);
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] procd: patch v3 to support busybox mkfs.ext2
To quote Arjen:
If the only reason to switch to ext2 is to remove the journal, why not
just add
-O ^has_journal
to the mount options?
That's not a mount option. That's a tune2fs option.
Journaling isn't the the only problem. The biggest problem is BLOAT.
You need libext2+e2fsprogs in a 4MB flash root image with the current
zram setup.
Would someone want /tmp on zram if they had to add all this to the 4MB
squashfs image.
-rw-r--r-- 1 lmc users 199739 Jul 3 06:15 e2fsprogs_1.43.1-1_mips_24kc.ipk
-rw-r--r-- 1 lmc users 151873 Jul 3 06:15 libext2fs_1.43.1-1_mips_24kc.ipk
The simple answer is most openwrt users would say no to this feature
do to how it's implemented.
I actually was going for ext2 like the original patch, but I was sold
that ext4 can mount ext2 formatted filesystems (without a journal)
(see man ext4). The ext4 filesystem driver vs ext2 does bloat a bit,
but I don't mind it as I can mount ext4 over nbd for my extroot.
Busybox is only 40k of source including the headers. mkfs.ext4 is 360k
compressed!
https://git.busybox.net/busybox/tree/util-linux/mkfs_ext2.c
Also -O ^has_journal is an tune2fs option not a mount option. And that
tune2fs feature isn't in busybox, hence the bloat issue.
"BusyBox v1.24.2 () multi-call binary.
Usage: tune2fs [-c MAX_MOUNT_COUNT] [-i DAYS] [-C MOUNT_COUNT] [-L
LABEL] BLOCKDEV
Adjust filesystem options on ext[23] filesystems"
Busybox tune2fs is useless.
So 90% of the userbase with size constrained flash file-systems will
want to use busybox mkfs.ext2 instead. busybox mkfs.ext2 and mkfs.ext2
don't conflict because the package installs in /usr/sbin and busybox
installs in /sbin
I move that the feature be dependent ONLY on busybox mkfs.ext2.
Busybox mount isn't required because procd includes sys/mount.h
In order words set the path to /sbin/mkfs.ext2 (busybox)
Attached is the new patch. Allow users in the Makefile configuration
to choose to use LZ4 (more speed ~15% less compression) if they so
desire.
John can do the makefile if and when he merges the patch.
I'm out of the debate now, I got it in my
lede/packgaes/system/procd/patches/ directory :) I'm happy
--- a/initd/zram.c 2016-07-03 06:39:51.01130 +0700
+++ b/initd/zram.c 2016-07-03 07:00:34.143492847 +0700
@@ -82,7 +82,7 @@
int
mount_zram_on_tmp(void)
{
- char *mkfs[] = { "/usr/sbin/mkfs.ext4", "-b", "4096", "-F", "-L", "TEMP", "-m", "0", "/dev/zram0", NULL };
+ char *mkfs[] = { "/sbin/mkfs.ext2", "-b", "4096", "-F", "-L", "TEMP", "-m", "0", "/dev/zram0", NULL };
FILE *fp;
long zramsize;
pid_t pid;
@@ -94,6 +95,15 @@
}
mkdev("*", 0600);
+#ifdef ZRAM_TMPFS_LZ4
+ fp = fopen("/sys/block/zram0/comp_algorithm", "r+");
+ if (fp == NULL) {
+ ERROR("Can't open /sys/block/zram0/comp_algorithm: %s\n", strerror(errno));
+ return errno;
+ }
+ fprintf(fp, "%s", "lz4" );
+ fclose(fp);
+#endif
zramsize = proc_meminfo() / 2;
fp = fopen("/sys/block/zram0/disksize", "r+");
@@ -107,10 +116,10 @@
pid = fork();
if (!pid) {
execvp(mkfs[0], mkfs);
- ERROR("Can't exec /sbin/mkfs.ext4\n");
+ ERROR("Can't exec /sbin/mkfs.ext2\n");
exit(-1);
} else if (pid <= 0) {
- ERROR("Can't exec /sbin/mkfs.ext4\n");
+ ERROR("Can't exec /sbin/mkfs.ext2\n");
return -1;
} else {
waitpid(pid, NULL, 0);
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] procd: patch to support busybox mkfs.ext2
Actually lzo compresses better but they are both fast. lz4 is faster on embedded devices. zram-swap should use lz4 if available and the patch can be as it was.http://blog.jpountz.net/post/28092106032/wow-lz4-is-fast lz4 has compression levels. in any case, speed > size on embedded devices. interestingly enough, higher lz4 compression yields faster decompression http://www.ilsistemista.net/index.php/linux-a-unix/44-linux-compressors-comparison-on-centos-6-5-x86-64-lzo-vs-lz4-vs-gzip-vs-bzip2-vs-lzma.html?start=4 They are mostly the same. On average 2.8 compression ratio in lz4 vs 3.0 in lzo. Can't hurt to go with the fastest. On 3 July 2016 at 07:10, Luke McKee wrote: > v2 of the patch. uses lz4 compression by default. lz4 is always > installed by openwrt Makefile Config.in if zram. > > lz4 is best for compressed filesystems as we all know (if you had to > choose between that and lzo). > zram-swap can keep using lzo for speed! > > I'll work in a compatibility patch for zram-swap script next to see if > zram0 is already being used and hot-add a new device. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] procd: patch to support busybox mkfs.ext2
v2 of the patch. uses lz4 compression by default. lz4 is always
installed by openwrt Makefile Config.in if zram.
lz4 is best for compressed filesystems as we all know (if you had to
choose between that and lzo).
zram-swap can keep using lzo for speed!
I'll work in a compatibility patch for zram-swap script next to see if
zram0 is already being used and hot-add a new device.
--- a/initd/zram.c 2016-07-03 06:39:51.01130 +0700
+++ b/initd/zram.c 2016-07-03 07:00:34.143492847 +0700
@@ -82,7 +82,7 @@
int
mount_zram_on_tmp(void)
{
- char *mkfs[] = { "/usr/sbin/mkfs.ext4", "-b", "4096", "-F", "-L", "TEMP", "-m", "0", "/dev/zram0", NULL };
+ char *mkfs[] = { "/sbin/mkfs.ext2", "-b", "4096", "-F", "-L", "TEMP", "-m", "0", "/dev/zram0", NULL };
FILE *fp;
long zramsize;
pid_t pid;
@@ -94,6 +95,14 @@
}
mkdev("*", 0600);
+
+ fp = fopen("/sys/block/zram0/comp_algorithm", "r+");
+ if (fp == NULL) {
+ ERROR("Can't open /sys/block/zram0/comp_algorithm: %s\n", strerror(errno));
+ return errno;
+ }
+ fprintf(fp, "%s", "lz4" );
+ fclose(fp);
zramsize = proc_meminfo() / 2;
fp = fopen("/sys/block/zram0/disksize", "r+");
@@ -107,10 +116,10 @@
pid = fork();
if (!pid) {
execvp(mkfs[0], mkfs);
- ERROR("Can't exec /sbin/mkfs.ext4\n");
+ ERROR("Can't exec /sbin/mkfs.ext2\n");
exit(-1);
} else if (pid <= 0) {
- ERROR("Can't exec /sbin/mkfs.ext4\n");
+ ERROR("Can't exec /sbin/mkfs.ext2\n");
return -1;
} else {
waitpid(pid, NULL, 0);
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] procd: patch to support busybox mkfs.ext2
For some further background... the original procd zram patch uses ext2 :) https://dev.openwrt.org/ticket/19586#comment:9 https://lists.openwrt.org/pipermail/openwrt-devel/2014-December/029587.html It shows you what happens when someone enables this option from make menuconfig. There needs to be some dependency testing. I suggest apply the patch and make it dependent on busybox mkfs.ext2 only. Leave mkfs.ext4 e2fsprogs in /usr/sbin and let users choose which they want from a fully qualified path in scripts. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] procd: patch to support busybox mkfs.ext2
Hi guys,
This is a little one. Busybox mkfs.ext2 works and with this setup the
ext4 module can mount /tmp without a journal. See #22666 I tested it.
Also the Makefile for procd doesn't have any dependencies for busybox
CONFIG_BUSYBOX_CONFIG_MKFS_EXT2=y OR e2fsprogs.
See the zram-swap Makefile. Mkfs.ext2 is also installed with e2fsprogs
so this wont break anything for those who install the more bloated
utility.
As we all know there is no need for mounting a journal on volatile
memory, so that's the other justification for this patch. busybox
supports all the commandline arguments given to mkfs.ext2
Also THE PATH WAS WRONG IN THE ORIGINAL PATCH for the error messages :P
Maybe e2fsprogs has to be patched so it installs to /sbin like most
other distros (e.g. gentoo)
--- zram.c.orig 2016-07-03 02:55:02.412237548 +0700
+++ zram.c 2016-07-03 02:55:54.691233783 +0700
@@ -82,7 +82,7 @@
int
mount_zram_on_tmp(void)
{
- char *mkfs[] = { "/usr/sbin/mkfs.ext4", "-b", "4096", "-F", "-L",
"TEMP", "-m", "0", "/dev/zram0", NULL };
+ char *mkfs[] = { "/sbin/mkfs.ext2", "-b", "4096", "-F", "-L",
"TEMP", "-m", "0", "/dev/zram0", NULL };
FILE *fp;
long zramsize;
pid_t pid;
@@ -107,10 +107,10 @@
pid = fork();
if (!pid) {
execvp(mkfs[0], mkfs);
- ERROR("Can't exec /sbin/mkfs.ext4\n");
+ ERROR("Can't exec /sbin/mkfs.ext2\n");
exit(-1);
} else if (pid <= 0) {
- ERROR("Can't exec /sbin/mkfs.ext4\n");
+ ERROR("Can't exec /sbin/mkfs.ext2\n");
return -1;
} else {
waitpid(pid, NULL, 0);
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
