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?

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.

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
=============================

On Tue, Oct 23, 2012 at 09:35:26AM -0700, Tim Bird wrote:

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.

We have a nice git+quilt feature in ptxdist:

- You can configure a switch to extract quilt series into git
repositories: that way ptxdist extracts a tar ball, checks the initial
state into a git repository and applies the quilt series with git.

- If you hack on a component, just use git the way it is usually used.

- When you are ready, ptxdist has automatically added a new command
'git ptx-patches' into that repository, which beams the current patch
series from git back into a quilt series in ptxdist.

- While doing so, it removes the git version (so that you don't get
changes in the patches when different people use different git
versions) and it removes the sha sums.

Very convenient, if you use ptxdist :-)

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?

genimage: create flash/sd/hd images
http://www.pengutronix.de/software/genimage/download/

memedit: hack your memory mapped registers
http://www.pengutronix.de/software/memedit/downloads/

ptx_ts: timestamp your <anything>
http://www.pengutronix.de/software/ptx_ts/index_en.html

3. development practices:

Mostly printk as well.

With ptxdist, you can build your BSP for a qemu based platform instead
of the real target, which makes it easy to hack on anything but the
kernel without going onto the target.

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!).

Same here; we have a separate lab net for that, with the big compile
machines having access to it as well :)

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).

These are in the PTX remotelabs (the 19" ones):
http://www.gude.info/index.php?lng=1§ion=products&product=epcalg

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.)

We basically have 'ptxdist test <testscript>' which is a remote control
mechanism in ptxdist which gives you access to the target via

- ssh
- rsh (with urshd, which is realtime-aware)
- serial
- serial-over-ethernet (Moxa)

The core mechanism is scripted in kermit, but the actual test scripts
are plain shell code. You can run shell commands on the test host and on
the target, and you can basically do anything with the test results.

rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

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@...
https://lists.celinuxforum.org/mailman/listinfo/celinux-dev

On 10/23/2012 11:04 AM, Todd Fischer wrote:

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

This looks useful.

I do something similar with the kernel. I have
a small one-line wrapper called armcgrep, which greps only the files in
the arch/arm section of the kernel source tree, and only those
with filenames matching the pattern "*.[chS]". Once things
are in the page cache, it works pretty fast.

'finds' looks similar, but it also omits some areas, and includes
things like Kconfig and others. I need to mentally digest all
the 'find' magic in it...

Thanks. Great tip!

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.

Wow. I have this exact problem on one of our lab hosts, which has
about 10 boards attached. We don't power cycle it very often,
but when we do it sometimes messes up the USB settings, and we have
to go manually experiment to figure out which boards are attached
to which ttyUSB's again. It's a royal pain.

I'd be interested in seeing your shell script, ugly sysfs parsing and all.

Just out of curiosity - why picocom?

I've never heard of it. Is it just tradition or do you have a reason
to use it over minicom?

Thanks!
-- Tim

=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================

On Tue, 23 Oct 2012 11:20:41 -0700, Tim Bird wrote:

On 10/23/2012 11:04 AM, Todd Fischer wrote:

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

This looks useful.

I do something similar with the kernel. I have
a small one-line wrapper called armcgrep, which greps only the files
in the arch/arm section of the kernel source tree, and only those
with filenames matching the pattern "*.[chS]". Once things
are in the page cache, it works pretty fast.

'finds' looks similar, but it also omits some areas, and includes
things like Kconfig and others. I need to mentally digest all
the 'find' magic in it...

Note also that you can use 'git grep', that will only grep the source
files that are under version control, skipping all object files and
other generated files you may have in your tree, if you're not doing
out of tree builds. I use 'git grep' routinely.

Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

On Tue, 23 Oct 2012 09:35:26 -0700, Tim Bird wrote:

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.

For sure on my end the most useful git commands are:

* git rebase -i, which I use to rework series of patches. No need for
quilt, stgit, topgit or who knows what. git rebase -i is really a
very powerful way to organize and rework a set of patches, going
through multiple iterations.

* git add -p, which allows to selectively stage parts of a file
changes for the next commit.

Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

On 09:35 Tue 23 Oct , 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.

git rebase -i

also tig

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.

Anyone else do something similar?

yeah everyday that why I use ser2net with barebox and bootp

