タグ付けされた質問 「system-calls」

私はmkdir、カーネルのソースを見ることで、関数がどのように機能するかを理解しようとしています。これは、カーネル内部を理解し、さまざまな機能間を移動しようとする試みです。mkdirで定義されていることを知っていsys/stat.hます。プロトタイプを見つけました： /* Create a new directory named PATH, with permission bits MODE. */ extern int mkdir (__const char *__path, __mode_t __mode) __THROW __nonnull ((1)); 次に、この関数が実装されているCファイルを確認する必要があります。ソースディレクトリから、私は試しました ack "int mkdir" 表示した security/inode.c 103:static int mkdir(struct inode *dir, struct dentry *dentry, int mode) tools/perf/util/util.c 4:int mkdir_p(char *path, mode_t mode) tools/perf/util/util.h 259:int mkdir_p(char *path, …

375 linux-kernel  source  system-calls 

たとえばgit、システムにインストールしました。しかし、どこにインストールしたか覚えていないので、これを見つけるのにどのコマンドが適していますか？

109 terminal  system-calls 

ではinclude/x86_64-linux-gnu/asm/unistd_64.h、という名前のシステムコールが表示されますtuxcall。 #define __NR_tuxcall 184 未実装のシステムコールでman tuxcallあると言うことを除いて、それについては何もありません。何をしたの？それは実装されなかったのですか、それとも古代の何かをしましたか

48 linux  system-calls 

Unix やの場合、and やorのようなtimeandのcreat代わりに、多分もっと適切な、そのようなアンテリングシステムコール名を使用する理由は何ですか。それは次の点に私を連れて行きます：なぜ誰かがそれを読みやすくするためにキャメルケースや少なくともアンダースコアなしのようなものが欲しいのですか？もちろん、呼び出しにはより多くの文字が含まれますが、コードの可読性がより重要であることは誰でも知っていますか？getCurrentTimeSecscreateFileget_current_time_secscreate_filecfsetospeed

43 history  posix  system-calls 

システムコールインターフェイスは低レベルで実装されているため、「ジェネリック」コードではなく、アーキテクチャ/プラットフォームに依存します。 しかし、Linux 32ビットx86カーネルのシステムコールに、同様のアーキテクチャのLinux 64ビットx86_64で同じ値が保持されない理由がはっきりとわかりません。この決定の背後にある動機/理由は何ですか？ 私の最初の推測は、バックグラウンド化の理由が32ビットアプリケーションをx86_64システム上で実行可能な状態に維持することであったため、システムコール番号への妥当なオフセットを介して、システムはユーザースペースが32ビットまたは64ビットであることを認識しますそれぞれ。ただし、そうではありません。少なくとも、x86_64のシステムコール番号0であるread（）は、この考えと一致しないように思われます。 もう1つの推測は、システムコール番号の変更にはセキュリティ/強化の背景があるかもしれないということです。 アーキテクチャに依存するコード部分の実装の課題に無知であるため、システムコール番号を変更する必要はないように思われます（16ビットのレジスタでさえ、すべてを表すために現在〜346の数値よりも多くを格納するため）呼び出し）、互換性を破る以外の何かを達成するのに役立ちます（ただし、ライブラリlibcを介してシステムコールを使用すると、軽減されます）。

35 linux  system-calls 

read()とのwrite()呼び出しのマニュアルページを読むと、これらの呼び出しは、ブロックする必要があるかどうかに関係なく、シグナルによって中断されるようです。 特に、仮定 プロセスが何らかのシグナルのハンドラーを確立します。 デバイスが設定されてO_NONBLOCK いない状態で開かれている（つまり、ブロッキングモードで動作している） その後、プロセスread()はデバイスから読み取るシステムコールを行い、その結果、カーネル空間でカーネル制御パスを実行します。 read()プロセスがカーネル空間で実行している間、ハンドラーが以前にインストールされたシグナルがそのプロセスに配信され、そのシグナルハンドラーが呼び出されます。 SUSv3の「System Interfaces volume（XSH）」のマニュアルページと適切なセクションを読むと、次のことがわかります。 私。a read()がデータを読み込む前に信号によって中断された場合（つまり、データが利用できなかったためブロックしなければならなかった場合）、errno[EINTR]に設定された-1を返します。 ii。a read()がデータを正常に読み取った後（つまり、要求の処理をすぐに開始できた）にシグナルによって中断された場合、読み取られたバイト数を返します。 質問A）： どちらの場合（ブロック/ブロックなし）でも、信号の配信と処理は完全に透過的ではないと仮定するのは正しいread()ですか？ ケースi。ブロッキングread()は通常、プロセスをTASK_INTERRUPTIBLE状態にするため、シグナルが配信されるとカーネルがプロセスをTASK_RUNNING状態にするため、理解できるようです。 しかし、read()ブロックする必要がなく（ケースii。）、カーネル空間でリクエストを処理している場合、シグナルの到着とその処理は、ハードウェアの到着と適切な処理と同様に透過的であると考えていました。割り込みになります。特に、シグナルの配信時に、プロセスは一時的にユーザーモードになり、そのシグナルハンドラーを実行して、最終的に戻り、中断されたread()（カーネルスペースで）処理を終了しread()て、完了までの経過後、プロセスはread()（ユーザー空間での）呼び出しの直後のポイントに戻り、結果として利用可能なすべてのバイトが読み込まれます。 しかし、ii。はread()、データがすぐに利用可能であるため、が中断されていることを暗示しているように見えますが、（すべてではなく）一部のデータのみを返します。 これにより、2番目の（そして最後の）質問に導かれます。 質問B）： A）での私の仮定が正しい場合、read()要求を満たすために利用可能なデータがあるためブロックする必要はないのに、なぜ中断されるのですか？言い換えると、なぜread()シグナルハンドラーを実行した後に再開されず、最終的にすべての利用可能なデータ（結局利用可能だった）が返されることになりますか？

29 kernel  signals  architecture  system-calls 

警告：ほとんどのシェルでこのコマンドを実行すると、システムが破損し、修正するには強制シャットダウンが必要になります。 再帰関数:(){ :|: & };:とその機能を理解しています。しかし、フォークシステムコールがどこにあるのかわかりません。よくわかりませんが、パイプの中で疑ってい|ます。

25 linux  shell  system-calls 

から man select int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout); nfdsは、3つのセットのいずれかで最も大きい番号のファイル記述子に1を加えたものです。 ファイル記述子を決定できる、およびnfdsをすでに持っている場合、の目的は何ですか？readfdswritefdsexceptfds

