タグ付けされた質問 「bsd」

バックグラウンド： システムコールのオーバーヘッドは、主にユーザー空間からカーネル空間へ、およびその逆へのコンテキストの切り替えにより、関数呼び出しのオーバーヘッドよりもはるかに大きくなります（推定範囲は20〜100倍）。関数呼び出しのオーバーヘッドを節約するためにインライン関数が一般的であり、関数呼び出しはsyscallsよりもはるかに安価です。開発者が1つのsyscallでカーネル内の操作を可能な限り処理することにより、システムコールのオーバーヘッドの一部を避けたいと考えるのは理にかなっています。 問題： これは、のような（？余計な）システムコールをたくさん作成したsendmmsgを（） 、recvmmsg（）などのようにchdir、オープン、のlseekおよび/またはシンボリックリンクの組み合わせ：openat、mkdirat、mknodat、fchownat、futimesat、newfstatat、unlinkat、fchdir、ftruncate、fchmod、renameat、linkat、symlinkat、readlinkat、fchmodat、faccessat、lsetxattr、fsetxattr、execveat、lgetxattr、llistxattr、lremovexattr、fremovexattr、flistxattr、fgetxattr、pread、pwrite等... 現在copy_file_range()、読み取りlseekと書き込みsyscallを組み合わせたLinuxが追加されました。これがfcopy_file_range（）、lcopy_file_range（）、copy_file_rangeat（）、fcopy_file_rangeat（）およびlcopy_file_rangeat（）になるまでの時間の問題です...しかし、X個の呼び出しの代わりに2個のファイルがあるため、X ^ 2になる可能性がありますもっと。わかりました、LinusとさまざまなBSD開発者はそこまで行きませんが、私のポイントは、バッチシステムコールがあれば、これらのすべて（ほとんど？） libc側にオーバーヘッドがある場合。 システムコールをバッチ処理するための非ブロッキングシステムコール用の特別なシステムコールスレッドを含む、多くの複雑なソリューションが提案されています。ただし、これらの方法は、libxcbとlibX11の場合とほぼ同じ方法で、カーネルとユーザー空間の両方にかなりの複雑さを追加します（非同期呼び出しにはより多くのセットアップが必要です） 解決？： 汎用バッチ処理システムコール。これにより、特殊なカーネルスレッドを使用することに伴う複雑さなしに、最大コスト（複数モードスイッチ）が軽減されます（ただし、その機能は後で追加できます）。 socketcall（）syscallには、基本的にプロトタイプの基本がすでにあります。引数の配列を取ることからそれを拡張して、代わりに戻り値の配列、引数の配列へのポインター（syscall番号を含む）、syscallの数、およびflags引数などを取得します。 batch(void *returns, void *args, long ncalls, long flags); 大きな違いの1つは、前のsyscallsの結果を後続のsyscalls（たとえば/ で使用するためのファイル記述子）で使用できるように、引数はおそらくすべて単純化のためのポインターである必要があることです。open()read()write() 考えられるいくつかの利点： ユーザースペースの削減->カーネルスペース->ユーザースペースの切り替え 可能なコンパイラスイッチ-fcombine-syscallsは、自動的にバッチ処理を試行します 非同期操作のオプションフラグ（fdを返すとすぐに監視されます） ユーザースペースに将来の結合されたsyscall関数を実装する機能 質問： バッチ処理システムコールを実装することは可能ですか？ 明らかな落とし穴がありませんか？ メリットを過大評価していますか？ バッチ処理システムコールの実装を気にすることは価値がありますか（Intel、Google、またはRedhatで働いていません）。 以前に自分のカーネルにパッチを適用しましたが、LKMLを扱うのは恐ろしいです。 歴史は、「普通の」ユーザー（git書き込みアクセスのない非企業のエンドユーザー）にとって何かが広く有用であっても、上流（unionfs、aufs、cryptodev、tuxoniceなど）に受け入れられることはないことを示しています。 参照： FlexSC：例外のないシステムコールを使用した柔軟なシステムコールスケジューリング 専用ユーザーおよびカーネルCPUを介したシステムコールのオーバーヘッドの回避

17 c  linux-development  bsd 

ほぼすべてのオープンソースソフトウェアライセンスは、ユーザーが保護しているプロジェクトのルートに完全なライセンスを含めることを要求します（または少なくとも弁護士が要求することを推奨します）。 私が話したある弁護士は、これはCD時代の遺産であり、宝石のケースに完全なライセンスを含めることが必要だったと示唆しています。 しかし、今日、私たちはクラウド時代に生きています。たとえば、完全なライセンスを自分のWebサイトでホストし、そのライセンスのタイトル+ URLをソースファイルのヘッダーに含めることができないのはなぜですか？ おまけ：確立されたライセンスをそのままルートに保持する必要があると一般的に合意している場合、FSFのOSIがURLで参照できるライセンスを承認していないのはなぜですか。

10 licensing  open-source  mit-license  apache  bsd 

複数の著作権者がいるオープンソースプロジェクトに参加しています。プロジェクトは、3条項BSDライセンスの下でライセンスされています。残念ながら、個々のコードファイルには元の所有者（著作権ヘッダー）への参照は含まれていませんが、プロジェクト全体として、BSDライセンステキストを含む単一のファイルLICENSE.txtが提供されています。プロジェクトには、すべての著作権者を識別する個別のファイルも含まれています。 ただし、私は実用的な質問に苦労しています。BSDライセンスの最初の行は、著作権所有者を識別するためのものです。 Copyright (c) <year>, <copyright holder> 私たちの場合、著作権所有者は1人ではありません（少なくともプロジェクト全体では）。では、具体的に言えば、ここに何を入れればよいのでしょうか。ライセンス自体が「上記の著作権表示」を保持することを指しているので、私はそれを省略することはできません。ここにすべての著作権者をリストする、またはおそらく著作権者の外部リストを参照するための推奨される方法/形式はありますか？ちなみに私たちは10人以上の貢献者について話しているので、その一部は個人、一部の企業であるため、短いリストではありません。 私は他のいくつかのプロジェクトがどのようにこれを行うかを見ました（例：Linux）、ほとんどの場合<copyright owner>、ライセンスにビットが含まれていないGPLを使用することがわかりました。

8 licensing  bsd