so I just have to use script to generate my kernel plus home made power swith
and then no need known how to manage it

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?

I use jtag everday

it's really good but as example whe you need to dump a big quantity of data
debugfs is more usefull dito when it's come during data high speed transfer

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.

I'm using home made ser2net servers based on at91

I use network boot everyday via bootp with vendor_id, class_i and user_class
to describe which kernel I want to use so no need to care too much

I use also pxe

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?

boot time scope or logical analyser I buy here in Shanghai

Do you use an existing open source test framework? If so, which one?

I was investigating autotest but complex lava worse

so I use home made stuff with expect

Hi Todd,

Am 23.10.2012 20:04, schrieb Todd Fischer:

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

You can likely avoid that by having a file:

/etc/udev/rules.d/99-usb-serial.rules

with an entry like:

SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="FTFL3WUV", SYMLINK:="myporta"

and then access the device via its symbolic link as:

/dev/myporta

Greetings,
Frieder

On Tue, Oct 23, 2012 at 8:27 PM, Thomas Petazzoni
<thomas.petazzoni@...> wrote:

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

This looks useful.

I do something similar with the kernel. I have
a small one-line wrapper called armcgrep, which greps only the files
in the arch/arm section of the kernel source tree, and only those
with filenames matching the pattern "*.[chS]". Once things
are in the page cache, it works pretty fast.

'finds' looks similar, but it also omits some areas, and includes
things like Kconfig and others. I need to mentally digest all
the 'find' magic in it...

Note also that you can use 'git grep', that will only grep the source
files that are under version control, skipping all object files and
other generated files you may have in your tree, if you're not doing
out of tree builds. I use 'git grep' routinely.

Yeah. For Tim's use case:

git grep <pattern> -- "arch/arm/*.[chS]"

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

On Tue, Oct 23, 2012 at 8:29 PM, Thomas Petazzoni
<thomas.petazzoni@...> wrote:

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.

For sure on my end the most useful git commands are:

* git rebase -i, which I use to rework series of patches. No need for
quilt, stgit, topgit or who knows what. git rebase -i is really a
very powerful way to organize and rework a set of patches, going
through multiple iterations.

Agreed. Once you start using "git rebase -i", you start wondering how you
ever could have lived with quilt.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

On 10/23/2012 11:42 AM, Geert Uytterhoeven wrote:

On Tue, Oct 23, 2012 at 8:27 PM, Thomas Petazzoni
<thomas.petazzoni@...> wrote:

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

This looks useful.

I do something similar with the kernel. I have
a small one-line wrapper called armcgrep, which greps only the files
in the arch/arm section of the kernel source tree, and only those
with filenames matching the pattern "*.[chS]". Once things
are in the page cache, it works pretty fast.

'finds' looks similar, but it also omits some areas, and includes
things like Kconfig and others. I need to mentally digest all
the 'find' magic in it...

Note also that you can use 'git grep', that will only grep the source
files that are under version control, skipping all object files and
other generated files you may have in your tree, if you're not doing
out of tree builds. I use 'git grep' routinely.

Yeah. For Tim's use case:

git grep <pattern> -- "arch/arm/*.[chS]"

Actually I mis-stated the case a bit. I'm searching the whole kernel
tree, but only including one architecture directory, arch/arm, in the search.
This is primarily to omit extraneous matches for other architectures (which I
might not be interested in at the moment). The way the kernel is written,
there are often arch-specific functions or structures that show up multiple
times if you don't filter down to one arch.

Here's my solution (armcgrep):

#!/bin/sh
find . -path "./.pc" -prune -o -name "*.[chS]" | xargs egrep "$1" | grep -v arch/[^a] | grep -v arch/a[^r]

I know there must be a simpler way to filter out non-arm arches than with
two "grep -v"s (anyone??), but it works... :-)

I have to prune out .pc because I'm using quilt and would otherwise get a lot
of matches in that sub-directory.
-- Tim


=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================

On 10/23/2012 11:43 AM, Geert Uytterhoeven wrote:

On Tue, Oct 23, 2012 at 8:29 PM, Thomas Petazzoni
<thomas.petazzoni@...> wrote:

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.

For sure on my end the most useful git commands are:

* git rebase -i, which I use to rework series of patches. No need for
quilt, stgit, topgit or who knows what. git rebase -i is really a
very powerful way to organize and rework a set of patches, going
through multiple iterations.