25 system-calls  file-descriptors 

man getrusage 2 言う ru_maxrss (since Linux 2.6.32) This is the maximum resident set size used (in kilobytes). For RUSAGE_CHILDREN, this is the resident set size of the largest child, not the maximum resident set size of the process tree. それで、この数は正確に何を意味するのでしょうか？

23 kernel  memory  system-calls 

bashでパイプを使用したとき、これについてはあまり考えませんでした。しかし、システムコールpipe（）とfork（）を使用してCコードの例を読むと、匿名パイプと名前付きパイプの両方を含むパイプをどのように理解するのか疑問に思います。 「Linux / Unixのすべてがファイルである」とよく言われます。パイプは実際にはファイルであるため、接続する部分の1つはパイプファイルに書き込み、他の部分はパイプファイルから読み取るのでしょうか。はいの場合、匿名パイプのパイプファイルはどこに作成されますか？/ tmp、/ dev、または...？ ただし、名前付きパイプの例から、パイプを使用すると、一時ファイルを明示的に使用するよりもスペースと時間のパフォーマンスが優れていることがわかりました。また、パイプはファイルのようにデータを保存しないようです。したがって、パイプは実際にはファイルであるとは思えません。

21 shell  pipe  system-calls  architecture 

Perl 5.xのドキュメントでは、flock（..）の実装では、1から始まり、利用できない場合は3に向かって進む、次のネイティブコールのいずれかを使用するように規定されています。 群れ（2） fcntl（2） lockf（3） それはいいです。ただし、flock（2）をNFS上で使用すべきではないという免責事項に気付いているかもしれません。このドキュメントでは、-Ud_flockフラグを使用してPerlにflock（2）を強制的に使用することを推奨しています。flock（2）（Redhat）のmanページには、NFSの問題に関する同様の免責事項が記載されています。 私の質問は、なぜ！？！？NFSでflock（2）が安全でない理由の詳細な記事や説明を見つけることができないようです。 Redhat（flock（2）が使用されている場所）とSolaris（fcntl（2）が使用されている場所）の両方で、CとPerlでいくつかのテストスクリプトを作成しました。Perlが実際にflock（2）とfcntl（2）をそれぞれ使用していることを確認するために、strace / trussを実行しました。ロックが守られていない問題を再現できませんでした！何が？

