ようこそ上級ユーザーさん!

You are here, because you do not need the guide tree spreading from user.beginner any longer and want to learn more about embedded systems in general, OpenWrt in particular and maybe get involved. If you are not, well, go away.

システムの構成要素

Embedded Linux

組み込みLinux システムは、主に以下の4つの要素で構成されています:

  1. ツールチェイン (which usually contains an integrated C standard library) to build (= cross-compile) from sources
  2. ユーザースペース: BusyBoxdropbearのような様々なユーザースペース・プログラム

OpenWrt

  • ビルド環境: OpenWrt Buildroot
  • いくつかのブートローダー: bootloader
  • メインラインの Linux カーネル: at buildtime, it is being downloaded from http://kernel.org/ and several patches are being applied. Patches are being written and maintained at OpenWrt, e.g. patches for lantiq, until they get mainlined
  • ユーザースペース: Busybox, opkg and a repository of about 2000 packages (including GNU tools just in case busybox does not behave like you want it to)

トピックス

FAQ

The browser https://dev.openwrt.org/browser is not only to look at the source code without actually downloading it, but mainly to document changes. If, for example you suddenly miss the packages kmod-fs-ext2 and kmod-fs-ext3 use the search to see when and possibly why these packages are no longer available

ソースコード

You can always download the entire source code and watch it in your favorite editor.
If you merely want to have a look at it, there is software for this purpose as well, i.e. OpenGrok, LXR Cross Referencer, etc.

You can also read about changes without having to look at the source code:

Developing

You may find further help with this here:

テスト

testing

Besides contributing code or helping to document things, you can also help a lot by testing

On Testing

In a perfect world you have full-time developers the do the developing and testing themselves. They write the damn code, they should know best, what they changed, when they changed it, what this could affect and thus are the most efficient testers. Dependent on what software is being developed, you will also employ testers. They do not necessarily be programmers (sic!) and also a lot cheaper then those but represent the user. Professional testers do exist. To develop a computer game, you need a lot of good professional testers. (Currently many games developing companies have switched to a procedure called public beta testing. To save on money and also for publicity.) For a office program you need less testers and for a software like OpenWrt, which is in fact an OS, even less, and different, though it's still good to have some. In this perfect world, both, developer and tester are happily employed and do talk to each other as often as needed.

In a realistic world you have less of everything.

In the real world you have unpaid developers and unpaid testers, coming from totally different cultural backgrounds, speaking unrelated languages, with some age differences, differences in skill, knowledge, understanding and interest. Different mentalities… Well, … welcome.

By simply utilizing the software and supplying some significant bug-report when you encounter a bug, you are already helping. But if you have the time and the will you could help with some extended testing.

For this it is essential to understand the development process:

Also bear in mind, that OpenWrt supports about 20 distinct hardware platforms. Decide what you want to go after.

Of course not the entire source code changes every three days, so there is no real point in testing everything every three days.

You could rather look the changes here: https://dev.openwrt.org/browser and check only the parts that have been altered. Or you rather subscribe to the commits mailing list: https://lists.openwrt.org/mailman/listinfo/openwrt-commits and receive a mail for every change.

Testing en passant

(En passant) Let's say you have one device you deploy as a NAT home router. Even though you could be perfectly happy with the current stable release (OpenWrt 10.03 'Backfire') you could still decide to install OpenWrt trunk 'Attitude Adjustment' on it instead. You could then decide to do this every now and then (maybe once a month) when you have the time for installing and for some (proper) testing.

So when you have the time and lust for some tinkering, either download the current build offered for download (dependent on the platform every couple of days a new one) or obtain the most current code through SVN and compile it. After installation, take some time to perform testing procedures and report bugs. Done.

What to test for? Test the things you are using. No biggie. The point here is, that you do use trunk, where the actual development is going on, and also that you flash the newest version on now and then (once a month, one every two weeks, how often you want) and do take some time and describe bugs.

Dependent on what device you have, it is most advisable to have a serial cable ready.

Mesh networking

Sadly there are some basic articles only, regarding this very interesting possibility:

There is a own independent project concerning itself with this matter, it's called Freifunk. They also provide some modified OpenWrt version for this purpose: An older one based on White Russian, called Freifunk Firmware and the newer one called FFLuci based on current OpenWrts.

Back to top

jp/doc/howto/user.advanced.txt · Last modified: 2012/03/29 08:54 by matsuk