Hello wlanmac,
at first thank you for your feedback.
will it be difficult to remove overall or will the LuCI code be mixed up
with non-GUI scripts?
It's just a separate set of packages: not more, not less.
As for LuCI, I would like to know more about why Lua and hence LuCI? You
say It's not
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
Yeah, sounds like many scripting languages...
except shell ;-)
Agreed, there is always some distribution specific glue needed. I'm
leaning toward a 'meta configuration' (in XML) which can be edited,
verified, and translated into distro specific configurations.
Ah I see you added another
On Tue, Jul 15, 2008 at 12:38:24PM +0200, wlanmac wrote:
But if you are using the Gargoyle approach - that is not bad but simply a
different approach - you have to mess up with Shell and learn JavaScript or
in your case *yourFrontendLanguage*.
True. But, I'd argue that JavaScript
Hi,
What packages are minimally needed to make an OpenWRT run?
In kamikaze there was a minimum release, but in the current SVN version it
doesn't look that way anymore?
The packages getting compiled are:
- base-files
- bridge-utils
- broadcom-diag
- wireless-tools
- nvram
- broadcom-wl
-
Steven Van Ingelgem wrote:
What packages are minimally needed to make an OpenWRT run?
In kamikaze there was a minimum release, but in the current SVN
version it doesn't look that way anymore?
- bridge-utils
- wireless-tools
- broadcom-wl
- dnsmasq
- dropbear
- iptables
^- not strictly
Sorry, but in some respects I look at all these web interfaces and just
cringe; the webif was never meant to be a lifelong ambition, it should
only be a very thin layer between uci and the browser. All of the schema
and validation, as well as the i18n should actually be handled on the
uci
On Monday 14 July 2008 22:54:41 Andrew Morton wrote:
+static int gpiommc_probe(struct platform_device *pdev)
+{
+ static int instance;
+ struct gpiommc_device *d = platform_get_drvdata(pdev);
+ struct spi_gpio_platform_data pdata;
+ int err = -ENOMEM;
+
+ d-spi_pdev =
On Tuesday 15 July 2008 07:06:49 Ben Nizette wrote:
On Mon, 2008-07-14 at 21:09 +0200, Michael Buesch wrote:
This driver provides a sysfs interface to dynamically create
and destroy GPIO-based MMC/SD card interfaces.
So an MMC or SD card can be connected to generic GPIO pins
and be
On Tuesday 15 July 2008 07:30:51 Ben Nizette wrote:
Looks good overall. I'm not sure that it need pretend to be
hotpluggable though
Because the hardware _is_ hotpluggable.
(i.e. the board info can be hardwired so there's no
need for the board setup callback).
I'm not sure why we should
On Tue, Jul 15, 2008 at 02:21:06PM +0200, Steven Van Ingelgem wrote:
The once in italic I believe I can remove, but can someone please confirm
this because I don't want to brick another modem ;-)
If you start a fresh build and leave the package selection at defaults
you'll get only slightly
On Tuesday 15 July 2008 02:07:57 RHS Linux User wrote:
Hi All,
I wonder if this MMC driver can be extended to support 2 MMC devices?
It does support an infinite amount of devices. See the initscript for adding
another one.
--
Greetings Michael.
For reference, bricked is a term I use when there is absolutely nothing
that can be done to recover a router -- it should not be applied to
cases of nihilistic ignorance or apathy.
I think most of us here refer to that as a system that isn't even
recoverable via serial terminal - the
Well,
The default SVN build is 1.9M in size. IIRC the micro build of whiterussion
was like 1.3M, so I wonder what I need to remove to get it back to that
size.
BTW? Does anyone know if there is already an OS driver available for the
WRT54GL modems (I'm speaking about the Broadcom wireless). I
On Tue, Jul 15, 2008 at 6:21 AM, Steven Van Ingelgem
[EMAIL PROTECTED] wrote:
What packages are minimally needed to make an OpenWRT run?
The below list is, for all intents and purposes, the minimal list.
Notes below on removal.
The packages getting compiled are:
- base-files
- bridge-utils
RB wrote:
- broadcom-diag
Removable if you don't care whether the LEDs work; may break other
core scripts in base-files that depend on what it provides, though.
Don't. Failsafe relies on it.
- dropbear
Not necessary if SSH isn't a concern (I rather think it is).
I believe you want SSH,
The default SVN build is 1.9M in size. IIRC the micro build of whiterussion
was like 1.3M, so I wonder what I need to remove to get it back to that
size.
Whiterussian's build process was completely different, and I don't see
much attention being paid to the systems with under 2MB of flash any
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
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
On Monday 14 July 2008 21:09:18 Michael Buesch wrote:
This driver provides a sysfs interface to dynamically create
and destroy GPIO-based MMC/SD card interfaces.
So an MMC or SD card can be connected to generic GPIO pins
and be configured dynamically from userspace.
Ok, I had requests in
20 matches
Mail list logo