remote syslog + top + OHCI
Augusto Bott
Augusto Bott
Joao Cardoso
> Hi there!
>
> Here's a few tweaks/enhancements on Alt-F v0.1b5 I've implemented for my
> own needs that could be useful and/or interesting for other people (and...
> even become part of future Alt-F releases - who knows! ;-)
Excelent! The very first code contribution to Alt-F! Congratulations Augusto.
I will certainly apply some of those changes to Alt-F.
But I have some questions :-)
> - remote syslog:
> As you probably are aware, many embedded systems
> (including Alt-F) record/store syslog messages on a memory area (which is
> limited and non-persistent). This usually means we don't get a chance to
> keep any kind of history and... when/if the box (or syslogd) crashes and/or
> restarts... everything logged so far is gone. So... it can be quite
> handy/useful to store/record/keep logs somewhere else ;-)
-Could you please add a two lines Copyright and Licence to the relevant files?
The Licence can refer, if applicable, to the COPYING file located in the
root of the rootfs and source code.
-And can you in fact see the startup/shutdown sequence using it?
-Can you supply a test setup? or at least a fragment of the startup/shutdown
remote log?
-How much more memory is actually needed?
in B6:
629596 Dec 12 18:58 /bin/busybox
335628 Dec 12 18:58 /lib/libuClibc-0.9.30.3.so
> - top:
> Currently 'top' is configured to show integer values on columns %MEM and
> %CPU (rounding up to the next integer value). I've changed this behaviour
> so it would show values with one decimal digit.(i.e. shows values like
> 0.8% instead of rounding up to 1%)
hmmm...
> - OHCI:
> I noticed the stock D-link software does have it enabled (but Alt-F
> apparently doesn't). I'm not sure if OHCI is actually required, but since
> I've been fiddling and testing USB-related things, seemed a good idea to
> have it enabled.
-For how much does the kernel size increases?
-Can it be build as a module? Modules are in /usr, which is lzma compressed.
-Can you refer a specific hardware or "use case" where it is needed?
I can attach usb printers/pens/disks without problems using the standard Alt-F
kernel.
In my mind, in the future there will be a disk-instalable kernel modules
package, containing modules that are not necessary to the base system and to
most users, but that nevertheless some users might need.
As it is usual with me, too many questions ;-), please do your best
Thanks,
João
BTW, did you have any problem building B5? apart the mconf/qconf issue?
Augusto Bott
--
Augusto Bott
--
You received this message because you are subscribed to the Google Groups "Alt-F" group.
To post to this group, send email to al...@googlegroups.com.
To unsubscribe from this group, send email to alt-f+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/alt-f?hl=en.
Augusto Bott
--
Augusto Bott
Joao Cardoso
> About 'copyright': please feel free to do whatever works best for you
> and/or the project (IMHO, I wrote these patches/hacks without any
> expectations... to be released as GPL, LGPL, PD, whatever ;-)
I understand your atitude, but you have to say something... I still have to do
the same for myself.
Does the following fits? Give me the e-mail address of your desire.
Copyright (c) 2010 Augusto Bott <your e-mail, even if in disguise>
Can be freely distributed and used under the terms of the GNU GPL, see the
/COPYING file for details
You can also put the files in the public domain, if you desire.
> About remote syslogging + shutdown: short answer would be 'sure!'. Long
> answer would be 'sure! as long as syslogd is running'. The shutdown
> procedure calls /etc/init.d/rcE, which begins by calling 'rcall stop' early
> on...
"rcall" already has two exceptions: sysctrl and inetd, just add syslog. But
you have also to comment the "ifconfig eth0 down" line in rcE
> If you're wondering if this actually works...
I know it works :-)
But the real advantage has to do with poweroff/shutdown loggging. And only for
those who can do it, most users won't, even if we write an wiki entry.
Alt-F was not made for experts -- for those we already have Debian.
Alt-F intends to be an *alternative*, and thus has to be usable by the average
user. But not so average as Gnome developpers use to think that users are :-)
> About OHCI/EHCI built-in or as modules: according to "make O=$BLDDIR
> linux26-menuconfig", both OHCI and EHCI can be built as modules (but I've
> been compiling both 'built-in' at the moment on my tests). As I said
> before, I'm not quite sure OHCI is actually needed/required on these boxes
> (but the output of 'dmesg' indicates both EHCI and OHCI are enabled on the
> D-link FW v1.09).
>
> The main reason behind enabling/fiddling/testing OHCI (and EHCI options,
> see below) is actually related to:
> - the amount of time it takes to run a simple command such as 'lsusb' on
>
> the unit (seems to run faster with stock FW, to be confirmed)
From a certain point in its history, usbutils started to be very slow, I have
even downgraded the Alt-F package version. Try version 0.72
> - the number of devices being detected/listed with 'lsusb'
>
> Stock D-link FW v1.09, right after boot (FFP for telnet access), no USB
> devices plugged in, no modules manually loaded (or unloaded):
> / # lsusb
> Bus 002 Device 001: ID 0000:0000
> Bus 001 Device 001: ID 0000:0000
> / #
>
> Alt-F v0.1b5, right after boot, no USB devices plugged in, no modules
> manually loaded (or unloaded):
> # lsusb
> Bus 001 Device 001: ID 1d6b:0002
> #
The unity has two USB devices, but as only one is available from the outside
(without soldering) the kernel only initializes one of them.
I have compiled and run pciutils, to see what does it reports. Nothing. The
SoC does not uses PCI (except rev-A1, for the external sata chip)
> About image sizes ('testing' = OHCI + remote syslog + top with decimals):
>
> /lib/libuClibc-0.9.30.3.so
> v0.1b6 = 335628 bytes (from your last reply)
> testing = 335732 bytes
> difference = 104 bytes (!!!)
>
> /bin/busybox
> v0.1b6 = 629596 bytes (from your last reply)
> testing = 629600 bytes
> difference = 4 bytes (!!!)
>
> rootfs.arm.cpio-sq.lzma
> v0.1b5 = 6448640 bytes (how big is v0.1b6, BTW?)
currently 6428648
> testing = 6465956 bytes
> difference = around 16k
>
> zImage
> v0.1b5 = 1521204 bytes
currently 1438632
> testing = 1529284 bytes
> difference = 8080 bytes (not quite sure how much this means once the kernel
> image is uncompressed)
>
> As a curiosity: I just finished compiling another test kernel with OHCI +
> deadline IO sched + sr module (support for USB cd/dvd optical drives) +
> enhanced EHCI scheduler (let's see if I get any performance improvements
> over USB :-). zImage = 1531600 bytes (only 10k bigger than 'stable',
> above).
The problem in embedded systems is that, as a portuguese saying says: "grain
by grain does the birdie fills the craw" :)
Bye,
Augusto Bott
--
Augusto Bott
--
Joao Cardoso
> Is this behaviour (initializing only one of them [ internal USB]) specified
anywhere in the
> code of Alt-F or... does this happen 'automagically' due to some kind of
> kernel patch/update/etc..?
all kernel DNS-323 specific handling is at arch/arm/mach-orion5x/dns323-
setup.c which only inits one of the two usb devices: orion5x_ehci0_init();
> 'later
>
>