Linux: directe, rauwe, absoluut unbuffered disk access

[Sprite_tm]

Ten eerste: wat wil ik:
Ik heb bij meneer Bart Smit een leuk digitaal fotolijstje annex sleutelhanger gehaald. 128x128 pixels, maar liefst twee hele megabytes aan RAM, een processor van 2 decennia geleden... ach, voor een tientje mag ik niet klagen De software is, as always, een Windows-hotsie-flotsie-dingetje. Ik wil het ding eigenlijk compleet zelf aansturen, en om dat te kunnen doen heb ik als eerste eigen software daarvoor nodig. Omdat mijn main platform eigenlijk Linux is, gaat stap 1 een Linux lees-en-schrijf-progsel zijn.

Ik heb dus zitten uitvogelen hoe het onder Windows werkt. Nou, het blijkt dat het device zich als een standaard mass-storage-device voordoet. Dat is het echter absoluut niet: writes en reads naar bepaalde schijflocaties worden gebruikt als 'triggers' om bepaalde operaties te doen.

Mijn probleem met het nadoen van de software onder Linux is nu dat Linux ervanuitgaat dat data op schijven alleen verandert als het OS erheenschrijft, en dat als ik byte N inlees, het vast geen kwaad kan om de eropvolgende 4K-1 bytes ook in te lezen. Bij normale schijven is dat compleet wenselijk, maar bij dit device raak je dan allerlei triggers en haal je bij het lezen verouderde info uit de cache.

Mijn vraag is dus: Hoe instrueer ik Linux om alleen die bytes te lezen en te schrijven die ik wil? Als ik /dev/sdx open, buffert 'ie er vrolijk op los. O_DIRECT heb ik al geprobeerd, maar dan gaat om de een of andere vage manier mijn lseek niet meer goed; bovendien heb ik gelezen dat je dan aan vage boundaries van 4K zit, wat ik al helemaal niet kan gebruiken. Ik heb wel iets gelezen over een raw device driver in de kernel, maar naast dat ik niet zou weten of dat werkt, heb ik liever niet dat ik m'n kernel moet recompilen. (Niet dat ik dat niet kan, maar als ik mijn progje later ga uitgeven moet iedereen die raw device support hebben.) Zou ik misschien direct tegen de SCSI-layer aan kunnen kletsen? Worstcase-scenario kan ik waarschijnlijk altijd libusb gebruiken, maar dan moet ik een manier vinden om de kernel te vertellen dat 'ie met z'n klauwen van mijn mass storage device af moet blijven.

[Sprite_tm]

Ahrg Ik las niet goed. Mijn calls gingen de mist in bij de reads, niet bij de lseeks, en dat was inderdaad een probleem ivm O_DIRECT en niet-aligned buffers. Op naar de tweede vraag dan maar: Wat is de mooiste manier om aligned buffers te krijgen? Ik doe het nu door /dev/zero private te mmappen en dat werkt, maar ik kan me niet aan de indruk onttrekken dat er iets netters moet wezen.

[Sebazzz]

Wilde gok: dd

Data van je dingetje af halen

dd if=/dev/sdx of=bestand.bin

Data mounten:

mkdir /mnt/dingetje
mount bestand.bin /mnt/dingetje

Klaar?

dd if=bestand.bin of=/dev/sdx

Of wil je geen data veranderen maar instructies uitvoeren? (mij niet helemaal duidelijk)

[ Voor 4% gewijzigd door Sebazzz op 04-01-2008 21:18 . Reden: Onzin ]

[LauPro]

Welk FS heeft dat device? En opzich vind ik het idee om gewoon een image erheen te dumpen niet verkeerd. Of moet er echt een specifieke volgorde worden aangegeven? Ik kan me voorstellen dat de driver in het fotolijstje niet met fragmentatie om kan gaan bijvoorbeeld.

[Sprite_tm]

Het is een proprietary FS, ik heb nog niet uitgevogeld welke. En as I said: je kan niet simpelweg je mass storage device uitlezen om de data te verkrijgen: om het geheugen van het device te lezen moet je basically een zwik commando's 'wegschrijven' naar offset 0x6200 en het resultaat uitlezen op adres 0xB000. Probleem is dus onder anderen dat als je dat voor de eerste keer doet, Linux vrolijk de data op 0xB000 cached: als je daarna nog een commando schrijft naar 0x6200 en dan het resultaat probeert te lezen van adres 0xB000, Linux denkt 'Heej, de data van dat adres staat nog in mijn cache!' en je dus het resultaat van het eerste commando voorschotelt. Maar dat is dus allemaal al opgelost door middel van O_DIRECT.

[LauPro]

Ik denk dat er helemaal geen FS is maar dat er in een soort binary formaat wordt weggeschreven. Of worden er inderdaad willekeurige commanda's gestuurd?

En de cache kan je vrij makkelijk omzeilen zoals je zelf al aangeeft. Al hoewel er volgens mij wel weer een buffered USB driver in de maak is die op stack-niveau aan de slag gaat. Misschien dat dat problemen op gaat leveren.