Új hozzászólás Aktív témák

• #18564 coco2 őstag Jester01 #18563

  Új Válasz 2013-11-15 09:56:29 #18564

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  coco2

  őstag

  válasz Jester01 #18563 üzenetére

  Nos, igen, az xy probléma valóban jelentős szokott lenni. Szóval lépek egyet vissza, és megpróbálom kirészletezni az alap problémát.

  Beleütköztem én is egy ilyenbe:
  stackoverflow.com/questions/3085714/accessing-backing-storage-file-from-both-host-machine-and-emulating-machine-when

  Sajnos az én helyzetem annál is bonyolultabb. A "távoli" állomás g_file_storage-en keresztül fat32 filesystemen nyitva akar tartani egy file-t huzamos időn keresztül, amit ha elengedtetek vele, akkor lehal egy olyan folyamat, aminek működnie kell. Sza* az egész, de azzal az oldallal nem tudok mit tenni, pont. A g_file_storage egy olyan önző fajta driver, ami lockolja a block device-t, vagy nem tudom, mit csinál, de mellette nem tudok hozzáférni semmihez. Nem tudom mountolni ugyan azt a block device-t, hogy másik filesystem driverrel hozzáférjek, sőt szektor szintű írás / olvasásra sem tudom megnyitni, mert az open() lefagy. Kizárásos alapon egy olyan block device-ra lesz szükségem, ami hozzáférést enged legalább szektor szinten az eszközhöz akkor is, amikor a g_file_storage fogva tartja.

  (Mostanra azt is átgondoltam, hogy ha azt meg is oldom, aszinkron adat csúszásaim lesznek a fat táblán, a directory bejegyzésekben, az adatszektorokban, ergo egy igen ügyes saját filesystem driverre lesz majd szükségem, de az had legyen az én problémám, és teljesen külön történet. Egyenlőre legyen csak meg a szektor szintű hozzáférés.)

  Block device-okról azt találtam, hogy olyat regisztrálni csak kernel driver tud. A kernel driverek pedig nem pont a legbarátságosabb környezet. Például a kernel fordításkori headerjei kellenek a fordításához, külön működési szabályaik vannak, és minden fejlesztéssel egy apró hiba miatt kernel lefagyást gyárthatok. Szimpatikusabb lenne egy már kész és kitesztelt driver, ami képes proxyzni műveleteket kernel és user szint között - ha van ilyen. Például signalokon keresztül kapok egy pointert lba szektor számmal és adatterülettel, hogy azt az 512 byte-ot írjam fel a drive-ra, vagy olvassam be róla, és amit visszaadok, azt fogja majd a block device is visszaadni a g_file_storage-nak. Valami ilyesmi.

  Létezik ilyen készen, vagy nekem kell majd írnom egyet?

Új hozzászólás Aktív témák