Re: [OpenWrt-Devel] [PATCH] Automount enhanced/fixed, also fstab
I'd rather keep them optional, that's why the log tells if it misses blkid. Actually it doesn't. And it's only automatically selected if the base block-mount package is selected, so it is optional, but you don't have to worry about individual dependencies, and things work as expected without special effort out of the box. it does, for a good reason, functions/block.sh issues a log message if blkid is missing, but uuid is used. I don't see how to separate a base block-mount package, because the majority is replacing old mounting routines. I'd expect the new functionality to split in something like base-mount (which would be of package base-files because it replaces the old fstab mounting and is therefore essential, consisting of the files you put in buildroot/package/base-files except of the hotplugd stuff) menuconfig-Base system-hotplugd-block-automount (automount files, to enable automount feature) menuconfig-Base system-hotplugd-block-fsck (to enable fsck on hotplug events) I'd suggest to put all hotplugd functionality in buildroot/package/hotplugd-block. The hotplugd-block Makefile would contain the package definitions mentioned above. 2) It should be possible to pull in the dependencies for say block-blkid, from the base system menu (device-dependent submenu), rather than having to hunt down, say, blkid Sorry, not sure what you mean. Could you explain by example? Base System|Device Dependent should have packages such block-meta-blkid, that has the dependencies that pull in blkid and block-blkid (the package with the blkid mount stuff). Why is this submenu 'Device Dependent' needed? What does it tell the user? I see two solutions to this: If we want to keep it simple and small it might make sense to simply activate busybox's blkid per default. Have to doublecheck the size increase though. More elaborate could be, a basefiles subpackage setting menuconfig-Base system-basefiles [ ] support mount by uuid or label . But maybe this is too much. I'd make it depending on the size increase above. me neither ;) .. but seriously. Circular dependencies only mean that somebody did not look deep enough into setting them properly. Not true, with the limited dependency language we have. Show me an example that is not solvable. packages that supply block devices: usb-storage, sdcard, ... autoselect packages that are needed to use these: e.g. block-mount block-mount is *required* to use usb, it's just nice to have. That's why profile selection not autoselect. What do you mean? block-mount is *required* to use usb, or it's just nice to have ? In my understanding I distinguish between basefile-block-(mount,fsck( and the hotplugd-block-(automount,fsck). The basefile functionality is there anyway, the hotplugd is optional. Actually users do not need automounting to use usb storage devices. They can use the terminal to mount and stuff. But as hotplugd-automounting wasn't optional before on second thought I'd vote for activating it by default, but make it not depending on anything or anything depending on it. .. what do you think, ede ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] rdc gpio and watchdog driver
Hello This patch adds an pci driver for the rdc southbridge, where the gpio and wdt config registers are located. The custom reboot function is needed, beacuse the wdt works by creating a nmi interrupt, and the normal reboot fixups don't work in irq context. The code in platfrom.c is rather messed up at the moment, I plan to clean this up later. There are also some kernel patches missing, one that removes the original wdt driver, and something that removes the rdc reboot fixup and removes the dependencie of rdc from the x86 reboot fixups in the Kconfig file, but the patch should work just fine without those. Bernhard rdc.diff Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Automount enhanced/fixed, also fstab
On Thu, 2010-02-18 at 12:18 +0100, edgar.sol...@web.de wrote: I'd rather keep them optional, that's why the log tells if it misses blkid. Actually it doesn't. And it's only automatically selected if the base block-mount package is selected, so it is optional, but you don't have to worry about individual dependencies, and things work as expected without special effort out of the box. it does, for a good reason, functions/block.sh issues a log message if Heh, I had forgotten I had done that. blkid is missing, but uuid is used. I don't see how to separate a base block-mount package, because the majority is replacing old mounting routines. The thing to remember is the the /etc/init.d/fstab and 10-mount are for mounting optional filesystems. Neither of them is needed if you don't have storage beyond your rootfs (that is the boot rootfs (afaik squashfs, jffs2 or ext2), or squashfs (which is a boot rootfs) + jffs2 I'd expect the new functionality to split in something like base-mount (which would be of package base-files because it replaces the old fstab mounting and is therefore essential, consisting of the files But it's not essential. It's not used by preinit, which is where essential mounting is doing. /etc/fstab is kept around primarily in case some application expects to find something there and /etc/config/fstab is only used for optional filesystems. you put in buildroot/package/base-files except of the hotplugd stuff) menuconfig-Base system-hotplugd-block-automount (automount files, to enable automount feature) menuconfig-Base system-hotplugd-block-fsck (to enable fsck on hotplug events) I'd suggest to put all hotplugd functionality in buildroot/package/hotplugd-block. The hotplugd-block Makefile would contain the package definitions mentioned above. The reason I divided the packages the way I did is so the the scripts weren't installed unless package that provided the capability to provide the function was present. e.g. btrfs fsck script only included when btrfs-progs is. Initially the core of the block-mount was to be included in base-files (which is what what you're talking about switching to again, but I might as well have left things the way I had them if we're going to to do that, because there is 5-8k of scripts that are hotplug only, and that's it), and the other script functions were to be added along with the package that provided the program need to use it. You didn't like that because it was too big. The thing unless you subdivide to fairly small chunk you can't have a proper matching of scripts to available functionality. I am personally opposed to installed the scripts willy-nilly and spamming the syslog with error messages if the dependencies aren't met. I think that is bad design. It's much better to include the script only if it won't cause the user to get error messages. Now if the user uses a config file with unsupported functions that's a different story...that's a configuration error. 2) It should be possible to pull in the dependencies for say block-blkid, from the base system menu (device-dependent submenu), rather than having to hunt down, say, blkid Sorry, not sure what you mean. Could you explain by example? Base System|Device Dependent should have packages such block-meta-blkid, that has the dependencies that pull in blkid and block-blkid (the package with the blkid mount stuff). Why is this submenu 'Device Dependent' needed? What does it tell the user? Device Dependent is for things like block-* that depend on having 'external' (non-boot rootfs) devices , or on certain wifi devices (like the toggle you mentioned before). It's more general than hotplug-scripts because it includes things other than just hotplug scripts. I see two solutions to this: If we want to keep it simple and small it might make sense to simply activate busybox's blkid per default. Have to doublecheck the size increase though. More elaborate could be, a basefiles subpackage setting menuconfig-Base system-basefiles [ ] support mount by uuid or label . But maybe this is too much. I'd make it depending on the size increase above. me neither ;) .. but seriously. Circular dependencies only mean that somebody did not look deep enough into setting them properly. Not true, with the limited dependency language we have. Show me an example that is not solvable. 1) Package C should be installed if both package A and be are B are installed (because of user expectations; A implies that it will use the functionality of B, if present, but that requires C) 2) Package C depends on A and B packages that supply block devices: usb-storage, sdcard, ... autoselect packages that are needed to use these: e.g. block-mount block-mount is *required* to use usb, it's just nice to have. That's why profile selection not autoselect. What do you mean? block-mount is *required* to use usb,
[OpenWrt-Devel] [PATCH] add upx package and libucl
Hi,
these patches add upx and libucl packages.
From http://upx.sourceforge.net/
UPX is a free, portable, extendable, high-performance executable packer
for several different executable formats. It achieves an excellent
compression ratio and offers very fast decompression. Your executables
suffer no memory overhead or other drawbacks for most of the formats
supported, because of in-place decompression.
-Raphael
diff -pruN libs.orig//ucl/Makefile libs/ucl/Makefile
--- libs.orig//ucl/Makefile 1970-01-01 01:00:00.0 +0100
+++ libs/ucl/Makefile 2010-02-18 15:22:38.666408901 +0100
@@ -0,0 +1,57 @@
+#
+# Copyright (C) 2006-2010 OpenWrt.org
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=ucl
+PKG_VERSION:=1.03
+PKG_RELEASE:=1
+
+PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
+PKG_SOURCE_URL:=http://www.oberhumer.com/opensource/ucl/download/
+PKG_MD5SUM:=852bd691d8abc75b52053465846fba34
+
+PKG_FIXUP:=libtool
+PKG_INSTALL:=1
+
+include $(INCLUDE_DIR)/package.mk
+
+define Package/libucl
+ SECTION:=libs
+ CATEGORY:=Libraries
+ DEPENDS:=
+ TITLE:=The Ultimate Packer for eXecutables
+ URL:=http://upx.sourceforge.net/
+endef
+
+define Package/libucl/description
+UCL is a portable lossless data compression library written in ANSI C. UCL
+implements a number of compression algorithms that achieve an excellent
+compression ratio while allowing *very* fast decompression. Decompression
+requires no additional memory.
+endef
+
+CONFIGURE_ARGS += \
+ --enable-static \
+ --enable-shared \
+ --disable-asm
+
+define Build/InstallDev
+ $(INSTALL_DIR) $(1)/usr/include/ucl
+ $(CP) $(PKG_INSTALL_DIR)/usr/include/ucl/ucl{,conf}.h $(1)/usr/include/ucl/
+
+ $(INSTALL_DIR) $(1)/usr/lib
+ $(CP) $(PKG_INSTALL_DIR)/usr/lib/libucl.{a,so*} $(1)/usr/lib/
+endef
+
+define Package/libucl/install
+ $(INSTALL_DIR) $(1)/usr/lib
+ $(CP) $(PKG_INSTALL_DIR)/usr/lib/libucl.so* $(1)/usr/lib/
+endef
+
+$(eval $(call BuildPackage,libucl))
+
diff -pruN utils.orig//upx/Makefile utils/upx/Makefile
--- utils.orig//upx/Makefile 1970-01-01 01:00:00.0 +0100
+++ utils/upx/Makefile 2010-02-18 15:23:45.515160485 +0100
@@ -0,0 +1,53 @@
+#
+# Copyright (C) 2006-2010 OpenWrt.org
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=upx
+PKG_VERSION:=3.04
+PKG_RELEASE:=1
+
+PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-src.tar.bz2
+PKG_SOURCE_URL:=http://upx.sourceforge.net/download/
+PKG_MD5SUM:=68d662b1f831335460f9bfdbf632c6ce
+
+TAR_OPTIONS+=--transform='s,$(PKG_NAME)-$(PKG_VERSION)-src,$(PKG_NAME)-$(PKG_VERSION),'
+
+include $(INCLUDE_DIR)/package.mk
+
+define Package/upx
+ SECTION:=utils
+ CATEGORY:=Utilities
+ DEPENDS:=+libucl
+ TITLE:=The Ultimate Packer for eXecutables
+ URL:=http://upx.sourceforge.net/
+endef
+
+define Package/upx/description
+UPX is a free, portable, extendable, high-performance executable packer for
+several different executable formats. It achieves an excellent compression ratio
+and offers very fast decompression. Your executables suffer no memory overhead
+or other drawbacks for most of the formats supported, because of in-place
+decompression.
+endef
+
+MAKE_VARS += \
+ UPX_UCLDIR=$(STAGING_DIR)/usr/include/ucl \
+ exeext=
+
+define Build/Compile
+ $(call Build/Compile/Default, \
+ all \
+ )
+endef
+
+define Package/upx/install
+ $(INSTALL_DIR) $(1)/usr/bin
+ $(INSTALL_BIN) $(PKG_BUILD_DIR)/src/upx $(1)/usr/bin/
+endef
+
+$(eval $(call BuildPackage,upx))
diff -pruN utils.orig//upx/patches/100-disable_doc.patch utils/upx/patches/100-disable_doc.patch
--- utils.orig//upx/patches/100-disable_doc.patch 1970-01-01 01:00:00.0 +0100
+++ utils/upx/patches/100-disable_doc.patch 2010-02-18 15:23:45.515160485 +0100
@@ -0,0 +1,12 @@
+diff -pruN upx-3.04.orig//Makefile upx-3.04/Makefile
+--- upx-3.04.orig//Makefile 2010-02-18 15:07:46.894410571 +0100
upx-3.04/Makefile 2010-02-18 15:08:32.758657685 +0100
+@@ -35,7 +35,7 @@ ifeq ($(BUILD_STUB),1)
+ $(MAKE) -C src/stub $@
+ endif
+ $(MAKE) -C src $@
+- $(MAKE) -C doc $@
++# $(MAKE) -C doc $@
+
+
+ ifneq ($(wildcard .hg/.),)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 2mb flash not OpenWRT-Target?
Linux can hardly fit in a 2MB flash device, once you have opened the Yes, but this text was written in the old times (2004?) Linux is more and more modularized, so it is comfortably possible to run it (customized) with 4MB RAM and 512k of FLASH. bye, Bastian signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH RFC] [package] babeld and ahcpd: update and UCIfication
Hi, I've finished to convert the babeld and ahcpd packages to use UCI. In the meantime, I've updated them to latest upstream revision and integrated ahcp as a protocol in OpenWrt. The latter means that now, if you want to configure an interface with ahcp, you just need to put the following in /etc/config/network: config 'interface' 'wifi' option 'ifname' 'ath0' option 'proto' 'ahcp' The config file (/etc/config/ahcp) is now reserved for forwarder and server mode configuration. Nothing prevents you from using ahcp in client mode on some interfaces, and server mode on some others (but server and forwarder modes are mutually exclusive). The babel patch is not very different from what I sent yesterday, only a few fixes based on feedback I got off-list (thank you all). This patches have been tested today rather extensively. I'll commit them in the trunk very soon, but felt it necessary to make this public annoucement since they change deeply how the packages are configured. Please upgrade and provide more feedback if anything looks wrong. Atheros packages (working on my Fonera 2100) are available here: http://www.pps.jussieu.fr/~kerneis/software/files/ahcpd_0.51-1_atheros.ipk http://www.pps.jussieu.fr/~kerneis/software/files/babeld_0.98-1_atheros.ipk Regards, -- Gabriel Kerneis From 86eeb382fef31d07e102d99b63f06cd17e716d9b Mon Sep 17 00:00:00 2001 From: Gabriel Kerneis kern...@pps.jussieu.fr Date: Mon, 15 Feb 2010 19:21:39 +0100 Subject: [PATCH 1/2] [package] babeld: update to 0.98, fix scripts - Full-featured UCI configuration file (no need for babeld.conf). - Do not check the pid file (useless) and ahcpd script (harmful). - Make /etc/config/babeld a config file. - Launch at most one instance of babeld. - Add status and reload options to init script. - 8 February 2010: babeld 0.98: * Implement the ability to prefer Babel routes to external routes according to the kernel priority (-A). * Implement the ability to redistribute boot routes when the protocol is explicitly specified on the redistribute line. * Allow trailing whitespace in config file. Signed-off-by: Gabriel Kerneis kern...@pps.jussieu.fr --- net/babel/Makefile| 12 ++-- net/babel/files/babeld.conf | 20 +- net/babel/files/babeld.config | 72 - net/babel/files/babeld.init | 142 +++-- 4 files changed, 212 insertions(+), 34 deletions(-) diff --git a/net/babel/Makefile b/net/babel/Makefile index 144bf9e..d26ebba 100644 --- a/net/babel/Makefile +++ b/net/babel/Makefile @@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=babeld -PKG_VERSION:=0.97 +PKG_VERSION:=0.98 PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=http://www.pps.jussieu.fr/~jch/software/files/ -PKG_MD5SUM:=be0748c382dfe60bd35aa6b661e6077d +PKG_MD5SUM:=85af76e90914b82d9ece497e15df252f include $(INCLUDE_DIR)/package.mk @@ -22,6 +22,7 @@ define Package/babeld CATEGORY:=Network TITLE:=A loop-free distance-vector routing protocol URL:=http://www.pps.jussieu.fr/~jch/software/babel/ + MAINTAINER:=Gabriel Kerneis kern...@pps.jussieu.fr DEPENDS:=+kmod-ipv6 +librt endef @@ -37,19 +38,16 @@ endef define Package/babeld/conffiles /etc/babeld.conf +/etc/config/babeld endef -MAKE_FLAGS += \ - CC=$(TARGET_CC) \ - CFLAGS=$(TARGET_CFLAGS) \ - define Package/babeld/install $(INSTALL_DIR) $(1)/usr/sbin $(INSTALL_BIN) $(PKG_BUILD_DIR)/babeld $(1)/usr/sbin/ $(INSTALL_DIR) $(1)/etc $(INSTALL_CONF) ./files/babeld.conf $(1)/etc/ $(INSTALL_DIR) $(1)/etc/config - $(INSTALL_DATA) ./files/babeld.config $(1)/etc/config/babeld + $(INSTALL_CONF) ./files/babeld.config $(1)/etc/config/babeld $(INSTALL_DIR) $(1)/etc/init.d $(INSTALL_BIN) ./files/babeld.init $(1)/etc/init.d/babeld endef diff --git a/net/babel/files/babeld.conf b/net/babel/files/babeld.conf index 07fcbe1..fd488f9 100644 --- a/net/babel/files/babeld.conf +++ b/net/babel/files/babeld.conf @@ -1,11 +1,15 @@ # babel config file -# Copyright (C) 2008 Juliusz Chroboczek, L. Aaron Kaplan +# Copyright (C) 2008-2010 Juliusz Chroboczek, L. Aaron Kaplan # j...@pps.jussieu.fr , aa...@lo-res.org # # This config file simply documents sample entries. -# redistribute means: redistribute routes from other -# routing protocols into babel. local means addresses assigned to local interfaces. +# redistribute means: redistribute routes from other routing protocols +# into babel. local means addresses assigned to local interfaces. # +# You do not need to edit this file: you can use /etc/config/babeld +# instead (sections interface and filter). Both files can be used +# simultaneously (the rules of this file are executed first). + # the default rules are: # ## redistribute local @@ -14,15 +18,23 @@ # this says, redistribute local addresses but no other routes - # redistribute IPv4 default route into babel ## redistribute local ip 0.0.0.0/0 le 0 metric 128
[OpenWrt-Devel] [PATCH] add bzr support to include/download.mk and fix whitespace
Hi, this patch adds support for bzr in include/download.mk, and fixes whitespace. -Raphael--- include/download.mk.orig 2010-02-18 18:27:26.090680177 +0100 +++ include/download.mk 2010-02-18 18:14:32.187190084 +0100 @@ -1,5 +1,5 @@ -# -# Copyright (C) 2007 OpenWrt.org +# +# Copyright (C) 2006-2010 OpenWrt.org # # This is free software, licensed under the GNU General Public License v2. # See /LICENSE for more information. @@ -8,7 +8,7 @@ DOWNLOAD_RDEP=$(STAMP_PREPARED) $(HOST_STAMP_PREPARED) # Try to guess the download method from the URL -define dl_method +define dl_method $(strip \ $(if $(2),$(2), \ $(if $(filter @GNOME/% @GNU/% @KERNEL/% @SF/% ftp://% http://% file://%,$(1)),default, \ @@ -16,9 +16,9 @@ $(strip \ $(if $(filter svn://%,$(1)),svn, \ $(if $(filter cvs://%,$(1)),cvs, \ $(if $(filter hg://%,$(1)),hg, \ - unknown \ - ) \ - ) \ + unknown \ +) \ + ) \ ) \ ) \ ) \ @@ -26,7 +26,7 @@ $(strip \ ) endef -# code for creating tarballs from cvs/svn/git/hg checkouts - useful for mirror support +# code for creating tarballs from cvs/svn/git/bzr/hg checkouts - useful for mirror support dl_pack/bz2=$(TAR) cfj $(1) $(2) dl_pack/gz=$(TAR) cfz $(1) $(2) dl_pack/unknown=echo ERROR: Unknown pack format for file $(1); false @@ -49,19 +49,18 @@ endef define DownloadMethod/cvs $(call wrap_mirror, \ echo Checking out files from the cvs repository...; \ -mkdir -p $(TMP_DIR)/dl \ -cd $(TMP_DIR)/dl \ -rm -rf $(SUBDIR) \ -[ \! -d $(SUBDIR) ] \ -cvs -d $(URL) co $(VERSION) $(SUBDIR) \ -find $(SUBDIR) -name CVS | xargs rm -rf \ -echo Packing checkout... \ -$(call dl_pack,$(TMP_DIR)/dl/$(FILE),$(SUBDIR)) \ -mv $(TMP_DIR)/dl/$(FILE) $(DL_DIR)/; \ -) + mkdir -p $(TMP_DIR)/dl \ + cd $(TMP_DIR)/dl \ + rm -rf $(SUBDIR) \ + [ \! -d $(SUBDIR) ] \ + cvs -d $(URL) co $(VERSION) $(SUBDIR) \ + find $(SUBDIR) -name CVS | xargs rm -rf \ + echo Packing checkout... \ + $(call dl_pack,$(TMP_DIR)/dl/$(FILE),$(SUBDIR)) \ + mv $(TMP_DIR)/dl/$(FILE) $(DL_DIR)/; \ + ) endef - define DownloadMethod/svn $(call wrap_mirror, \ echo Checking out files from the svn repository...; \ @@ -93,6 +92,21 @@ define DownloadMethod/git ) endef +define DownloadMethod/bzr + $(call wrap_mirror, \ + echo Checking out files from the bzr repository...; \ + mkdir -p $(TMP_DIR)/dl \ + cd $(TMP_DIR)/dl \ + rm -rf $(SUBDIR) \ + [ \! -d $(SUBDIR) ] \ + bzr co --lightweight -r$(VERSION) $(URL) $(SUBDIR) \ + find $(SUBDIR) -name .bzr | xargs rm -rf \ + echo Packing checkout... \ + $(call dl_pack,$(TMP_DIR)/dl/$(FILE),$(SUBDIR)) \ + mv $(TMP_DIR)/dl/$(FILE) $(DL_DIR)/; \ + ) +endef + define DownloadMethod/hg $(call wrap_mirror, \ echo Checking out files from the hg repository...; \ @@ -111,6 +125,7 @@ endef Validate/cvs=VERSION SUBDIR Validate/svn=VERSION SUBDIR Validate/git=VERSION SUBDIR +Validate/bzr=VERSION SUBDIR Validate/hg=VERSION SUBDIR define Download/Defaults ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Automount enhanced/fixed, also fstab
Lets start here OpenWrt does not currently run on devices which have 2MB or less of flash memory. This limitation will probably not be worked around since those devices are most of the time micro-routers, or Wireless Access Points, which are not the main OpenWrt target. This reads to me only as not primary target. Not as in we do not support that. It simply states what was the case at the time of writing. Also my understanding of the community project openwrt is not to exlude anybody or some purpose. See the list of growing platforms for example. It is like a living organism. If there is a need or somebody willing it is done. If there is nobody by now, maybe somebody comes around later. What makes openwrt so unique is the vast amount of possibility. There is a small set of readymade images. But if you want to buildroot yourself the tiniest embedded Linux you need, well it is possible. Device Dependent is for things like block-* that depend on having 'external' (non-boot rootfs) devices , or on certain wifi devices (like Device dependent says nothing specific. Even worse, it sounds like something that should change according to the chosen device profile. How about additional/external storage support? This way the user would know what to expect in the category. the toggle you mentioned before). It's more general than hotplug-scripts because it includes things other than just hotplug scripts. Do you have more packages you want to put in there? Maybe we can come up with a less generic name. I think I'll wait to you've digested the correction on what's essential and what's not and the total size of the hotplug code. I also would And again .. it sums up. Having said sad I am glad to hear that the block mount scripts are not that tightly integrated in the boot process as I expected. Hence I gladly add it to the optional package list, see below. like you to really think about the issue of badgering the user because they didn't fill a dependency (that is have scripts that are trying to execute functions but can't because the programs to do it aren't there). You got me wrong. Read on. I think it's fundamentally flawed. Warning the user if they've configured things badly is different than failing to fill a dependency automatically when the promised functionality depends it. Dependencies reflect absolute requirements. Fs utility packages do not require the fsck.sh scripts. E.g. e2fsck works perfectly alone. The same with usb storage. This works if the new scripts are installed or not. The script merely offer a sophisticated way to deal with it. What we have here is a dynamic dependency e.g. blkid. Buildroot does not know if the user is going to configure the use of uuid or label mounts. Therefore it is a dependency that starts when the user configures the system after flashing. Hence there must be a way to tell him/her what is going on. Same for fs tools. Only because basic addstorage support is installed, this doesn't mean that the user is going to use an fsck.* app. This is decided later, if he decides to uci config a file check. In that lies the real quest. Easy solution is error log output. Better is putting comments where the fsck'ing is configured. Perfect would be a tool that helps to configure and checks for pitfalls. I actually opt for Easy+Better. Circumvent dynamic dependencies is only possible by splitting the promised functionality out of the big package to the effect that the small package wouldn't run if the dependency is missing. This is extra difficult here because of the multiple choice of filesystems. And there might be more in the future. The reason I divided the packages the way I did is so the the scripts weren't installed unless package that provided the capability to provide the function was present. e.g. btrfs fsck script only included when btrfs-progs is. Cleanly these fsck scripts should be packaged each as a package that depends on the appropriate fs tool and the basic blockmount. But this is more hassle than it's worth and therefore putting into their respective fs tools package serves the purpose fine. Initially the core of the block-mount was to be included in base-files (which is what what you're talking about switching to again, but I might This was because I was under the impression they weren't optional. as well have left things the way I had them if we're going to to do that, because there is 5-8k of scripts that are hotplug only, and that's it), and the other script functions were to be added along with the package that provided the program need to use it. You didn't like that because it was too big. Moreover I oppose to the idea to waste space on code that the user does not/ can not use. The thing unless you subdivide to fairly small chunk you can't have a proper matching of scripts to available functionality. Agreed see Circumvent dynamic dependencies... above. I am personally opposed
Re: [OpenWrt-Devel] 2mb flash not OpenWRT-Target?
Linux can hardly fit in a 2MB flash device, once you have opened the Yes, but this text was written in the old times (2004?) I've been using OpenWRT on my WL-700gE for a while now. That machine has a 2MB flash, so OpenWRT is quite usable there. But yes, it also has a IDE interface, so the 2MB only serves as a sort of initramfs (indeed, I don't even include a jffs2 partition, only squashfs). Linux is more and more modularized, so it is comfortably possible to run it (customized) with 4MB RAM and 512k of FLASH. This may be true, but I've found that the firmware for my WL-700gE tends to grow overtime, so while it's more and more modularized allowing it to run on ever smaller devices, for a given set of features its size tends to increase over time rather than decrease. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] x86: additional grub options and defaults for soekris
On Wednesday 17 February 2010 10:11:36 Jo-Philipp Wich wrote: Hi. I committed a modified version based on your patch in https://dev.openwrt.org/changeset/19681 - please test and report if you see further issues. hi! yes, grub configuration now works out of the box. there are still the problems i mentioned last time: * kernel 2.6.31.12 will not boot on soekris net4826 (with and without 300- block2mtd_init.patch) - system will reboot shortly after kernel was loaded. * and with kernel version 2.6.32.8 300-block2mtd_init.patch will cause a kernel panic. bruno ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] External Rootfs (e.g. USB)
This has to be manually configured after the first boot (and requires a reboot after a sysupgrade first boot). H... that's a problem. It means that you can't just have squashfs+extroot but need a jffs2 inbetween just for this little cconfig. Actually the squashfs/jffs2 is a fallback full firmware in the event of Inevitable Disaster(tm). Still, you need jffs2 there (both the jffs2 partition and the jffs2 modules). That's a lot of flash space for something that's not actually needed. And of course, it's also an added step when installing upgrading the firmware. config 'modules' 'modules' list 'fs_modules' 'fs-ext3' list 'controller' 'usb-core' list 'controller' 'usb-ohci' list 'controller' 'usb-storage' In my (limited experience), load all the available modules works just dandy: after all, these are only the modules available in the proto-root filesystem, so they're likely to be pretty close to the bare minimum. Could you explain the rationale for the relatively sophisticated config of modules you're proposing here? actually, the squashfs is likely to contain much more than the bare minimum; Why? If your rootfs is on USB or some such, there's little point in including lots of stuff in your squashfs. it's got whatever the user menuconfig selects as their base router configuration and it's harder to do something about things going wrong in preinit, so minimizing the modules loaded is useful. In addition hotplug doesn't coldplug in init. That means hotplug events aren't generated unless the modules are loaded after hotplug (in /etc/init.d/boot). I'll take your word for it on these issues. They haven't affected me, but that's not statistically significant. And, finally, it's really not very sophisticated. It just loads modules if they're listed, the same was as load_modules for the main system does, except it loads specific modules instead of all available. Well, I'm looking at it from the point of view of a user who'd like to be able to directly tell make menuconfig that his rootfs is on /dev/hde1, in which case any configuration on top of the rootfs device name is an annoyance. It's not terribly complicated code in my opinion, so shouldn't be a problem. I meant complex for the user, not for the implementer. I mean, as a user, I've already had to select which modules to include in my squashfs so that my rootfs can be found, so writing this file is an annoyance, and will hold redundant info, except that I additionally have to figure out whether it should say fs_modules or controller or maybe something else. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
