On 10/23/2012 10:35 AM, Tim Bird wrote:
Hi everyone,
I'm conducting a bit of a survey. I am holding a "Birds-of-a-Feather"
session at ELC Europe in a few weeks on the topic of embedded
Linux tips and tricks. For that session, I'd like to collect
ideas from people about tips or tricks that you use in your own
embedded Linux development.
Specifically do you have tips in any of the following topic areas
that you would be willing to share with me (so I can share with others?)
1. git commands:
Do you have any 'git' commands that you use, that
you think are not commonly known or used?
My own is 'git describe', which I used quite a bit when
preparing my 'status of embedded Linux' talks.
Also, I use 'git format-patch' quite a bit when I'm converting
from git commits to a quilt series. I know people use this
for submitting patches to mainline, but I use it a bit differently
(I think) when I'm making a quilt patch series.
2. Custom or homebrew tools:
When I'm moving from git commits to quilt patches, I also use
a homebrew tool called 'diffinfo', that can split large patches
into smaller ones based on regular expressions or file paths.
I know I could also use "git rebase --interactive" for this, but
I've gotten used to my own tool for this.
Do you have any custom tool that you use to solve a particular
problem you run into frequently, that you would be willing to
describe?
I use a tool, finds, I got from someone about 15 years ago. It simply
does a recursive look for a string in all files of interest in a
directory tree. When I get a big tarball of code that I don't intend to
build, but want to grab some logic, I use finds. I have created a
variety of variations of finds (which I usually later throw away) as my
search needs change. Essentially finds is
find . -exec fgrep -H "$1" {} \;
but with lots and lots of other qualifiers. You can see a usable
version at
https://www.ridgerun.com/developer/wiki/index.php/Tip_of_the_day#finds_-_find_a_string_in_common_text_files
Another one I use is called 'ttc', for 'tiny target control'.
It is a thin wrapper over many of the commands that are used
to configure, build and install the kernel (as well as execute
commands on the target, move stuff between host and target, etc.)
I use this so that I don't have to remember all the different
config options, toolchain paths, cross-compiler prefix, bootloader
commands, and board access methods for the different boards I use.
Currently I'm only dealing with 2 or 3 boards, but I used to
deal with about 10 different boards on a continual basis.
It was driving me nuts every time I switched from one
board to another, having to re-learn all
the little details about working with the new board.
Anyone else do something similar?
3. development practices:
Do you have a way that you debug or develop Linux software, that
may be different from others. For example, I'm a bit of a
debugging medievalist. I still do probably 70% of my kernel debugging
with printks. One quirky "trick" I use, is that I usually put any
printks that I want to trigger from user-space in
fs/sync.c:SYSCALL_DEFINE0(sync)
This syscall is not called under normal conditions by any other
programs, and is easily triggered with the 'sync' command at the shell.
I know I could put something in /proc, or /debugfs, but using
sync does not require mounting anything ahead of time, and it's
much easier to just drop a few printks there than code up a
procfs entry.
What do you use to debug the kernel? (qemu?, jtag?, kgdb?) Any tips
for using those, that you think other people might not know?
3. hardware configuration
How is your hardware set up? The first thing I do when I get a
new board is set it up with a network connection and serial connection
to my host (on an isolated network segment, of course, since Sony doesn't
like my host acting like a DHCP server for other machines!). Also, I
use a digital loggers web-controllable power switch. I used all kinds
of different things previously (including relays that could toggle
reset buttons on the boards, or control the power to the board via
a USB power switch). I usually spend a few hours getting the board
completely set up for automated, command-line driven access. From then
on, I pretty much never touch the board, and I can even access it from
anywhere when I'm traveling, using ssh to my host.
How do you set up your development boards? Do you have a common
configuration that you use that makes things easier to access the board,
deploy the software, etc.
A recurring problem I had was finding the right /dev/ttyUSB? device. I
have a nice USB to 4 serial port adaptor in a metal box I have screwed
to my bench. I also use several USB serial dongles. For reasons I
don't understand, they change association (at least under Ubuntu). I
created two scripts lsuart and uart. The output of lsuart gives me
information about the serial ports, like
Available USB UARTs
-------------------
a:/dev/ttyUSB0 FTDI USB Serial Device 0000:00:04.1-4.1 (4 port jack A)
b:/dev/ttyUSB1 FTDI USB Serial Device 0000:00:04.1-4.2 (4 port jack B)
c:/dev/ttyUSB2 FTDI USB Serial Device 0000:00:04.1-4.3 (4 port jack C)
:/dev/ttyUSB3 pl2303 0000:00:02.1-4.2 ()
d:/dev/ttyUSB4 FTDI USB Serial Device 0000:00:04.1-4.4 (4 port jack D)
In use
------
/dev/ttyUSB4: 9705: picocom -b 115200 -r -l /dev/ttyUSB4
I gave names (a, b, c, d) to the 4 fixed uarts. Now I look at which
port my serial cable is plugged into - say the 3rd one, which I call c,
and I can fire up picocom with the standard setting using
uart c
Sometimes I can't find a terminal session (too many windows open), so I
use the PID from the In use section of the lsuart output to kill it.
If others have the "where is my USB serial port" problem, I can love up
my shell script (lsuart is a symbolic link to uart), which is around 200
lines of ugly sysfs parsing.
Todd
4. testing
Do you use a specific tool for testing? I have a simple script called
'tbtorture.sh' that I used to 'hammer' my board when I trying to stress
it. (Lately, I've been trying to cause stack overflows on my ARM system
with 4K stacks.) tbtorture is my own tool that I wrote based on
'do_hell' by Ingo Molnar. Unfortunately, Sony's internal distribution
doesn't have all the programs that do_hell called, and I re-wrote
parts of it to correspond to what we have in our distro (pretty
much just busybox and a few other things.)
What is your favorite tool for stress-testing your system?
What is your favorite tool for testing:
file-system performance?
RT performance?
memory utilization?
kernel regressions?
boot time?
Do you use an existing open source test framework? If so, which one?
5. Personal productivity tips
Do you have any tips related to improving your own personal productivity?
I have a certain workflow that I use throughout the week, with my
development task lists. (I'll describe this more at the BOF).
I use elinux.org, StackOverflow and LWN.net a lot, to find
information I need for development tasks (and to keep up with new
developments that I might include in Sony's future products.)
Finally - I am lucky to be able to attend a lot of conferences, where
I can talk to lots of developers and bounce crazy ideas off them.
I had a hallway conversation with Cristoph Hellwig at last year's
ELC Europe - and something he said was brewing in my mind until about
a month ago - when I finally used it on my 4k-stacks project. Conferences
and hallway conversations are like that. It saved me a ton
of time, and gave me just the key to unlock the next step in my project
(but only later when I got to a different area of the problem.)
I attend ELC, ELCE, and LinuxCon US and Japan.
What events would you recommend to people?
What web sites for forums?
What mailing lists?
Any other tips for increasing your productivity developing Linux?
Thanks in advance for any feedback you provide.
If you're coming to Barcelona, make sure to say hi and if
you're not doing something better, come to my BOF the evening
of Monday, November 5th (don't mind the current schedule, my BOF time
is changing.)
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================
_______________________________________________
Celinux-dev mailing list
Celinux-dev@lists.celinuxforum.org
https://lists.celinuxforum.org/mailman/listinfo/celinux-dev
_______________________________________________
Celinux-dev mailing list
Celinux-dev@lists.celinuxforum.org
https://lists.celinuxforum.org/mailman/listinfo/celinux-dev
