On Tue, Oct 23, 2012 at 09:35:26AM -0700, 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?
git branch -av --contains gitk --all git log --graph --pretty=oneline --abbrev-commit git tag -a git format-patch git diff git blame git cherry-pick git merge-base git rebase -i git commit --ammend git --first-parent --pritty=oneline sha1..sha2 git cherry stable/linux-3.0.y | head git cherry stable/linux-3.0.y | wc handy for identifying the AOSP/kernel/common android-3.0 changes made to linux-stable. > 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? > > 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. We have some python scripts for identifying changes that touch upstream and non-upstream files at the same time. (those cause problems for us WRT baseline updates from linux-stable or android-3.0 and are harder to revert when conflicts happen so we discourage such changes) We have some python scripts for scanning gerrit changes that are in a specified project with a specified number of +1s that are getting close to being ready to merge such that I can look at them before some bozo actually merges it without me looking at it. We have a customized repo program that generates a format-patch out put given the output of repo manifest -r -o snapshot.xml that helps identify day to day changes to an android tree under development. > 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? ftrace! monsoon battery simulator (looking at the 1ms samples of the power used at the battery port tells me about as much as power top and other p and c state tracing tool.) we use debugfs a lot too. > 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. Monsoon battery emulator working ADB, and serial port are my first order things. > 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 > android specific: source build/envsetup.sh then mgrep and godir are the bomb! > 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? ELC and Plumbers > > What web sites for forums? > > What mailing lists? > > Any other tips for increasing your productivity developing Linux? use ctags and cscope --mark > > 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
