franciscoalecrim.com

Baseado em Documentation/SubmittingPatches do código fonte do kernel Linux

1 – Criando e enviando suas mudanças

diff -pruN arvore_original arvore_modificado > meu_patch

2 – Descreva o suas alterações

Seja simples e objetivo, descrevendo os detalhes tecnicos.

3 – Separe as alterações

Se você deseja fazer uma correção em um driver A e depois
uma outra alterção em um driver B. Separe em 2 patches para ficar mais organizado.

4 – Verifique o estilo

Verifique o estilo de seu patch. Utilize scripts/checkpatch.pl para checagem.

5 – Selecione o destino

Procure os mantenedores e envie os patches para as pessoas corretas.

6 – Copie a lista

CC a mailing list.

7 – No MIME, no links, no compression, no attachments. Just plain text.

Não preciso explicar mais nada.

8 – Limite de tamanho

Se o seu patch é maior que 40kb, é melhor deixar ele na web e mandar a URL.

9 – Kernel version

Mandar a versao do kernel, caso não seja a current.

10 – Não perca a coragem, re-envie.

11 – Inclua PATCH no subject.

12 – Assine seus patches.

13 – Acked-by para o revisor.

14 – O formato canonical

Minha dica pra isto é USE GIT. Ele já deixa os patches no formato.

git-format-patch -1

Tips and tricks
1 – Leia o CodingStyle
2 – #ifdefs são feios
3 – static inline é melhor que macro
4 – “Faça as coisas o mais simples possível,mas não mais simples” Albert Einstein

Baseado em Documentation/CodingStyle do kernel do Linux

1 – Indentação de 8 characteres

Exemplo:

if (x is true) {        we do y}

2 – Linhas podem possuir apenas 80 colunas

Exemplo:

 printk(KERN_WARNING "Warning this is a long printk with "   "3 parameters a: %u b: %u "   "c: %u \n", a, b, c);

3 – Localização de Chaves
Localizacao das chaves deve ser na ultima coluna do primeira linha e na
primeira coluna da ultima linha

if (x is true) {        we do y}

4 – Nomes de variaveis

LOCAIS devem ser curtas e simples
exemplo: tmp
GLOBAIS devem ser bem descritas, evitando contrações
exemplo: count_active_users()

5 – Evita typedefs.

Evite utilizar typedefs para ponteiros e estruturas, tornando o código
mais complicado.

Exemplo: “struct virtual_container *a;” é muito mais claro do que “vps_t a;”

6 – Funtions devem ser curtas e claras.

Condições:

  6.1 - Dimensões (80x24)  6.2 - Não mais do que 5-10 variáveis.  6.3 - Sem isto, você provavelmente está fazendo algo errado.

7 – Centralizar saída de funções.

GOTO não é péssima prático como muitos dizem.

Exemplo:

int fun(int a){       int result = 0;       char *buffer = kmalloc(SIZE);

       if (buffer == NULL)               return -ENOMEM;

       if (condition1) {               while (loop1) {                       ...               }               result = 1;               goto out;       }       ...out:       kfree(buffer);       return result;}

8 – Comentar é bom, mas NÃO EXAGERE.

Seu código deve ser claro, por isto não coloque no comentário explicações
sobre como seu cógigo funciona.
Veja: Documentation/kernel-doc-nano-HOWTO.txt

9 – Dica pro pessoal que usa emacs.

Eu uso VIM.

10 – Configuração no Kconfig

Definições são indentadas com TAB e help com 2 espaços.

11 – Estruturas de dados.

No kernel não tem garbage collector para corrigir suas porcarias.
Se você sujou então vai ter que limpar. Não esqueça que sua estrutura
pode ser acessada por outra thread, por isto lembre de realizar controle
ou você terá um bug.

12 – Macros
Macros devem ser escritas em letras MAIUSCULAS.

13 – Printing messages

Cuidados com erros de escrita nas mensagens.

14 – Alocando memoria

O kernel possui diversas formas de alocação de memória. A forma mais
recomendada de passar o tamanho memória que deve ser alocado é:

p = kmalloc(sizeof(*p), …);

15 – Funções inline

Neste tópico ele desistimula a utilização de funções inline.

16 – Funções retornam valores ou nomes

0 = sucesso
-Exxx = falhou

17 – Não re-invente macros

18 – Editor modelines

Não adicionei configurações para o seu editor em código fontes.

Comentários e correções são bem vindos em alecrim@gmail.com

Hi all,

I’m working with an OMAP1610 H2 and it was taking a long time to load and uncompress kernel. Eduardo recommended me some things to be done.

BE CAREFUL –
I’M NOT RESPONSIBLE FOR YOUR ACTS. YOU CAN MISS INFORMATION IF YOU DO NOT FOLLOW THE STEPS CORRECTLY.

