I forgot pytimechart as a common ftrace tool I use. --mark
> -----Original Message----- > From: mark gross [mailto:mark.gr...@intel.com] > Sent: Wednesday, October 24, 2012 7:03 AM > To: Tim Bird > Cc: CE Linux Developers List > Subject: Re: [Celinux-dev] Embedded Linux tips and tricks?? a bit of a > survey... > > 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