Agreed. Once you start using "git rebase -i", you start wondering how you
ever could have lived with quilt.

It must just be me. I've tried "git rebase -i" a few times, and I
always manage to completely mess up my patches. If I hadn't done a git stash,
I would have been dead. I probably just need to muscle my way through
it a few more times until I'm comfortable with it, but I must be
doing something wrong...
-- Tim

=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================

On Tue, 23 Oct 2012 11:55:11 -0700, Tim Bird wrote:

Agreed. Once you start using "git rebase -i", you start wondering
how you ever could have lived with quilt.

It must just be me. I've tried "git rebase -i" a few times, and I
always manage to completely mess up my patches. If I hadn't done a
git stash, I would have been dead. I probably just need to muscle my
way through it a few more times until I'm comfortable with it, but I
must be doing something wrong...

Yes, it takes a little bit of time to get used to 'git rebase -i'.
Having someone explaining you the workflow is most likely the best
thing: in no more than 30 minutes to an hour, you'll have fully
understood the power of 'git rebase -i'.

However, once you've understood how it works, believe, you'll never get
back to quilt, and you will pester against any version control system
that doesn't provide a tool similar to interactive rebasing.

Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

On Tue, Oct 23, 2012 at 3:55 PM, Tim Bird <tim.bird@...> wrote:

On 10/23/2012 11:43 AM, Geert Uytterhoeven wrote:

On Tue, Oct 23, 2012 at 8:29 PM, Thomas Petazzoni
<thomas.petazzoni@...> wrote:

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.

For sure on my end the most useful git commands are:

* git rebase -i, which I use to rework series of patches. No need for
quilt, stgit, topgit or who knows what. git rebase -i is really a
very powerful way to organize and rework a set of patches, going
through multiple iterations.

Agreed. Once you start using "git rebase -i", you start wondering how you
ever could have lived with quilt.

It must just be me. I've tried "git rebase -i" a few times, and I
always manage to completely mess up my patches. If I hadn't done a git stash,
I would have been dead. I probably just need to muscle my way through
it a few more times until I'm comfortable with it, but I must be
doing something wrong...

Tim,

I'm very newbiew around here, and being new to kernel, I've missed the
quilt age.

That said, "git rebase -i" is one of the most frequent stuff I do when
preparing patchsets...

Note that it's very flexible...

git rebase -i HEAD^

git rebase -i HEAD^^^

git rebase -i ba06efcc4

git rebase -i linuxtv/staging/for_v3.8

Once there you can even reorder commits, bringing some ancient commit to HEAD
and then fix with "git commit --amend".

Of course, I've messed patches a few times, but it's until you get
used to it ;-)

My two cents,

Ezequiel

On 10/23/2012 11:40 AM, Frieder Ferlemann wrote:

Hi Todd,

Am 23.10.2012 20:04, schrieb Todd Fischer:

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

You can likely avoid that by having a file:

/etc/udev/rules.d/99-usb-serial.rules

with an entry like:

SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="FTFL3WUV", SYMLINK:="myporta"

and then access the device via its symbolic link as:

/dev/myporta

Oh - that's handy! I've been using my 'ttc' program to abstract out
the ttyUSB associated with a board, so I can just do something like:
'ttc panda console'. But my mappings would not break (as often?)
if I used the udev rules.

My excuse for not doing this earlier is that ttc precedes udev by
several years

Thanks.
-- Tim

=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================

On 10/23/2012 11:33 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:

git rebase -i

that's another vote: :-)

also tig

I've never even heard of 'tig', and lo, after
"sudo apt-get install tig", I've got what looks to
be a very handy text-mode browser for git!

Thanks! I'll definitely play around with this one
some more.

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?

yeah everyday that why I use ser2net with barebox and bootp

so I just have to use script to generate my kernel plus home made power swith
and then no need known how to manage it

Hmmm. Haven't heard of this one either. I need to go
check it out.

I'm using home made ser2net servers based on at91

I use network boot everyday via bootp with vendor_id, class_i and user_class
to describe which kernel I want to use so no need to care too much

I use also pxe

Yeah. I mostly use tftpboot with dhcpd dishing out a custom
kernel (and rootfs dir) for each board based on MAC address.
(using the bootp protocol? I can't remember which part of the
exchange is dhcp and which part is bootp).