1 – Upgrade u-boot

- Install scratchbox for cross-compilation.

- Download the last version of u-boot.

- Configure and Compile u-boot

[sbox-arm: ~/applications/u-boot-1.3.0] > make omap1610h2_config && make

- Copy the new u-boot.bin to your tftpboot directory(details here)

$ cp /scratchbox/users/alecrim/home/alecrim/applications/u-boot-1.3.0/u-boot.bin /tftpboot

- Using minicom, access the current u-boot prompt and load the new u-boot

OMAP1610 H2 # tftp 0×10000000 u-boot.bin
TFTP from server 10.0.0.1; our IP address is 10.0.0.2
Filename ‘u-boot.bin’.
Load address: 0×10000000
Loading: ###################
done
Bytes transferred = 93568 (16d80 hex)

The bold number is import, save it.IT’S YOUR U-BOOT HEXADECIMAL!!

- Unlock the flash memory, erase a sector, copy the new u-boot.bin and lock the flash again.

DANGEROUS!! TAKE CARE!!DANGEROUS!! TAKE CARE!!DANGEROUS!! TAKE CARE!!DANGEROUS!! TAKE CARE!!

REPLACE THE BOLD HEXADECIMAL (16d80)!!! PUT YOUR U-BOOT HEXADECIMAL !!!

OMAP1610 H2 # protect off 00000000 0001ffff
Un-Protected 1 sectors

OMAP1610 H2 # era 00000000 0001ffff

Erasing sector 0 … done
Erased 1 sectors

OMAP1610 H2 # cp.b 0×10000000 0×00000000 0x16d80
Copy to Flash…\done

OMAP1610 H2 # protect on 00000000 0001ffff
Protected 1 sectors
OMAP1610 H2 #

Now, you can restart your board and pray for some output on your serial.

references:
http://tree.celinuxforum.org/CelfPubWiki/OSK_2fuboot
http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigationId=11994&path=templatedata/cm/product/data/omap_1610
http://tree.celinuxforum.org/CelfPubWiki/OSK

Hi all,

+

I tested SDIO GPS with a OMAP1710 and it works. Many phones and internet tablets are based on this platform. The steps below show the procedures I’ve done:

== KERNEL SIDE ==

Compile a new kernel from linux-omap with some additional features activated.

Device Drivers  ---><*> MMC/SD card support  --->   SDIO UART/GPS class support

Boot your device with this feature.

Maemo-omap1710:~# modprobe sdio_uart

Plug your SDIO card and the message below will be printed.

mmc_slot (GPIO 193) is now openmmci-omap mmci-omap.1: cover is now closedmmci-omap mmci-omap.1: command timeout (CMD8)mmc0: new SDIO card at address f111

The entry /dev/ttySDIO0 should be created.

== USER SIDE ==

I’m using GPSd to test it. Download the last version, compile and install on my device using scratchbox.

Start the GPS daemon

Maemo-omap1710:~# gpsd -N -n -D 2 /dev/ttySDIO0 &Maemo-omap1710:~# gpsd: launching (Version 2.34)gpsd: listening on port 2947gpsd: running with effective group ID 0gpsd: running with effective user ID 0gpsd: opening GPS data source at '/dev/ttySDIO0'gpsd: speed 4800, 8N1gpsd: garmin_gps not active.gpsd: gpsd_activate(1): opened GPS (4)gpsd: SiRF packet seen when NMEA expected.gpsd: FV  0x06: Firmware version: MEW-05-00-030627Wgpsd: FV  0x06: Firmware version: 2.4.02.02 0800003f21

Get you position:

Maemo-omap1710:~# gpspipe -rgpsd: client connect on 7gpsd: client(0) turned on raw modeGPSD,R=1$GPRMC,000004,V,0000.0000,S,00000.0000,W,0.0000,0.000,090602,,*3C$GPGSA,A,1,,,,,,,,,,,,,,,,*32$GPRMC,000005,V,0000.0000,S,00000.0000,W,0.0000,0.000,090602,,*3D$GPGSA,A,1,,,,,,,,,,,,,,,,*32$GPRMC,000006,V,0000.0000,S,00000.0000,W,0.0000,0.000,090602,,*3E$GPGSA,A,1,,,,,,,,,,,,,,,,*32$GPRMC,000007,V,0000.0000,S,00000.0000,W,0.0000,0.000,090602,,*3F$GPGSA,A,1,,,,,,,,,,,,,,,,*32$GPRMC,000008,V,0000.0000,S,00000.0000,W,0.0000,0.000,090602,,*30$GPGSA,A,1,,,,,,,,,,,,,,,,*32

The filesystem used is based on Maemo.