seriove porty

[Dan Lukes]

Jindra Fucik wrote:
>> Konkretne v pripade tveho F81216 sice tak trochu necistym trikem
>> dosahli toho, ze by v systemu tenhle chip mohl byt az ctyrikrat, ale
>> musi to byt prave tenhle chip - nemuze na te adrese kolidovat s nejakym
>> uplne jinym zarizenim.
> 
> ... a nebo to zarizeni musi pouzivat podobnej trik s jinym klicem nez jsou 
> tyhle 4.

	Coz je, priznejme si, spise mene pravdepodobne.

> moje predstava je, ze si udelam vlastni zarizeni - rikejme mu treba 
...
> teda pokud se mi podari ty hinty parsovat

	Na pracovani s hinty jsou v jadre urcite k dispozici nejake funkce. 
Neverim, ze si kazdy ovladac pise vlastni parsovani ...

	Ale jinak mi ta tvoje predstava az tak sympaticka neni. Nevidim duvod, 
proc by uzivatel mel dopredu do souboru psat nejake pevne hodnoty a 
hlidat, ze nejsou pouzite nekde jinde. Tobe je nakonec fuk, na jakych 
konkretnich portech a prerusenich seriak sedi.

	Ten tvuj ovladac by mel najit volnou portovou radu a volne irq, 
nakonfigurovat svaba a vyrobit hint radek, ktery pak pouzije sio ovladac.

> Muzes poradit nezkusenemu, kde by jsi zacal hledat, kam ty radky napsat?

  	Jak kam ?
  	Pises vlastni samostatny modul, ne ?

Zakladem vlastniho modulu pro je radka:

DRIVER_MODULE(f81216, isa, f81216_driver, f81216_devclass, 0, 0);

je to sice zaklad, ale obvykel ho najdes az uplen konci zdrojaku. 
Protoze se odvolava na veci, tkere budes muset definovat nebo 
implementovat vys.

To prvni f81216 je jmeno modulu.

f81216_devclass je odkaz na promennou, kterou nadefinujes takhle:
static devclass_t f81216_devclass;

f81216_driver je odkaz na strukturu, ktera bude vypadat nejak takhle:

static driver_t f81216_driver = {
         "f81216", f81216_methods, sizeof(struct f81216_softc)
};

Tady jsou dva dalsi odkazy - ma tabulku metod a na (tvoji) strukturu, do 
ktere si modul uklada svoje perzistentni data (pokud zadne takove nemas, 
ja ja bych skoro rekl, ze ne, muzes tam napsat nulu)

Tabulka metod vypada takhle:

static device_method_t f81216_methods[] = {
         /* Device interface */
         DEVMETHOD(device_probe,         f81216_probe),
         DEVMETHOD(device_attach,        f81216_attach),
         { 0, 0 }
};


Az sem je to pro kazdu modul vlastne stejne - jen to f81216 by se lisilo 
(a misto 'isa' by bylo pci/eisa/atapci/amr ci neco jineho). I tabulka 
metod by mohla byt rozsahlejsi, ale ty potrebujes jen ty dve metody uvedene.

A teprve ted zacina tvoje skutecna prace - musis napsat ty dve metody.

Prvni:
static int f81216_probe(device_t dev)

bude system volat pro ruzna zarizeni, u kterych usoudi, ze by je mohl 
tento ovladac ovladat - a na tobe je vratit ENXIO pokud myslis, ze tohle 
zarizeni ty ovladat neumis a BUS_PROBE_DEFAULT pokud ho ovladat umis.

Vzhledem k tomu, ze na ISA sbernici te bude volat jen tehdy, kdyz tak 
usoudi z hint souboru je to skoro o tom, ze nic resit nebudes a budes 
vzdy vracet uspech.

Az skonci tahle faze, tak system ze vsech ovladacu, ktere se k danemu 
zarizeni nabidly vybere jeden a u nej zavola metodu attach:

static int f81216_attach(device_t dev)

a to je ta funkce, ve ktere udelas uplne vsechno, co chces. Mimo jine 
bys mel od systemu regulerne naalokovat port 43, ktery pouzivas. A pak 
nakonfigurovat ten chip tak, jak potrebujes. A to by melo byt vsechno.

Jelikoz i v jadre muzes celkem normalne pouzivat printf, mas volne pole 
co se ladicich tisku tyce. Ano, modul si nepustis (alespon en snadno) 
pod debuggerem, takze pokud jsi odchovan uz ciste interaktivnimi 
metodami ladeni, tak budes mit trochu problem si zvyknout. Pokud jsi uz 
alespon nekdy ladil off-linove tak by to melo byt zcela hladke.

Kdyz na neco narazis, zkus se zeptat. Nemam jasno, jestli do konference, 
protoze psani modulu by to mohl zajimat jeste nekoho jineho, nebo primo 
me, protoze takhle odborne veci tu nikoho nezajimaji. Tak si to u 
konkretniho dotazu rozmysli sam.

							Dan