Re: [OpenWrt-Devel] ARM Kernel crash
Thanks! actually, that variable was already set. I will enable a few more options. I didn't get an Oops report - at least not out of QEmu or from an remotely attached gdb. On Tue, 2008-07-15 at 12:43 +0200, John Crispin wrote: activate CONFIG_KALLSYMS and then paste the oops dump pls wlanmac wrote: Hi all, I have a problem with a program crashing an ARM kernel - and crashing it hard. The program uses the Tun/Tap driver, but I'm not certain that is the issue. I haven't seen this behavior on any other architecture - anyone know of known problems with tun/tap or other issues with ARM? I tried to debug the kernel while running under QEmu, but gdb just drops the remote connection with no other info. Any ideas about the problem or how to go about debugging it would be appreciated. Best regards, David ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Gargoyle -- another (new) web interface for OpenWrt Kamikaze
Its funny you all speak about division, being i cant completely functionally use any of them that exists, being x-wrt, gargoyle, or luci so to each there own, there is CoovaAP also which is a diversion gargoyle doesnt even configure WDS from where i can see, looking at Luci next, x-wrt leaves a bit to be desired quite honestly, i believe there is room in this space for other, better more complete GUIs, not to compare anything openwrt to dd-wrt, the only good thing dd-wrt has is the GUI, the rest well we have found problematic and unstable, also its encrypted. not sure why he decided to shoot himself that way but hey, whole other topic. now if all of you were to come together, and join forces and take the best features from each of what exists, you might get my attention, the one gui that does what i require is Coova, though its not complete either. overall you all lack some functionality in both design and features capabilities. so stop whining or compalining and GET to work before someone else wrties another, by the way Luci... well its fast kudos to you guys for that, though i cant read german :) On Tue, 2008-07-15 at 09:57 -0400, Brian J. Murrell wrote: On Mon, 2008-07-14 at 17:04 -0400, Eric Bishop wrote: It is ironic that the LuCI team decided to make an announcement regarding their project today. I have also been working on a new (open source) web interface for Kamikaze called Gargoyle, and am now releasing the first beta version, which can be found at gargoyle-router.com. Another. ~sigh~ I'm all for choice, but too much choice possibly means an unnecessary division of labour and unfortunately all Open Source projects suffer from a shortage of labour. I wonder how much better and more complete one (or two perhaps) web UIs for OpenWRT would be if the resources were pooled into a common project that kept all of the stakeholders happy. Right up front I want to emphasize that Gargoyle is, like both LuCI and X-Wrt a front-end for OpenWrt and NOT a fork. Right. All trying to achieve the same thing. Hence my division of labour comment. Currently it is designed to run on top of Kamikaze 7.09 and not the trunk, but as soon as another stable version is released it will be engineered to run on top of that. So you will only remain compatible with released versions? How much lag do you expect after a release becomes stable before you will have your UI working on it? However, several features included in the current trunk have been incorporated (e.g. the new UCI) and are installed as packages on top of the default Kamikaze release. I have chosen to incorporate the features this way so that the interface could be built around a stable version vs. the ever-changing trunk. Right, but unless you track trunk, you will always have a lag between waiting for a stable release and porting your work to it. Gargoyle takes a very different philosophical approach to interface design than X-Wrt or what I've seen of the new LuCI. Both X-Wrt and LuCI seem to be designed with the goal of providing the absolute maximum functionality possible. Which is a good thing. With the hackabilty of OpenWRT, people are doing all kinds of neat things to it, a lot which less-power-users might like, if there were UI to configure it. However, this often comes at the expense of making the interface more difficult to use, and can turn off novice users. Indeed, there should be a simplified interface for the simple use-cases, but also a more advanced interface for power users. But there is nothing wrong with those both being available in the same UI. They are not mutually exclusive. Just my $0.02. b. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Gargoyle -- another (new) web interface for OpenWrt Kamikaze
On Wed, 2008-07-16 at 20:59 +0700, OutBackDingo wrote: Its funny you all speak about division, being i cant completely functionally use any of them that exists, being x-wrt, gargoyle, or luci That's exactly my point. _Exactly_. Here we have 3 or 4 (or more) web UIs all going off in different directions and not one of them functional enough that I don't need a shell prompt. Don't get me wrong, I applaud all of the time and effort being put into development of FOSS, I just think that the OpenWRT WebUI effort would be better serviced by some collaboration of resources to yield one or two UIs that were functionally useful for the varied uses and functions that OpenWRT can be put to. I'm all for a simple and advanced UI, but those don't have to be different projects. The same framework (i.e. the meat behind the eye-candy) can be used to provide both rather than two completely different frameworks with two completely different lipstick-and-mascara covers on them. b. signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Gargoyle -- another (new) web interface for OpenWrt Kamikaze
I think you might be reading between the lines here, clarifying my thoughts, diversification is good, controlled collaboration growing from that is even better overall I think its best you take a good look at the BSD arena, there are multiple BSDs all living and playing well, and sharing concepts, features, code. there is nothing wrong with diversion, of similiar concepts, but there should be some collaboration amongst these projects, meaning dont re-invent the whole wheel, but share concepts. its not the projects themselves that are broken, its the conceptual way people percieve development, take a lesson from BSD and even m0n0wall. M0n0wall has itself been forked into some 4 or 5 other projects each with a different target audience, though similiar concepts and code could be shared among the projects. I find in alot of ways the linux camp in general if very forked, they dont percieve doing things together in generalist terms, meaning whats common to you all, first its WRT. second is the goal of being able to configure it, third is features. if the 3 projects collaborated and understood one another there could be a good common re-usable code base, from there is the capability to develop divergent UIs that might appear conceptually the same but have differences among them, you all need to consider your goals, whats re-usable, whats common, whats unique to each individually. I never said all come together in one, that breaks potential innovation from individuals, but it does make sense to collaborate and consider the re-usabilities of your project and how / where it affects others. its not even they all have to be haserl, or lua, a language preference even make a difference. in both flexibilities and performance, though overall one might be faster, the other more flexible. im surprised theres no python gui, or php even. people want functionality and features without giving up performance. On Wed, 2008-07-16 at 10:10 -0400, Brian J. Murrell wrote: On Wed, 2008-07-16 at 20:59 +0700, OutBackDingo wrote: Its funny you all speak about division, being i cant completely functionally use any of them that exists, being x-wrt, gargoyle, or luci That's exactly my point. _Exactly_. Here we have 3 or 4 (or more) web UIs all going off in different directions and not one of them functional enough that I don't need a shell prompt. Don't get me wrong, I applaud all of the time and effort being put into development of FOSS, I just think that the OpenWRT WebUI effort would be better serviced by some collaboration of resources to yield one or two UIs that were functionally useful for the varied uses and functions that OpenWRT can be put to. I'm all for a simple and advanced UI, but those don't have to be different projects. The same framework (i.e. the meat behind the eye-candy) can be used to provide both rather than two completely different frameworks with two completely different lipstick-and-mascara covers on them. b. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] PPS-tools
This patch updates the package PPS-tools to linuxpps-v5.3.0
I extracted from http://wiki.enneenne.com/index.php/LinuxPPS_support.
Signed-off-by: Frithjof Hammer [EMAIL PROTECTED]
Index: utils/pps-tools/patches/001-source.patch
===
--- utils/pps-tools/patches/001-source.patch(Revision 11847)
+++ utils/pps-tools/patches/001-source.patch(Arbeitskopie)
@@ -1,8 +1,6 @@
-diff --git a/Makefile b/Makefile
-new file mode 100644
-index 000..a2660a2
/dev/null
-+++ b/Makefile
+diff -urN a/Makefile b/Makefile
+--- a/Makefile 1970-01-01 01:00:00.0 +0100
b/Makefile 2008-07-16 15:56:51.0 +0200
@@ -0,0 +1,27 @@
+TARGETS = ppstest ppsctl
+
@@ -10,7 +8,7 @@
+CFLAGS += -I .
+CFLAGS += -ggdb
+
-+# -- Actions
section --
++# -- Actions section --
+
+.PHONY : all depend dep
+
@@ -24,18 +22,16 @@
+endif
+
+
-+# -- Clean
section
++# -- Clean section --
+
+.PHONY : clean
+
+clean :
+ rm -f *.o *~ core .depend
+ rm -f ${TARGETS}
-diff --git a/ppsctl.c b/ppsctl.c
-new file mode 100644
-index 000..83fd08a
/dev/null
-+++ b/ppsctl.c
+diff -urN a/ppsctl.c b/ppsctl.c
+--- a/ppsctl.c 1970-01-01 01:00:00.0 +0100
b/ppsctl.c 2008-07-16 15:56:51.0 +0200
@@ -0,0 +1,62 @@
+#include stdio.h
+#include unistd.h
@@ -99,11 +95,9 @@
+
+ return 0;
+}
-diff --git a/ppsfind b/ppsfind
-new file mode 100755
-index 000..93c0e17
/dev/null
-+++ b/ppsfind
+diff -urN a/ppsfind b/ppsfind
+--- a/ppsfind 1970-01-01 01:00:00.0 +0100
b/ppsfind 2008-07-16 15:56:51.0 +0200
@@ -0,0 +1,17 @@
+#!/bin/sh
+
@@ -122,11 +116,9 @@
+done
+
+exit 0
-diff --git a/ppstest.c b/ppstest.c
-new file mode 100644
-index 000..d125ffa
/dev/null
-+++ b/ppstest.c
+diff -urN a/ppstest.c b/ppstest.c
+--- a/ppstest.c1970-01-01 01:00:00.0 +0100
b/ppstest.c2008-07-16 15:56:51.0 +0200
@@ -0,0 +1,151 @@
+#include stdio.h
+#include stdlib.h
@@ -279,12 +271,186 @@
+
+ return 0;
+}
-diff --git a/timepps.h b/timepps.h
-new file mode 100644
-index 000..28ebf4c
/dev/null
-+++ b/timepps.h
-@@ -0,0 +1,193 @@
+diff -urN a/pps.txt b/pps.txt
+--- a/pps.txt 1970-01-01 01:00:00.0 +0100
b/pps.txt 2008-07-16 15:56:51.0 +0200
+@@ -0,0 +1,172 @@
++
++ PPS - Pulse Per Second
++ --
++
++(C) Copyright 2007 Rodolfo Giometti [EMAIL PROTECTED]
++
++This program is free software; you can redistribute it and/or modify
++it under the terms of the GNU General Public License as published by
++the Free Software Foundation; either version 2 of the License, or
++(at your option) any later version.
++
++This program is distributed in the hope that it will be useful,
++but WITHOUT ANY WARRANTY; without even the implied warranty of
++MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
++GNU General Public License for more details.
++
++
++
++Overview
++
++
++LinuxPPS provides a programming interface (API) to define into the
++system several PPS sources.
++
++PPS means pulse per second and a PPS source is just a device which
++provides a high precision signal each second so that an application
++can use it to adjust system clock time.
++
++A PPS source can be connected to a serial port (usually to the Data
++Carrier Detect pin) or to a parallel port (ACK-pin) or to a special
++CPU's GPIOs (this is the common case in embedded systems) but in each
++case when a new pulse comes the system must apply to it a timestamp
++and record it for the userland.
++
++Common use is the combination of the NTPD as userland program with a
++GPS receiver as PPS source to obtain a wallclock-time with
++sub-millisecond synchronisation to UTC.
++
++
++RFC considerations
++--
++
++While implementing a PPS API as RFC 2783 defines and using an embedded
++CPU GPIO-Pin as physical link to the signal, I encountered a deeper
++problem:
++
++ At startup it needs a file descriptor as argument for the function
++ time_pps_create().
++
++This implies that the source has a /dev/... entry. This assumption is
++ok for the serial and parallel port, where you can do something
++useful besides(!) the gathering of timestamps as it is the central
++task for a PPS-API. But this assumption does not work for a single
++purpose GPIO line. In this case even basic file-related functionality
++(like read() and write()) makes no sense at all and should not be a
++precondition for the use of a PPS-API.
++
++The problem can be simply solved if you consider that a PPS source is
++not always connected with a GPS data source.
++
++So your programs should check if the GPS data source (the serial port
++for instance) is a PPS source too, otherwise they should provide the
Re: [OpenWrt-Devel] Adding entries to the crontab
How is it possible to create a crontab entry while creating a package? [...] But I would like to do it at such time that the crontab is already modified on the firmware image? I'm not sure to understand: you just want to add a crontab entry at package installation time, right ? If so, you can use the target Package/packagename/postinst to add such entry with a little shell script. You can see an example here: https://dev.openwrt.org/cgi-bin/trac.fcgi/browser/packages/admin/muninlite/Makefile This package add entries to /etc/inetd.conf and /etc/services at installation time. In fact, what's directly under such target (until the keyword 'endef' is encountered) will be copied verbatim as a post-install script in your package at build time. Cheers, ben -- *Benoît GANNE* /jabber: [EMAIL PROTECTED]/ /icq: 138217861/ /msn: [EMAIL PROTECTED]/ -- ...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and the Ugly). -- Matt Welsh ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Adding entries to the crontab
Am Mittwoch, 16. Juli 2008 20:47 schrieb Benoît Ganne:
How is it possible to create a crontab entry while creating a package?
[...]
But I would like to do it at such time that the crontab is already
modified on the firmware image?
I'm not sure to understand: you just want to add a crontab entry at
package installation time, right ?
If so, you can use the target Package/packagename/postinst to add such
entry with a little shell script.
You can see an example here:
https://dev.openwrt.org/cgi-bin/trac.fcgi/browser/packages/admin/muninlite/
Makefile This package add entries to /etc/inetd.conf and /etc/services at
installation time.
In fact, what's directly under such target (until the keyword 'endef' is
encountered) will be copied verbatim as a post-install script in your
package at build time.
Interesting, but a bit of a dirty hack for something like cronjobs imho. I
always wondered if there is something like /etc/cron.d/ and /etc/{hourly|
daily|monthly} for openwrt? But obviously there is not.
jens
pgpzw1INtlt8a.pgp
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Adding entries to the crontab
On Wed, 2008-07-16 at 21:11 +0200, Jens Nachtigall wrote:
Interesting, but a bit of a dirty hack for something like cronjobs imho.
No, on the contrary. Using published interfaces such as the crontab
command to submit cron entries is in fact the official method of
adding cron jobs. Hacking crontab files within cron's management is the
dirty hack.
I
always wondered if there is something like /etc/cron.d/ and /etc/{hourly|
daily|monthly} for openwrt? But obviously there is not.
Most of those files are all conveniences on top of the basic cron system
to which you use the crontab (or /etc/crontab in the case of vixie's
implementation -- the historic implementation didn't have the /etc/cron
system-wide file) command to add entries.
The accepted way to add a cron entry for a package is indeed to put it
into it's postinst and have the package install process (building the
base /rom image does in fact use the package install process, so it will
work, IIUC) add the entry through the official API.
That all said, I can't find the cron package in OpenWRT. Can anyone
point me (in the source tree I mean) to it?
b.
signature.asc
Description: This is a digitally signed message part
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Adding entries to the crontab
Thanks Benoit :-), that helps a lot! 2008/7/16 Benoît Ganne [EMAIL PROTECTED]: How is it possible to create a crontab entry while creating a package? [...] But I would like to do it at such time that the crontab is already modified on the firmware image? I'm not sure to understand: you just want to add a crontab entry at package installation time, right ? If so, you can use the target Package/packagename/postinst to add such entry with a little shell script. You can see an example here: https://dev.openwrt.org/cgi-bin/trac.fcgi/browser/packages/admin/muninlite/Makefile This package add entries to /etc/inetd.conf and /etc/services at installation time. In fact, what's directly under such target (until the keyword 'endef' is encountered) will be copied verbatim as a post-install script in your package at build time. Cheers, ben -- *Benoît GANNE* /jabber: [EMAIL PROTECTED]/ /icq: 138217861/ /msn: [EMAIL PROTECTED]/ -- ...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and the Ugly). -- Matt Welsh ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Adding entries to the crontab
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 That all said, I can't find the cron package in OpenWRT. Can anyone point me (in the source tree I mean) to it? cron is supplied by the busybox harald -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIflpmJgyxs71kcx4RAqOBAJ9w928k8Ay/UfKGa+0Q+0DbhRhPMACdHYEk qvCH1HAPyh10VSRUbSojaTY= =BQjf -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Adding entries to the crontab
It seems to work well using the crontab command from within your init
script - assuming your cron is associated with a service.
in start():
(crontab -l 2/dev/null | grep -v $0
echo */10 * * * * $0 checksomething
) | crontab - 2/dev/null
in stop():
crontab -l 2/dev/null | grep -v $0 | crontab -
and then check for the checksomething argument to your init script. It
is self contained, and installed/removed on start/stop.
On Wed, 2008-07-16 at 21:11 +0200, Jens Nachtigall wrote:
Am Mittwoch, 16. Juli 2008 20:47 schrieb Benoît Ganne:
How is it possible to create a crontab entry while creating a package?
[...]
But I would like to do it at such time that the crontab is already
modified on the firmware image?
I'm not sure to understand: you just want to add a crontab entry at
package installation time, right ?
If so, you can use the target Package/packagename/postinst to add such
entry with a little shell script.
You can see an example here:
https://dev.openwrt.org/cgi-bin/trac.fcgi/browser/packages/admin/muninlite/
Makefile This package add entries to /etc/inetd.conf and /etc/services at
installation time.
In fact, what's directly under such target (until the keyword 'endef' is
encountered) will be copied verbatim as a post-install script in your
package at build time.
Interesting, but a bit of a dirty hack for something like cronjobs imho. I
always wondered if there is something like /etc/cron.d/ and /etc/{hourly|
daily|monthly} for openwrt? But obviously there is not.
jens
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
