Tim's Tips and Tricks

From eLinux.org
Revision as of 11:37, 23 October 2012 by Tim Bird (talk | contribs)
Jump to: navigation, search

Sources

Ideas for individual tips

Git tips

  • Show when a commit was entered in the tree: "git describe <commit>"
  • Show the version of software where a change first appeared: "git describe --contains <commit>"
  • git log <file> # narrow scope of log
    • git log <dir>
    • git lg [<dir_or_file>] # nice summary
      • alias.lg=log --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr %an)%Creset' --abbrev-commit --date=relative
      • how to do a git alias, with colors!
  • find the commit for a specific line in a file: "git annotate <file> | grep <regex_of_line>"
    • Then do: "git show <commit_of_interest>"
    • This is good to find out: why is it here? who did this?, when did it get changed to this?
  • git bisect
  • git proxy (finally!!)

patch management

  • quilt - patches as first class objects
    • git for development work, then convert to quilt patches
    • git rebase --interactive
  • precommit - quilt pop -a, basediff, quilt push -a, scripts/fix-filemodes.sh
  • diffinfo - my own tool for managing patches
    • splitting a patch: splitpatch - tool to break patches apart

source finding

  • cgrep, mgrep, confgrep, kgrep, armcgrep, jgrep - scan C code, Makefiles, .config, Kconfig, arm C files, and java code, respectively for a search pattern
    • thin wrappers on 'find . [some conditions] -exec egrep $1'
  • finds - find a string in a set of files (Credit to Todd Fischer of RidgeRun)

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

kernel debugging

  • use of fs/sync.c:SYSCALL_DEFINE0(sync) for user-space triggered printks
  • use of qemu for kernel debugging

testing

  • tbtorture.sh - for stress testing

board handling

  • consistent board setup (including remote access)
    • connections: serial, network, power (web-based control) [images]
      • power port controller [image]
    • Usually use tftp boot kernel, with NFS rootfs
      • but can do other setups: feed kernel through serial line, put kernel on SD card using known-good kernel, etc.
  • ttc - command line tool for board control
    • abstracts differences between boards
    • allows for board sharing (ttc reserve)
    • everything is scritable, and remotable
    • object-oriented: inheritance to quickly modify attributes of a board "class"
    • items abstracted:
      • kernel source, toolchain, architecture, defconfig, kernel image name, tool paths
      • kernel build, install
      • board console access, reboot, run arbitrary commands, reset
      • filesystem access (copy from/to)

Finding the ttyUSB* for a board connected to a multi-port hub: (Credit to Todd Fischer of RidgeRun): 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.


personal productivity

  • my workflow:
    • different day for each topic area
    • today script
  • multiple todo's, NOTES all over the place (several in each work directory)
    • must do a context save in each directory, before moving on
    • git branch is essential - commit changes (even if flaky) before moving on
  • my favoriate mailing lists:
    • sorry, but linux-embedded seems to be dead
    • lkml, linux-arm, yocto-devel
    • celinux-dev
  • attend conferences, talk to smart people
  • conferences I attend:
    • ELC, ELCE, linuxcon US, Linuxcon Japan, Linuxcon Europe (by serendipity)
    • what about plumbers?? other regional events??