Ich arbeite an einer Embedded-Linux-Videorecorder-Anwendung, die Video im MP4-Format in eine Datei schreibt (im FAT-Format SD-Karte).
Einige komplizierende Faktoren sind, dass die Video- und Audiodaten von Hardware-Codecs kommen, die mit geringer Latenz gewartet werden müssen und in DMA-fähige Puffer schreiben müssen.
Momentan benutze ich für die Ausgabedatei open () und write (), finde aber, dass write () Hunderte von Millisekunden benötigen, um zurückzukehren, wenn das System unter Last ist, also werden meine Schreibvorgänge in einem separaten Thread erledigt.
Wie es aussieht, kopiere ich Daten aus den (kleinen, begrenzten Anzahl) DMA-Puffern in einen multi-megabyte malloc'd Ringpuffer und schreibe dann () von dem in einem anderen Thread. Das bedeutet, ich mache mindestens zwei Kopien, einmal in den App-Puffer und einmal in den Systempuffer-Cache.
Ich erwäge, O_DIRECT-Schreibvorgänge zu versuchen, um eine Kopie zu vermeiden, bin aber an Kommentaren interessiert. Ich stelle fest, dass Robert Love kommentiert, dass O_DIRECT schrecklich ist aber sagt nicht warum.
Auf der anderen Seite wäre ich auch interessiert, wenn irgendjemand einen Weg kennt, um write () für längere Zeit nicht zu blockieren (AIO?), dann könnte ich den Puffercache verwenden, wie es Linus beabsichtigt hat.
>Diese Frage hat nichts mit meine sehr alte Frage über Schreibstände .
Wenn dies wirklich ein eingebettetes Produkt ist, in dem Sie Ihre Treiberquelle steuern, würde ich ernsthaft in den Speicher schauen, damit der Benutzer auf den gleichen Speicher wie der Gerätetreiber zugreifen und all diese Kopien vermeiden kann / p>
Und hier ist eine Beispielimplementierung des Treiberspeichers, der mit einem Userspace-Prozess unter Verwendung von mmap geteilt wird .