19 nfs  system-calls 

プロセス管理に関するウィキペディアの記事を読んでいます。私の焦点はLinuxにあります。システムコール、メッセージパッシング、割り込みの概念と目的の関係と違いを理解することはできません。これらはすべて、リソースとサービスをカーネルに要求するプロセスのためのものですか？ この記事からの引用とその他の引用： OSが割り当て解除または割り当てを実行するために、プログラムの実行中にOSがプロセッサの制御を取り戻すには、2つの方法があります。 プロセスはシステムコール（ソフトウェア割り込みとも呼ばれます）を発行します。たとえば、ハードディスク上のファイルへのアクセスを要求するI / O要求が発生します。 ハードウェア割り込みが発生します。たとえば、キーボードでキーが押された、またはタイマーが切れた（プリエンプティブマルチタスクで使用）。 ユーザーモードで実行しているプログラムがカーネルのサービスを要求できる方法は2つあります。 * System call * Message passing 割り込みは、注意の必要性を示す非同期信号、または実行の変更の必要性を示すソフトウェアの同期イベントです。 ハードウェア割り込みにより、プロセッサは実行状態を保存し、割り込みハンドラーの実行を開始します。ソフトウェア割り込みは通常、命令セット内の命令として実装され、ハードウェア割り込みと同様の割り込みハンドラーへのコンテキスト切り替えを引き起こします。

15 system-calls  architecture  interrupt 

「システムコール」という用語を理解したいと思います。システムコールは、ユーザー空間アプリケーションからカーネルサービスを取得するために使用されることをよく知っています。 明確にする必要があるのは、「システムコール」と「システムコールのC実装」の違いです。 これは私を混乱させる引用です： Unixライクなシステムでは、そのAPIは通常、システム呼び出しにラッパー関数を提供するglibcなどのCライブラリ（libc）の実装の一部であり、多くの場合、呼び出し元のシステム呼び出しと同じ名前が付けられます。 「彼らが呼ぶシステムコール」とは何ですか？それらのソースはどこですか？コードに直接含めることはできますか？ 一般的な意味での「システムコール」はPOSIX定義のインターフェイスにすぎませんが、実際に実装を確認するにはCソースを調べ、実際のユーザー空間からカーネルへの通信が実際にどのように行われるかを確認しますか？ 背景メモ：最終的に、各c関数がからのデバイスと対話するかどうかを理解しようとしています/dev。

14 kernel  c  posix  system-calls 

Linux（私のライブサーバーはRHEL 5.5上にあります-以下のLXRリンクはカーネルバージョンへのリンクです）、man 7 ipと言います： バインドされたTCPローカルソケットアドレスは、SO_REUSEADDRフラグが設定されていない限り、閉じた後しばらく利用できません。 私は使用していませんSO_REUSEADDR。「いつか」はどれくらいですか？どのくらいの長さで、どのように変更できますか？ 私はこれをあちこち探してみましたが、いくつかの情報を見つけましたが、どれもアプリケーションプログラマーの観点からこれを実際には説明していません。機知に： TCP_TIMEWAIT_LENでnet/tcp.h「TIME-WAIT状態を破壊するために待機する時間」であり、「約60秒」に固定されています / proc / sys / net / ipv4 / tcp_fin_timeoutは、「ソケットが当社側で閉じられた場合、FIN-WAIT-2状態にソケットを保持する時間」であり、「デフォルト値は60秒です」 私がつまずいているのは、TCPライフサイクルのカーネルモデルと利用できないポートのプログラマーモデルとの間のギャップを埋めることです。つまり、これらの状態が「いつか」に関係するかを理解することです。

13 linux  tcp  system-calls  socket  timeout 

遅いシステムコールと速いシステムコールの違いは何ですか？プロセスがいくつかのシグナルをキャッチすると、遅いシステムコールがブロックされる可能性があることを学びました。キャッチされたシグナルはブロックされたシステムコールを呼び起こすことがありますが、このメカニズムを正確に理解することはできません。どんな例でも歓迎されます。

13 system-calls  system-programming