Q&A
何らかの組み込みlinux上の話でしょうか。/dev/mtdblock 用のデバイスドライバーは自作（あるいはベンダー提供）のものではありませんか。
FRAM(/dev/mtdblock4)のデバイスファイルをQFileで開き
seekで所定の位置まで移動して、wirteでデータを書く
という流れの処理をしています。
コンパイルのQtバージョンは5.3.2で、実行環境もQt5.3.2
の状態でアプリを起動すると、seekを呼んでいるところで
QIODevice::seek: Cannot call seek on a sequential device
というエラー？警告？文が表示されます。
言葉通りなら
シーケンシャルデバイスではシークできないよと言っているのだと思います。
確かにQtのドキュメントにも
For sequential devices, the default behavior is to do nothing and return false.
と書いているため、シーケンシャルデバイスの場合何もしないということになります。
seekの戻り値がfalseになっていたことも確認済みです。
しかし、実際にFRAMの中身を見てみると
しっかりとシークをした位置にデータを書き込んでいることが確認できました。
というかそもそもFRAMはランダムアクセスだと思うので、前提の部分でおかしいです。
isSequentialを呼んでみるとfalseが返ってくるため、しっかりとランダムアクセスデバイスとして
認識は出来ているみたいです。
また、コンパイルしたものはそのままで実行環境をQt5.7.1で実行してみると
問題の警告文が表示されなくなります。
このことからQtのバグなのではと推測したのですが
これに関するバグレポートや修正に関する文書が見つけられず困っています。
これがただ単に間違って警告が出てしまうだけだというなら、
表示される警告を無視、出来れば表示しないようにしてそのままQFileのseekを使い続けようと思っているのですが
他に致命的なバグが存在するようなのであれば、C++の関数に処理を書き換えようと思っております。
何かコレに関する情報をご存知の方、ちょっとしたことでもいいので教えていただけませんでしょうか？
よろしくお願いします。
###追記
Qt5.3.2のソースを見ていたところ
C++
1bool QIODevice::isSequential() const 2{ 3 return false; 4}
というのを見つけました
つまりどんな状況でもfalseしか返さないので、実質シーケンシャルデバイスを認識するのは不可能？
そうなってくるとなぜ警告文が出てくるのか、なおさら分からなくなってしまいました...
###追記２
QFile::seek() on character devices not working
該当の問題だと思われるバグのページを見つけていました...
割と最初に見つけていたのに勝手に勘違いしてスルーしていました...
恐らくこれだと思われるので
今一度、検討をしてみたいと思います
>何らかの組み込みlinux上の話でしょうか
はい、ボードコンピュータにDebianがインストールされているものです
>/dev/mtdblock 用のデバイスドライバーは自作（あるいはベンダー提供）のものではありませんか。
ベンダー提供になります
回答2件
0
ベストアンサー
Qtを使ったことは無いのですが、「ちょっとしたことでもいいので」とのことでしたので、ご質問を読んで思ったことを述べたいと思います。ですのでQtから離れ、かつ直接的な回答ではありませんのでご了承ください。
FRAMはメモリなので、本来はディスクのようなブロックデバイスに相当するものだと思います。それを上位のアプリ側への便宜を図って /dev/mtbblokへのデバイスドライバーを介し、必要に応じてデバイスドライバーが提供するioctlで固有のコマンドを受け付け、さもファイルでシークできるように振る舞います。
ベンダー提供のデバイスドライバーであれば、カスタマイズされたボード用にベンダーがそれ用のデバイスドライバーを提供しますが、もともと用途が限定されているので機能に制限があったり、使い方によってはもちろんバグや不具合が出ることもあります。/dev/mtbblockを直接アクセスしていることで、それらのことが発現しているかもしれません。
例えばファイルのシークはlinuxのシステムコールlseek
ですが、呼び出せはしてもFRAMへのアクセスに関してドライバー内の処理に不備があれば、返ってくる結果が不整合となることも有り得ます。そんな場合、Qtから降りてC++でファイルアクセスするようにしても、恐らく本質的に同じ結果になります。
問題の切り分け方法としてご提案できることのひとつは、Qtでもなく、C++でもなく、C言語でlinux のopen, lseek, read, writeなどのシステムコールを直接使うテストプログラムを作り、それらシステムコールの呼び出し結果(返り値)とerrnoを確認し、また、実際の読み出し、書き込み結果を照合してみることです。特にエラー時に参照できるグローバル変数errnoは通常、デバイスドライバーが返すものなので、時に有用なものになります。
場合によってはベンダー提供のデバイスドライバーのソースと突き合わせてみる必要もあるかもしれません。ここで問題があるのであれば少々やっかいで、問題の無い /dev/mtblockへのアクセス方法を考えなければなりません。あるいはデバイスドライバーの改修か。
もちろん、Qtのライブラリとのインターフェース不整合と言うこともあります。そうであれば、C++でのファイルアクセスで回避策を得られると思いますし、別回答でいただいた策や、追記されたことの裏づけも取れると思います。
投稿2019/10/09 07:25
総合スコア9183
コメントの
> そうなってくるとなぜ警告文が出てくるのか、
ですが、bool QIODevice::isSequential() const { return false;} を受けての、Qtの上位ライブラリが出している単なる警告かアサーションかもしれませんね。（推測です）
>FRAMへのアクセスに関してドライバー内の処理に不備があれば
なるほど、考えもしていませんでした
確かに、その場合は厄介ですね
>システムコールの呼び出し結果(返り値)とerrnoを確認し、また、実際の読み出し、書き込み結果を照合してみることです
これは一度しておいたほうが良いかもしれませんね
とてもためになる回答ありがとうございます
勉強になりました
>Qtの上位ライブラリが出している単なる警告かアサーションかもしれませんね。
seek関数内で
isSequentialの戻り値がtrueの場合、問題の警告を表示して
その場でfalseをreturnするところまでは確認できているのですが
じゃあ必ずfalseなら何故警告が？
seekの戻り値がfalseなのは確認できているが
なら何故シークできているのか？
と、謎が深まるばかりです...
軽くしか見ていないのでよく見れば解決するかもしれないので
問題を追っかけるのも良いですが、そこに時間をかけすぎてもしょうがないので
とりあえず使用を避けることにしたいと思っています
システムコールでの処理が確認でき次第
そのままその処理を採用しようかと思っています
> seekの戻り値がfalseなのは確認できているが
> なら何故シークできているのか？
/dev/mtbblock のデバイスドライバーを利用したread/write/lseekはちゃんと動いていて、シーケンシャルデバイス（キャラクターデバイスのことだと思いますが）か否かの判定を決定付けるQtのライブラリか、ドライバーとのやり取りにどこかに不備があるのだと思います。その場合は、問題は軽微だと思います。（状況を理解した上で、無視すれば良い）
>シーケンシャルデバイス（キャラクターデバイスのことだと思いますが）
この文に、ん！？
と思い、検索したサイトを見返してみました
https://bugreports.qt.io/browse/QTBUG-63099
恐らくこれですね...割と一番最初に見つけていましたが
character devicesというワードに違うかな？と勘違いしてスルーしていました...
ちゃんと読んではいませんが
恐らくこのバグで間違いないかと思います
だとするとページにも書いてある通り軽微なバグだとは思います
もう少し使用するかどうかを検討してみたいと思います
seekの頻度が多いためそのたびに警告が出るのは困るので
回避できないかの検討が必要です...
ご案内いただいたQtのバグレポートを読みました。まさにキャラクターデバイスに対するQFile::seek()ハンドリング不備、ですね。
とは言え バグレポート中の以下の dと fileEngine、QIODeviceのクラスの内容を読まないと断定はできませんが。
if (!d->fileEngine->seek(off) || !QIODevice::seek(off))
開いたファイルへのseekをサポートするかしないか、ユーザー側でフラグをセットするメンバー関数があるのではないでしょうか。（あってもバグレポートにあるように、処理が足りなそうですが）
思いつきの助言ですので、この辺にしておきます。
0
Qt の開発は、「バグの修正時には必ずバグ登録をする」というルールでは行われていないため、修正されたバグに対応するバグレポートがない場合があります。
どの修正によってその振る舞いが変わったかを確かめたいのであれば、 Qt 5.3.2 と Qt 5.7.1 を git bisect して、コミットを特定することをお勧めします。
本日時点での Qt は最新版は 5.13.1 となっており、Qt 5.7.1 以降に発見されたバグがいくつも修正されています。
致命的なバグを気にされるのであれば、まずはサポート対象の最新版もしくは最新のLTS版（本日時点では 5.12.5）を使うことを強くお勧めします。
投稿2019/10/09 06:53
総合スコア347
>「バグの修正時には必ずバグ登録をする」というルールでは行われていないため
なるほど、必ずあるものだと勝手に思っていました
>致命的なバグを気にされるのであれば
それもそうですね...
ただ、現状5.3.2(jessieでapt出来る最新)という方針になっているので
大人しくC++の関数で実装しようかと思います
回答ありがとうございました
あなたの回答
tips
プレビュー