Are you using a dedicated bootp server, or just
run-of-the-mill dhcpd here?

I haven't done much with pxe. I'm not even sure I
know the difference between PXE and bootp.


Thanks for the feedback. I learned some new things already... :-)
-- Tim

=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================

On Tue, Oct 23, 2012 at 09:09:04PM +0200, Thomas Petazzoni wrote:

It must just be me. I've tried "git rebase -i" a few times, and I
always manage to completely mess up my patches. If I hadn't done a
git stash, I would have been dead. I probably just need to muscle my
way through it a few more times until I'm comfortable with it, but I
must be doing something wrong...

Yes, it takes a little bit of time to get used to 'git rebase -i'.
Having someone explaining you the workflow is most likely the best
thing: in no more than 30 minutes to an hour, you'll have fully
understood the power of 'git rebase -i'.

However, once you've understood how it works, believe, you'll never get
back to quilt, and you will pester against any version control system
that doesn't provide a tool similar to interactive rebasing.

Ack.

"git add -p" is also pretty useful in the context of sorting work and
rebaseinteractiveing ;) it into proper patches.

rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

On Tue, Oct 23, 2012 at 12:48:57PM -0700, Tim Bird wrote:

I use also pxe

Yeah. I mostly use tftpboot with dhcpd dishing out a custom
kernel (and rootfs dir) for each board based on MAC address.
(using the bootp protocol? I can't remember which part of the
exchange is dhcp and which part is bootp).

Are you using a dedicated bootp server, or just
run-of-the-mill dhcpd here?

I haven't done much with pxe. I'm not even sure I
know the difference between PXE and bootp.

Another nice thing if you work with (recent) ptxdist and with barebox:
Barebox is not only able to load a kernel via tftp, but also via NFS.
And ptxdist builds a userspace nfs server. So you can remote boot your
target without having to install any infrastructure component (like a
TFTP server) and without root access. That's especially nice if you have
to deal with strange $BIG_COMPANY network setups :)

rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

On 10/23/2012 01:01 PM, Robert Schwebel wrote:

On Tue, Oct 23, 2012 at 12:48:57PM -0700, Tim Bird wrote:

I use also pxe

Yeah. I mostly use tftpboot with dhcpd dishing out a custom
kernel (and rootfs dir) for each board based on MAC address.
(using the bootp protocol? I can't remember which part of the
exchange is dhcp and which part is bootp).

Are you using a dedicated bootp server, or just
run-of-the-mill dhcpd here?

I haven't done much with pxe. I'm not even sure I
know the difference between PXE and bootp.

Another nice thing if you work with (recent) ptxdist and with barebox:
Barebox is not only able to load a kernel via tftp, but also via NFS.
And ptxdist builds a userspace nfs server. So you can remote boot your
target without having to install any infrastructure component (like a
TFTP server) and without root access. That's especially nice if you have
to deal with strange $BIG_COMPANY network setups :)

Interesting... That's something else to go look at.

Thanks.
-- Tim

=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================

Hi Tim,

Am 23.10.2012 20:20, schrieb Tim Bird:> On 10/23/2012 11:04 AM, Todd Fischer wrote:

/dev/ttyUSB4: 9705: picocom -b 115200 -r -l /dev/ttyUSB4

Just out of curiosity - why picocom?

I've never heard of it. Is it just tradition or do you have a reason
to use it over minicom?

I prefer picocom (36656 byte stripped) because minicom (192568 byte stripped)
does not offer the functionality I need.


While picocom knows cr lf mappings like:

--imap <map> (input mappings)
--omap <map> (output mappings)
--emap <map> (local-echo mappings)
<map> is a comma-separated list of one or more of:
crlf : map CR --> LF
crcrlf : map CR --> CR + LF
igncr : ignore CR
lfcr : map LF --> CR
lfcrlf : map LF --> CR + LF
ignlf : ignore LF

Minicom only seems to offer:
A Toggle 'Add Linefeed' on/off. If it is on, a linefeed is added before every carriage return displayed on the screen.

Which is an _extremely_ short list of options and not what I need.
Out of my head I think I need "--imap lfcrlf".


I'd be happy if minicom could do it as well.

Greetings,
Frieder