Re[8]: SVOC :: Remember, remember, the velvet November


node:	Re[8]: SVOC
template:	4
parent:	Re[7]: SVOC
owner:	ventYl
viewed by:
created:	03.03.2007 - 12:10:53
updated:

cwbe coordinatez:
101
1
102
1546480
1546544
2931877
2933342
2933564
2936548
2936669
2959791
2959859
2961382
2962092

ABSOLUT
KYBERIA

permissions
you:	r,
system:	public
net:	yes

no ano... to by slo a dokonca by to slo IMHO aj velmi jednoducho... akurat.. skor by som na to postavil server priamo v pocitaci (prepojil ho s transportnym serverom, aby to bolo nezavisle od transportnej vrstvy /kabel, iR, Bt/) a so samotnym telefonom vykecaval cez AT prikazy...

000001010000000100000102015464800154654402931877029333420293356402936548029366690295979102959859029613820296209202962095

alebo takto no, zriesit nejaky gsm fileserver ktory by komunikoval cez seriovy port
s telefonom a cez AT prikazy by spolu komunikovali. nejak takto si to predstavujem:

; mount -c {gsmfs /dev/eia0} /mnt/gsm

kde /dev/eia0 (to je seriove rozhranie) mohol byt akykolvek character device

00000101000000010000010201546480015465440293187702933342029335640293654802936669029597910295985902961382029620920296209502962145

v styxe je mozne zriesit nieco take, ze primontujes jeden server a ten trebars mountne nie jedno character device, ale cely adresarovy strom character devicov... akurat... tu sa to dostava do kolizie so samotnou filozofiou distribuovaneho systemu, lebo mas server, ktory remotne riesi zdroje ineho zariadenia. a tam je prave ten problem, ze na telefon sa nedostanes priamo, ale musis vyuzit sluzby transportnej vrstvy, cize samotny gsmfs by nedokazal bezat len tak, ale potreboval by k svojej cinnosti namontovany filesystem s transportnou vrstvou... a neviem, ako rado by sa to malo so vzdialenym montovanim...
ale cez javu ako taku je to na niektorych mobiloch prakticky nerealizovatelna zalezitost

0000010100000001000001020154648001546544029318770293334202933564029365480293666902959791029598590296138202962092029620950296214502962160

to by slo...inferno to zvlada v pohode. prave na tieto veci je urceny

000001010000000100000102015464800154654402931877029333420293356402936548029366690295979102959859029613820296209202962095029621450296216002962174

takze napriklad... gsmfs pouzije bluezfs ako transportnu vrstvu, aby sa dostal k Obex resource telefonu na hoste gsmhost... ja si ten gsmfs namontujem z desktophosta a gsmfs bude v pohode ako transportnu vrstvu aj nadalej pouzivat bluezfs z gsmhostu? alebo to je skor riesene nejako inak a to riesenie mi uslo? :)

00000101000000010000010201546480015465440293187702933342029335640293654802936669029597910295985902961382029620920296209502962145029621600296217402962214

jasne, tak to funguje ako si to popisal ;)

pripadny bluezfs moze bezat na gsmhost ale rovnako moze bezat aj u teba kedze mas pristup na
bluetooth device gsmhosta. gsmfs moze bezat u teba alebo na gsmhost alebo na uplne inom tretom stroji ktory s tym nic nema spolocne. skratka servery resp drivre ktore obsluhuju device sa mozu nachadzat na uplne inych strojoch nez sa nachadza device. radsej uvediem nejaky priklad.

nech na stroji s menom gsmhost je bluetooth device urceny na komunikaciu s mobilom cez bluetooth.
nech tento device sa vola /dev/bz0 (upozornujem ze toto je len fikcia a ziaden bluetooth stack
neexistuje pod infernom). nas stroj "localhost" chce pristupovat k tomuto mobilu.
bluezfs - tento uz neberme do uvahy, mame /dev/bz0 a ten uplne staci.
gsmfs - moze byt fileserver ktory si moze vziat na vstup nejaky character device a na vystupe
ma Styx protokol.

moze to vyzerat nasledovne:
1. gsmfs bezi na gsmhoste, uz je namountovany a mi k nemu pristupujeme skrz melua grid cez adresarovu strukturu v /usr.
napr:

; cd /usr/user1/1/gsm

2. spustime gsmfs u seba a pouzijeme remotny device

; mount -c {gsmfs /usr/user/1/dev/bz0} /mnt/gsm

3. vyhradime si na to nejaky dedikovany treti stroj ktory sa bude starat len o servovanie gsmfs

"treti stroj":

; listen 'tcp!*!gsmport' { gsmfs /usr/user/1/dev/bz0 }

"localhost":

; mount -c "treti stroj" /mnt/gsm

a podobne kombinacie by som tu mohol vymyslat na 100 sposobov

0000010100000001000001020154648001546544029318770293334202933564029365480293666902959791029598590296138202962092029620950296214502962160029621740296221402967170

jaj jasne... usiel mi ten fakt, ze v inferne neexistuje nic, co by nebolo suborom... nakolko bluetooth stack samotny je v linuxe rieseny ako socketove rozhranie