دالة الغلاف ()clone¶

عند إنشاء العملية الابنة باستخدام دالة غلاف clone()، فإنها تبدأ التنفيذ باستدعاء الدالة التي يشير إليها المعامل fn. (يختلف هذا عن fork(2)، حيث يستمر التنفيذ في الابن من نقطة استدعاء fork(2)). يُمرر المعامل arg كمعامل للدالة fn.

عندما تعود الدالة fn(arg)، تنتهي العملية الابنة. الرقم الصحيح الذي تعيده fn هو حالة الخروج للعملية الابنة. قد تنتهي العملية الابنة أيضًا صراحةً باستدعاء exit(2) أو بعد تلقي إشارة قاتلة.

يحدد المعامل stack موقع المكدس الذي تستخدمه العملية الابنة. وبما أن العملية الابنة والمستدعِي قد يتشاركان الذاكرة، فليس من الممكن للعملية الابنة أن تُنفذ في نفس المكدس الذي يستخدمه المستدعِي. يجب على المستدعِي بالتالي إعداد مساحة ذاكرة لمكدس الابن وتمرير مؤشر إلى هذه المساحة إلى clone(). تنمو المكدسات لأسفل في جميع المعالجات التي تشغل لينكس (باستثناء معالجات HP PA)، لذا يشير stack عادةً إلى أعلى عنوان في مساحة الذاكرة المعدة لمكدس الابن. لاحظ أن clone() لا توفر وسيلة يمكن من خلالها لـ المستدعِي إبلاغ النواة بحجم منطقة المكدس.

تُناقش المعاملات المتبقية لـ clone() أدناه.

clone3()¶

يوفر نداء النظام clone3() مجموعة فائقة من وظائف واجهة clone() الأقدم. كما يوفر عددًا من تحسينات واجهة برمجة التطبيقات (API)، بما في ذلك: مساحة لبتات أعلام إضافية؛ وفصل أنظف في استخدام المعاملات المختلفة؛ والقدرة على تحديد حجم منطقة مكدس الابن.

كما هو الحال مع fork(2)، يعود clone3() في كل من الأب والابن. ويعيد 0 في العملية الابنة ويعيد المعرف PID الخاص بالابن في الأب.

المعامل cl_args لـ clone3() هو هيكل بالشكل التالي:

struct clone_args {


    u64 flags;        /* قناع بتات الأعلام */


    u64 pidfd;        /* مكان تخزين واصف ملف PID


                         (int *) */


    u64 child_tid;    /* مكان تخزين معرف TID للابن،


                         في ذاكرة الابن (pid_t *) */


    u64 parent_tid;   /* مكان تخزين معرف TID للابن،


                         في ذاكرة الأب (pid_t *) */


    u64 exit_signal;  /* الإشارة التي تُرسل للأب عند


                         إنهاء الابن */


    u64 stack;        /* مؤشر لأدنى بايت في المكدس */


    u64 stack_size;   /* حجم المكدس */


    u64 tls;          /* موقع TLS الجديد */


    u64 set_tid;      /* مؤشر لمصفوفة pid_t


                         (منذ لينكس 5.5) */


    u64 set_tid_size; /* عدد العناصر في set_tid


                         (منذ لينكس 5.5) */


    u64 cgroup;       /* واصف ملف لمجموعة التحكم (cgroup) المستهدفة


                         للابن (منذ لينكس 5.7) */
};

يجب تهيئة المعامل size الذي يُزود لـ clone3() ليساوي حجم هذا الهيكل. (وجود المعامل size يسمح بتوسعات مستقبلية لهيكل clone_args).

يُحدد مكدس العملية الابنة عبر cl_args.stack، الذي يشير إلى أدنى بايت في منطقة المكدس، و cl_args.stack_size، الذي يحدد حجم المكدس بالبايت. في الحالة التي يُحدد فيها علم CLONE_VM (انظر أدناه)، يجب تخصيص مكدس وتحديده صراحةً. خلاف ذلك، يمكن تحديد هذين الحقلين كـ NULL و 0، مما يجعل الابن يستخدم نفس منطقة مكدس الأب (في مساحة العناوين الافتراضية الخاصة بالابن).

تُناقش الحقول المتبقية في المعامل cl_args أدناه.

التكافؤ بين معاملات ()clone و ()clone3¶

على عكس واجهة clone() الأقدم، حيث تُمرر المعاملات بشكل فردي، تُجمع المعاملات في واجهة clone3() الأحدث داخل هيكل clone_args الموضح أعلاه. يسمح هذا الهيكل بمجموعة فائقة من المعلومات الممرة عبر معاملات clone().

يوضح الجدول التالي التكافؤ بين معاملات clone() والحقول في المعامل clone_args المزود لـ clone3():

إشارة إنهاء الابن¶

عند إنهاء العملية الابنة، قد تُرسل إشارة إلى الأب. تُحدد إشارة الإنهاء في البايت المنخفض لـ flags (clone()) أو في cl_args.exit_signal (clone3()). إذا حُددت هذه الإشارة كأي شيء آخر غير SIGCHLD، فيجب على العملية الأب تحديد الخيارات __WALL أو __WCLONE عند انتظار الابن باستخدام wait(2). إذا لم تُحدد أي إشارة (أي صفر)، فلن تُرسل إشارة إلى العملية الأب عند إنهاء الابن.

مصفوفة set_tid¶

بشكل مبدئي، تختار النواة المعرف PID المتسلسل التالي للعملية الجديدة في كل من فضاءات أسماء PID التي توجد فيها. عند إنشاء عملية باستخدام clone3()، يمكن استخدام مصفوفة set_tid (المتوفرة منذ لينكس 5.5) لاختيار معرفات PID محددة للعملية في بعض أو كل فضاءات أسماء PID التي توجد فيها. إذا كان يجب ضبط PID للعملية المنشأة حديثًا فقط لفضاء أسماء PID الحالي أو في فضاء أسماء PID المنشأ حديثًا (إذا كانت flags تحتوي على CLONE_NEWPID) فيجب أن يكون العنصر الأول في مصفوفة set_tid هو الـ PID المطلوب ويجب أن يكون set_tid_size مساوياً لـ 1.

إذا كان يجب أن يكون لـ PID العملية المنشأة حديثًا قيمة معينة في فضاءات أسماء PID متعددة، فيمكن أن تحتوي مصفوفة set_tid على مدخلات متعددة. يحدد المدخل الأول الـ PID في فضاء أسماء PID الأكثر تعشيشًا، ويحتوي كل من المدخلات التالية على الـ PID في فضاء أسماء PID السلف المقابل. يُحدد عدد فضاءات أسماء PID التي يجب ضبط الـ PID فيها بواسطة set_tid_size الذي لا يمكن أن يكون أكبر من عدد فضاءات أسماء PID المتداخلة حاليًا.

لإنشاء عملية بمعرفات PID التالية في تسلسل هرمي لفضاء أسماء PID:

اضبط المصفوفة على:

set_tid[0] = 7;
set_tid[1] = 42;
set_tid[2] = 31496;
set_tid_size = 3;

إذا كان يلزم فقط تحديد معرفات PID في فضاءي أسماء PID الأكثر تعشيشًا، فاضبط المصفوفة على:

set_tid[0] = 7;
set_tid[1] = 42;
set_tid_size = 2;

يُختار الـ PID في فضاءات أسماء PID خارج الفضاءين الأكثر تعشيشًا بنفس الطريقة التي يُختار بها أي PID آخر.

تتطلب ميزة set_tid صلاحية CAP_SYS_ADMIN أو (منذ لينكس 5.9) CAP_CHECKPOINT_RESTORE في جميع فضاءات أسماء المستخدمين المالكة لفضاءات أسماء PID المستهدفة.

يمكن لـ المستدعِين فقط اختيار PID أكبر من 1 في فضاء أسماء PID معين إذا كانت هناك عملية init (أي عملية ذات PID 1) موجودة بالفعل في ذلك الفضاء. خلاف ذلك، يجب أن يكون مدخل الـ PID لفضاء أسماء PID هذا هو 1.

قناع الأعلام¶

يسمح كل من clone() و clone3() باستخدام قناع بتات للأعلام يعدل سلوكهما ويسمح لـ المستدعِي بتحديد ما يُتشارك بين المستدعِي والعملية الابنة. يُشار إلى قناع البتات هذا — المعامل flags في clone() أو حقل cl_args.flags الممرر إلى clone3() — باسم قناع flags فيما تبقى من هذه الصفحة.

يُحدد قناع flags كعملية OR بتية لصفر أو أكثر من الثوابت المدرجة أدناه. باستثناء ما هو مذكور أدناه، تتوفر هذه الأعلام (ولها نفس التأثير) في كل من clone() و clone3().

CLONE_CHILD_CLEARTID (منذ لينكس 2.5.49)

مسح (تصفير) معرف خيط الابن في الموقع الذي يشير إليه child_tid (clone()) أو cl_args.child_tid (clone3()) في ذاكرة الابن عند خروجه، وإجراء تنبيه (wakeup) على futex في ذلك العنوان. يمكن تغيير العنوان المعني بواسطة نداء النظام set_tid_address(2). يُستخدم هذا بواسطة مكتبات الخيوط.

CLONE_CHILD_SETTID (منذ لينكس 2.5.49)

تخزين معرف خيط الابن في الموقع الذي يشير إليه child_tid (clone()) أو cl_args.child_tid (clone3()) في ذاكرة الابن. تكتمل عملية التخزين قبل أن يعيد نداء الاستنساخ التحكم إلى مساحة المستخدم في العملية الابنة. (لاحظ أن عملية التخزين قد لا تكون قد اكتملت قبل عودة نداء الاستنساخ في العملية الأب، وهو أمر ذو صلة إذا استُخدم علم CLONE_VM أيضًا).

CLONE_CLEAR_SIGHAND (منذ لينكس 5.5)

بشكل مبدئي، تكون ترتيبات الإشارات في خيط الابن هي نفسها الموجودة في الأب. إذا حُدد هذا العلم، فإن جميع الإشارات التي تُعالج في الأب (ولم تُضبط على SIG_IGN) تُعاد إلى ترتيباتها المبدئية (SIG_DFL) في الابن.

تحديد هذا العلم مع CLONE_SIGHAND غير منطقي وغير مسموح به.

CLONE_DETACHED (تاريخي)

لفترة من الوقت (خلال سلسلة تطوير لينكس 2.5) كان هناك علم CLONE_DETACHED، والذي تسبب في عدم تلقي الأب إشارة عند إنهاء الابن. في النهاية، دُمج تأثير هذا العلم تحت علم CLONE_THREAD وبحلول وقت إصدار لينكس 2.6.0، لم يعد لهذا العلم أي تأثير. منذ لينكس 2.6.2، اختفت الحاجة لتقديم هذا العلم مع CLONE_THREAD.

لا يزال هذا العلم معرفًا، ولكن عادةً ما يُتجاهل عند استدعاء clone(). ومع ذلك، راجع وصف CLONE_PIDFD لمعرفة بعض الاستثناءات.

CLONE_FILES (منذ لينكس 2.0)

إذا ضُبط CLONE_FILES، فإن العملية المستدعِية والعملية الوليدة تتشاركان نفس جدول واصفات الملفات. أي واصف ملف يُنشأ بواسطة العملية المستدعِية أو بواسطة العملية الوليدة يكون صالحًا أيضًا في العملية الأخرى. وبالمثل، إذا أغلقت إحدى العمليات واصف ملف، أو غيرت الأعلام المرتبطة به (باستخدام عملية F_SETFD في fcntl(2))، تتأثر العملية الأخرى أيضًا. إذا استدعت عملية تتشارك جدول واصفات ملفات execve(2)، فإن جدول واصفات ملفاتها يُنسخ (يُفصل التشارك).

إذا لم يُضبط CLONE_FILES، ترث العملية الوليدة نسخة من جميع واصفات الملفات المفتوحة في العملية المستدعِية وقت استدعاء الاستنساخ. العمليات اللاحقة التي تفتح أو تغلق واصفات الملفات، أو تغير أعلام واصف الملف، والتي تقوم بها إما العملية المستدعِية أو العملية الوليدة لا تؤثر على العملية الأخرى. لاحظ، مع ذلك، أن واصفات الملفات المنسوخة في الوليدة تشير إلى نفس أوصاف الملفات المفتوحة مثل واصفات الملفات المقابلة في العملية المستدعِية، وبالتالي تتشارك إزاحات الملف وأعلام حالة الملف (انظر open(2)).

CLONE_FS (منذ لينكس 2.0)

إذا ضُبط CLONE_FS، يتشارك المستدعِي والعملية الوليدة نفس معلومات نظام الملفات. يتضمن ذلك جذر نظام الملفات، ودليل العمل الحالي، وقناع وضع إنشاء الملفات (umask). أي استدعاء لـ chroot(2) أو chdir(2) أو umask(2) تقوم به العملية المستدعِية أو العملية الوليدة يؤثر أيضًا على العملية الأخرى.

إذا لم يُضبط CLONE_FS، تعمل العملية الوليدة على نسخة من معلومات نظام الملفات للعملية المستدعِية وقت استدعاء الاستنساخ. الاستدعاءات لـ chroot(2) أو chdir(2) أو umask(2) التي تُجرى لاحقًا بواسطة إحدى العمليات لا تؤثر على العملية الأخرى.

CLONE_INTO_CGROUP (منذ لينكس 5.7)

بشكل مبدئي، توضع العملية الوليدة في نفس مجموعة التحكم (cgroup) الإصدار 2 التي تتبعها العملية الأب. يسمح علم CLONE_INTO_CGROUP بإنشاء العملية الوليدة في مجموعة تحكم إصدار 2 مختلفة. (لاحظ أن CLONE_INTO_CGROUP له تأثير فقط على مجموعات التحكم من الإصدار 2.)

لوضع العملية الوليدة في مجموعة تحكم مختلفة، يحدد المستدعِي CLONE_INTO_CGROUP في cl_args.flags ويمرر واصف ملف يشير إلى مجموعة تحكم إصدار 2 في حقل cl_args.cgroup. (يمكن الحصول على واصف الملف هذا عن طريق فتح دليل cgroup v2 باستخدام إما علم O_RDONLY أو علم O_PATH.) لاحظ أن جميع القيود المعتادة (الموضحة في cgroups(7)) بشأن وضع عملية في مجموعة تحكم إصدار 2 تنطبق هنا.

من بين حالات الاستخدام الممكنة لـ CLONE_INTO_CGROUP ما يلي:

CLONE_IO (منذ لينكس 2.6.25)

إذا ضُبط CLONE_IO، فإن العملية الجديدة تتشارك سياق إدخال/إخراج مع العملية المستدعِية. إذا لم يُضبط هذا العلم، فإن العملية الجديدة (كما في fork(2)) يكون لها سياق إدخال/إخراج خاص بها.

سياق الإدخال/الإخراج هو نطاق الإدخال/الإخراج لجدول القرص (أي ما يستخدمه مجدول الإدخال/الإخراج لنمذجة جدولة إدخال/إخراج العملية). إذا تشاركت العمليات نفس سياق الإدخال/الإخراج، فإن مجدول الإدخال/الإخراج يعاملها كعملية واحدة. نتيجة لذلك، فإنها تتشارك وقت القرص. بالنسبة لبعض مجدولي الإدخال/الإخراج، إذا تشاركت عمليتان في سياق إدخال/إخراج واحد، فسيُسمح لهما بتداخل وصولهما إلى القرص. إذا كانت عدة خيوط تقوم بالإدخال/الإخراج نيابة عن نفس العملية (aio_read(3)، على سبيل المثال)، فيجب عليها استخدام CLONE_IO للحصول على أداء إدخال/إخراج أفضل.

إذا لم تُضبط النواة بخيار CONFIG_BLOCK، فإن هذا العلم لا يفعل شيئًا.

CLONE_NEWCGROUP (منذ لينكس 4.6)

إنشاء العملية في فضاء أسماء cgroup جديد. إذا لم يُضبط هذا العلم، فإن العملية (كما في fork(2)) تُنشأ في نفس فضاءات أسماء cgroup الخاصة بالعملية المستدعِية.

لمزيد من المعلومات حول فضاءات أسماء cgroup، راجع cgroup_namespaces(7).

فقط العملية ذات الامتيازات (CAP_SYS_ADMIN) يمكنها استخدام CLONE_NEWCGROUP.

CLONE_NEWIPC (منذ لينكس 2.6.19)

إذا ضُبط CLONE_NEWIPC، فسيتم إنشاء العملية في فضاء أسماء IPC جديد. إذا لم يُضبط هذا العلم، فإن العملية (كما في fork(2)) تُنشأ في نفس فضاء أسماء IPC الخاص بالعملية المستدعِية.

لمزيد من المعلومات حول فضاءات أسماء IPC، راجع ipc_namespaces(7).

فقط العملية ذات الامتيازات (CAP_SYS_ADMIN) يمكنها استخدام CLONE_NEWIPC. لا يمكن تحديد هذا العلم بالتزامن مع CLONE_SYSVSEM.

CLONE_NEWNET (منذ لينكس 2.6.24)

(اكتمل تنفيذ هذا العلم فقط في حوالي لينكس 2.6.29.)

إذا ضُبط CLONE_NEWNET، فسيتم إنشاء العملية في فضاء أسماء شبكة جديد. إذا لم يُضبط هذا العلم، فإن العملية (كما في fork(2)) تُنشأ في نفس فضاء أسماء الشبكة الخاص بالعملية المستدعِية.

لمزيد من المعلومات حول فضاءات أسماء الشبكة، راجع network_namespaces(7).

فقط العملية ذات الامتيازات (CAP_SYS_ADMIN) يمكنها استخدام CLONE_NEWNET.

CLONE_NEWNS (منذ لينكس 2.4.19)

إذا ضُبط CLONE_NEWNS، تبدأ الوليدة المستنسخة في فضاء أسماء وصل جديد، يُهيأ بنسخة من فضاء أسماء الأب. إذا لم يُضبط CLONE_NEWNS، تعيش الوليدة في نفس فضاء أسماء الوصل الخاص بالأب.

لمزيد من المعلومات حول فضاءات أسماء الوصل، راجع namespaces(7) و mount_namespaces(7).

فقط العملية ذات الامتيازات (CAP_SYS_ADMIN) يمكنها استخدام CLONE_NEWNS. لا يُسمح بتحديد كل من CLONE_NEWNS و CLONE_FS في نفس استدعاء الاستنساخ.

CLONE_NEWPID (منذ لينكس 2.6.24)

إذا ضُبط CLONE_NEWPID، فسيتم إنشاء العملية في فضاء أسماء PID جديد. إذا لم يُضبط هذا العلم، فإن العملية (كما في fork(2)) تُنشأ في نفس فضاء أسماء PID الخاص بالعملية المستدعِية.

لمزيد من المعلومات حول فضاءات أسماء PID، راجع namespaces(7) و pid_namespaces(7).

فقط العملية ذات الامتيازات (CAP_SYS_ADMIN) يمكنها استخدام CLONE_NEWPID. لا يمكن تحديد هذا العلم بالتزامن مع CLONE_THREAD.

CLONE_NEWUSER

(أصبح هذا العلم ذا معنى لأول مرة لـ clone() في لينكس 2.6.23، ودُمجت دلالات clone() الحالية في لينكس 3.5، ودُمجت الأجزاء النهائية لجعل فضاءات أسماء المستخدمين قابلة للاستخدام بالكامل في لينكس 3.8.)

إذا ضُبط CLONE_NEWUSER، فسيتم إنشاء العملية في فضاء أسماء مستخدم جديد. إذا لم يُضبط هذا العلم، فإن العملية (كما في fork(2)) تُنشأ في نفس فضاء أسماء المستخدمين الخاص بالعملية المستدعِية.

لمزيد من المعلومات حول فضاءات أسماء المستخدمين، راجع namespaces(7) و user_namespaces(7).

قبل لينكس 3.8، كان استخدام CLONE_NEWUSER يتطلب أن يكون لدى المستدعِي ثلاث قدرات: CAP_SYS_ADMIN و CAP_SETUID و CAP_SETGID. بدءًا من لينكس 3.8، لا حاجة لامتيازات لإنشاء فضاء أسماء مستخدم.

لا يمكن تحديد هذا العلم بالتزامن مع CLONE_THREAD أو CLONE_PARENT. لأسباب أمنية، لا يمكن تحديد CLONE_NEWUSER بالتزامن مع CLONE_FS.

CLONE_NEWUTS (منذ لينكس 2.6.19)

إذا ضُبط CLONE_NEWUTS، فسيتم إنشاء العملية في فضاء أسماء UTS جديد، وتُهيأ معرفاته بنسخ المعرفات من فضاء أسماء UTS للعملية المستدعِية. إذا لم يُضبط هذا العلم، فإن العملية (كما في fork(2)) تُنشأ في نفس فضاء أسماء UTS الخاص بالعملية المستدعِية.

لمزيد من المعلومات حول فضاءات أسماء UTS، راجع uts_namespaces(7).

فقط العملية ذات الامتيازات (CAP_SYS_ADMIN) يمكنها استخدام CLONE_NEWUTS.

CLONE_PARENT (منذ لينكس 2.3.12)

إذا ضُبط CLONE_PARENT، فإن أب الوليدة الجديدة (كما تعيده getppid(2)) سيكون هو نفسه أب العملية المستدعِية.

إذا لم يُضبط CLONE_PARENT، فإن أب الوليدة (كما في fork(2)) هو العملية المستدعِية.

لاحظ أن العملية الأب، كما تعيدها getppid(2)، هي التي تتلقى إشارة عند إنهاء الوليدة، بحيث إذا ضُبط CLONE_PARENT، فإن أب العملية المستدعِية، وليس العملية المستدعِية نفسها، هو من يتلقى الإشارة.

لا يمكن استخدام علم CLONE_PARENT في استدعاءات الاستنساخ من قبل عملية البدء العامة (PID 1 في فضاء أسماء PID الأولي) وعمليات البدء في فضاءات أسماء PID الأخرى. يمنع هذا القيد إنشاء أشجار عمليات متعددة الجذور بالإضافة إلى منع إنشاء زومبي لا يمكن حصادهم في فضاء أسماء PID الأولي.

CLONE_PARENT_SETTID (منذ لينكس 2.5.49)

تخزين معرف خيط الوليدة في الموقع الذي يشير إليه parent_tid (في clone()) أو cl_args.parent_tid (في clone3()) في ذاكرة الأب. (في لينكس 2.5.32-2.5.48 كان هناك علم CLONE_SETTID يقوم بذلك.) تكتمل عملية التخزين قبل أن يعيد استدعاء الاستنساخ التحكم إلى مساحة المستخدم.

CLONE_PID (لينكس 2.0 إلى لينكس 2.5.15)

إذا ضُبط CLONE_PID، تُنشأ العملية الوليدة بنفس معرف العملية للمستدعِية. هذا مفيد لاختراق النظام، ولكنه غير مفيد لغير ذلك. من لينكس 2.3.21 فصاعدًا، أصبح بالإمكان تحديد هذا العلم فقط بواسطة عملية تمهيد النظام (PID 0). اختفى العلم تمامًا من مصادر النواة في لينكس 2.5.16. لاحقًا، تجاهلت النواة بصمت هذه البتة إذا حُددت في قناع الأعلام. وبعد فترة طويلة، أُعيد تدوير نفس البتة لاستخدامها كعلم CLONE_PIDFD.

CLONE_PIDFD (منذ لينكس 5.2)

إذا حُدد هذا العلم، يُخصص واصف ملف PID يشير إلى العملية الوليدة ويُوضع في موقع محدد في ذاكرة الأب. يُضبط علم الإغلاق عند التنفيذ (close-on-exec) على واصف الملف الجديد هذا. يمكن استخدام واصفات ملفات PID للأغراض الموضحة في pidfd_open(2).

إذا حُدد CLONE_PIDFD مع CLONE_THREAD، فإن واصف ملف PID الذي تم الحصول عليه يشير إلى خيط معين، بدلاً من متصدر مجموعة الخيوط إذا لم يُحدد CLONE_THREAD. تتوفر هذه الميزة منذ لينكس 6.9.

إذا حُدد علم CLONE_DETACHED المهمل بجانب CLONE_PIDFD عند استدعاء clone()، فسيُعاد خطأ. وينتج خطأ أيضًا إذا حُدد CLONE_DETACHED عند استدعاء clone3(). يضمن سلوك الخطأ هذا إمكانية إعادة استخدام البتة المقابلة لـ CLONE_DETACHED لميزات واصف ملف PID الإضافية في المستقبل.

CLONE_PTRACE (منذ لينكس 2.2)

إذا حُدد CLONE_PTRACE، وكانت العملية المستدعِية تخضع للتتبع، فسيتم تتبع الوليدة أيضًا (راجع ptrace(2)).

CLONE_SETTLS (منذ لينكس 2.5.32)

يُضبط واصف TLS (تخزين الخيط المحلي) على tls.

تفسير tls والأثر الناتج يعتمد على المعمارية. في x86، يُفسر tls على أنه struct user_desc * (راجع set_thread_area(2)). في x86-64 هي القيمة الجديدة التي ستُضبط لسجل القاعدة %fs (راجع معامل ARCH_SET_FS لـ arch_prctl(2)). في المعماريات التي تحتوي على سجل TLS مخصص، فهي القيمة الجديدة لذلك السجل.

يتطلب استخدام هذا العلم معرفة مفصلة وعمومًا لا ينبغي استخدامه إلا في المكتبات التي تنفذ تعدد الخيوط.

CLONE_SIGHAND (منذ لينكس 2.0)

إذا ضُبط CLONE_SIGHAND، تتشارك العملية المستدعِية والوليدة في نفس جدول معالجي الإشارات. إذا استدعت العملية المستدعِية أو الوليدة sigaction(2) لتغيير السلوك المرتبط بإشارة ما، يتغير السلوك في العملية الأخرى أيضًا. ومع ذلك، لا يزال للعملية المستدعِية والوليدة أقنعة إشارات ومجموعات إشارات معلقة متميزة. لذا، يمكن لإحداهما حجب أو إلغاء حجب الإشارات باستخدام sigprocmask(2) دون التأثير على العملية الأخرى.

إذا لم يُضبط CLONE_SIGHAND، ترث العملية الوليدة نسخة من معالجي الإشارات للعملية المستدعِية وقت استدعاء الاستنساخ. الاستدعاءات لـ sigaction(2) التي تُجرى لاحقًا بواسطة إحدى العمليات ليس لها أي تأثير على العملية الأخرى.

منذ لينكس 2.6.0، يجب أن يتضمن قناع flags أيضًا CLONE_VM إذا حُدد CLONE_SIGHAND.

CLONE_STOPPED (منذ لينكس 2.6.0)

إذا ضُبط CLONE_STOPPED، فسيتم إيقاف الوليدة في البداية (كما لو أُرسلت إليها إشارة SIGSTOP)، ويجب استئنافها عن طريق إرسال إشارة SIGCONT إليها.

أُهمل هذا العلم منذ لينكس 2.6.25 فصاعدًا، وأُزيل تمامًا في لينكس 2.6.38. ومنذ ذلك الحين، تتجاهله النواة بصمت دون خطأ. بدءًا من لينكس 4.6، أُعيد تدوير نفس البتة لعلم CLONE_NEWCGROUP.

CLONE_SYSVSEM (منذ لينكس 2.5.10)

إذا ضُبط CLONE_SYSVSEM، تتشارك الوليدة والعملية المستدعِية في قائمة واحدة لقيم تعديل سيمافور System V (تُعرف بـ semadj) (راجع semop(2)). في هذه الحالة، تراكم القائمة المشتركة قيم semadj عبر جميع العمليات التي تتشارك القائمة، وتُجرى تعديلات السيمافور فقط عندما تنتهي آخر عملية تشارك القائمة (أو تتوقف عن مشاركتها باستخدام unshare(2)). إذا لم يُضبط هذا العلم، يكون للوليدة قائمة semadj منفصلة تكون فارغة في البداية.

CLONE_THREAD (منذ لينكس 2.4.0)

إذا ضُبط CLONE_THREAD، تُوضع الوليدة في نفس مجموعة الخيوط التي تتبعها العملية المستدعِية. ولجعل ما تبقى من مناقشة CLONE_THREAD أكثر قابلية للقراءة، استُخدم مصطلح "خيط" للإشارة إلى العمليات داخل مجموعة الخيوط.

كانت مجموعات الخيوط ميزة أضيفت في لينكس 2.4 لدعم مفهوم خيوط POSIX لمجموعة من الخيوط التي تتشارك معرف عملية (PID) واحد. داخليًا، هذا المعرف المشترك هو ما يسمى بمعرف مجموعة الخيوط (TGID). منذ لينكس 2.4، تعيد الاستدعاءات لـ getpid(2) معرف TGID للمستدعِي.

يمكن تمييز الخيوط داخل المجموعة من خلال معرفات الخيوط (TID) الفريدة (على مستوى النظام). يتوفر معرف TID للخيط الجديد كنتيجة دالة تعاد للمستدعِي، ويمكن للخيط الحصول على معرف TID الخاص به باستخدام gettid(2).

عند إجراء استدعاء استنساخ بدون تحديد CLONE_THREAD، يُوضع الخيط الناتج في مجموعة خيوط جديدة يكون معرف TGID الخاص بها هو نفسه معرف TID للخيط. هذا الخيط هو متصدر مجموعة الخيوط الجديدة.

الخيط الجديد المنشأ باستخدام CLONE_THREAD له نفس العملية الأب للعملية التي أجرت استدعاء الاستنساخ (أي، مثل CLONE_PARENT)، بحيث تعيد الاستدعاءات لـ getppid(2) نفس القيمة لجميع الخيوط في مجموعة خيوط واحدة. عندما ينتهي خيط CLONE_THREAD، لا تُرسل للخيط الذي أنشأه إشارة SIGCHLD (أو أي إشارة إنهاء أخرى)؛ ولا يمكن الحصول على حالة مثل هذا الخيط باستخدام wait(2). (يُقال عن الخيط إنه منفصل).

بعد انتهاء جميع الخيوط في مجموعة الخيوط، تُرسل للعملية الأب لمجموعة الخيوط إشارة SIGCHLD (أو إشارة إنهاء أخرى).

إذا قام أي من الخيوط في مجموعة خيوط بتنفيذ execve(2)، فسيتم إنهاء جميع الخيوط الأخرى باستثناء متصدر مجموعة الخيوط، ويُنفذ البرنامج الجديد في متصدر مجموعة الخيوط.

إذا أنشأ أحد الخيوط في مجموعة خيوط وليدة باستخدام fork(2)، فيمكن لأي خيط في المجموعة انتظار (wait(2)) تلك الوليدة.

منذ لينكس 2.5.35، يجب أن يتضمن قناع flags أيضًا CLONE_SIGHAND إذا حُدد CLONE_THREAD (ولاحظ أنه منذ لينكس 2.6.0، يتطلب CLONE_SIGHAND أيضًا تضمين CLONE_VM).

ترتيبات الإشارات وإجراءاتها تكون على مستوى العملية: إذا سُلّمت إشارة غير معالجة إلى خيط ما، فإنها ستؤثر على (تنهي، توقف، تواصل، تُتجاهل في) جميع أعضاء مجموعة الخيوط.

لكل خيط قناع إشارات خاص به، كما يُضبط بواسطة sigprocmask(2).

قد تكون الإشارة موجهة للعملية أو موجهة للخيط. تستهدف الإشارة الموجهة للعملية مجموعة خيوط (أي معرف TGID)، وتُسلّم إلى خيط مختار عشوائيًا من بين تلك التي لا تحجب الإشارة. قد تكون الإشارة موجهة للعملية لأنها نُتجت بواسطة النواة لأسباب أخرى غير استثناء الأجهزة، أو لأنها أُرسلت باستخدام kill(2) أو sigqueue(3). تستهدف الإشارة الموجهة للخيط (أي تُسلّم إلى) خيطًا معينًا. قد تكون الإشارة موجهة للخيط لأنها أُرسلت باستخدام tgkill(2) أو pthread_sigqueue(3)، أو لأن الخيط نفذ تعليمة بلغة الآلة أدت إلى إطلاق استثناء في الأجهزة (على سبيل المثال، وصول غير صالح للذاكرة أطلق SIGSEGV أو استثناء نقطة عائمة أطلق SIGFPE).

يعيد استدعاء sigpending(2) مجموعة إشارات تمثل اتحاد الإشارات المعلقة الموجهة للعملية والإشارات المعلقة للخيط المستدعِي.

إذا سُلّمت إشارة موجهة للعملية إلى مجموعة خيوط، وقامت مجموعة الخيوط بتثبيت معالج للإشارة، فسيتم استدعاء المعالج في عضو واحد بالضبط، يُختار عشوائيًا من أعضاء مجموعة الخيوط الذين لم يحجبوا الإشارة. إذا كانت خيوط متعددة في مجموعة ما تنتظر قبول نفس الإشارة باستخدام sigwaitinfo(2)، فستختار النواة عشوائيًا أحد هذه الخيوط لتلقي الإشارة.

CLONE_UNTRACED (منذ لينكس 2.5.46)

إذا حُدد CLONE_UNTRACED، فلا يمكن لعملية التتبع فرض CLONE_PTRACE على هذه العملية الوليدة.

CLONE_VFORK (منذ لينكس 2.2)

إذا ضُبط CLONE_VFORK، يُعلق تنفيذ العملية المستدعِية حتى تحرر الوليدة موارد ذاكرتها الافتراضية عبر استدعاء execve(2) أو _exit(2) (كما هو الحال مع vfork(2)).

إذا لم يُضبط CLONE_VFORK، فستكون كل من العملية المستدعِية والوليدة قابلتين للجدولة بعد الاستدعاء، ولا ينبغي للتطبيق الاعتماد على حدوث التنفيذ بأي ترتيب معين.

CLONE_VM (منذ لينكس 2.0)

إذا ضُبطت CLONE_VM، فستعمل العملية المستدعية والعملية الوليدة في مساحة الذاكرة ذاتها. وعلى وجه الخصوص، تكون عمليات كتابة الذاكرة التي تجريها العملية المستدعية أو العملية الوليدة مرئية أيضًا في العملية الأخرى. علاوة على ذلك، فإن أي وصل أو فصل لذاكرة يُجرى باستخدام mmap(2) أو munmap(2) بواسطة العملية الوليدة أو المستدعية يؤثر أيضًا في العملية الأخرى.

إذا لم تُضبط CLONE_VM، فستعمل العملية الوليدة في نسخة منفصلة من مساحة ذاكرة العملية المستدعية وقت استدعاء الاستنساخ. ولا تؤثر عمليات كتابة الذاكرة أو وصل/فصل الملفات التي تجريها إحدى العمليتين في الأخرى، تمامًا كما في fork(2).

إذا حُددت علامة CLONE_VM ولم تُحدد علامة CLONE_VFORK، فسيُمسح أي كدس إشارات بديل أُنشئ بواسطة sigaltstack(2) في العملية الوليدة.

الاختلافات بين مكتبة C والنواة¶

استدعاء نظام clone() الخام يتوافق بشكل أوثق مع fork(2) من حيث أن التنفيذ في العملية الوليدة يستمر من نقطة الاستدعاء. وعلى هذا النحو، تُحذف المعطيات fn و arg الخاصة بدالة غلاف clone().

على عكس غلاف glibc، يقبل استدعاء نظام clone() الخام NULL كمعطى لـ stack (وبالمثل يسمح clone3() لـ cl_args.stack بأن يكون NULL). وفي هذه الحالة، تستخدم العملية الوليدة نسخة مكررة من كدس الأب. (تضمن دلالات النسخ عند الكتابة Copy-on-write أن تحصل العملية الوليدة على نسخ منفصلة من صفحات الكدس عندما تقوم أي من العمليتين بتعديل الكدس). وفي هذه الحالة، لضمان التشغيل الصحيح، لا ينبغي تحديد خيار CLONE_VM. (إذا كانت العملية الوليدة تتشارك ذاكرة الأب بسبب استخدام علامة CLONE_VM، فلن يحدث تكرار بالنسخ عند الكتابة ومن المرجح أن يؤدي ذلك إلى حدوث فوضى).

يختلف ترتيب المعطيات أيضًا في استدعاء النظام الخام، وهناك اختلافات في المعطيات عبر المعماريات المختلفة، كما هو مفصل في الفقرات التالية.

واجهة استدعاء النظام الخام في x86-64 وبعض المعماريات الأخرى (بما في ذلك sh و tile و alpha) هي:

long clone(unsigned long flags, void *stack,
           int *parent_tid, int *child_tid,
           unsigned long tls);

في x86-32 وعدة معماريات شائعة أخرى (بما في ذلك score و ARM و ARM 64 و PA-RISC و arc و Power PC و xtensa و MIPS)، ينعكس ترتيب آخر معطيين:

long clone(unsigned long flags, void *stack,
          int *parent_tid, unsigned long tls,
          int *child_tid);

في معماريتي cris و s390، ينعكس ترتيب أول معطيين:

long clone(void *stack, unsigned long flags,
           int *parent_tid, int *child_tid,
           unsigned long tls);

في معمارية microblaze، يُزوّد معطى إضافي:

long clone(unsigned long flags, void *stack,
           int stack_size,         /* حجم الكدس */
           int *parent_tid, int *child_tid,
           unsigned long tls);

blackfin و m68k و sparc¶

اتفاقيات تمرير المعطيات في blackfin و m68k و sparc تختلف عن الأوصاف أعلاه. لمزيد من التفاصيل، انظر مصدر النواة (و glibc).

لينكس 2.4 وما قبله¶

في سلسلة لينكس 2.4.x، لا تجعل CLONE_THREAD بشكل عام أب الخيط الجديد هو نفس أب العملية المستدعية. ومع ذلك، من لينكس 2.4.7 إلى لينكس 2.4.18، كانت علامة CLONE_THREAD تتضمن علامة CLONE_PARENT (كما هو الحال في لينكس 2.6.0 وما بعده).

في لينكس 2.4 وما قبله، لا يأخذ clone() المعطيات parent_tid و tls و child_tid.

ia64¶

في ia64، تُستخدم واجهة مختلفة:

int __clone2(typeof(int (void *)) *fn,
             void *stack_base, size_t stack_size,
             int flags, void *arg, ...
          /* pid_t *parent_tid, struct user_desc *tls,
             pid_t *child_tid */ );

النموذج المبدئي الموضح أعلاه هو لدالة غلاف glibc؛ أما بالنسبة لنداء النظام نفسه، فيمكن وصف النموذج المبدئي على النحو التالي (وهو مطابق لنموذج clone() المبدئي على microblaze):

long clone2(unsigned long flags, void *stack_base,
            int stack_size,         /* حجم المكدس */
            int *parent_tid, int *child_tid,
            unsigned long tls);

تعمل __clone2() بنفس طريقة clone()، باستثناء أن stack_base يشير إلى أدنى عنوان في منطقة مكدس الابن، ويحدد stack_size حجم المكدس الذي يشير إليه stack_base.

مصدر البرنامج¶

#define _GNU_SOURCE
#include <err.h>
#include <sched.h>
#include <signal.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <sys/utsname.h>
#include <sys/wait.h>
#include <unistd.h>
static int              /* دالة البدء للابن المنسوخ */
childFunc(void *arg)
{


    struct utsname uts;


    /* غيّر اسم المضيف في نطاق أسماء UTS للابن.  */


    if (sethostname(arg, strlen(arg)) == -1)


        err(EXIT_FAILURE, "sethostname");


    /* استرجع واعرض اسم المضيف.  */


    if (uname(&uts) == -1)


        err(EXIT_FAILURE, "uname");


    printf("uts.nodename in child:  %s\n", uts.nodename);


    /* أبقِ نطاق الأسماء مفتوحًا لفترة عبر النوم.


       يسمح هذا ببعض التجارب--على سبيل المثال، قد


       تنضم عملية أخرى إلى نطاق الأسماء.  */


    sleep(200);


    return 0;           /* ينتهي الابن الآن */
}
#define STACK_SIZE (1024 * 1024)    /* حجم المكدس للابن المنسوخ */
int
main(int argc, char *argv[])
{


    char            *stack;         /* بداية مخزن المكدس */


    char            *stackTop;      /* نهاية مخزن المكدس */


    pid_t           pid;


    struct utsname  uts;


    if (argc < 2) {


        fprintf(stderr, "Usage: %s <child-hostname>\n", argv[0]);


        exit(EXIT_SUCCESS);


    }


    /* خصص ذاكرة لتستخدم كمكدس للابن.  */


    stack = mmap(NULL, STACK_SIZE, PROT_READ | PROT_WRITE,


                 MAP_PRIVATE | MAP_ANONYMOUS | MAP_STACK, -1, 0);


    if (stack == MAP_FAILED)


        err(EXIT_FAILURE, "mmap");


    stackTop = stack + STACK_SIZE;  /* نفترض أن المكدس ينمو لأسفل */


    /* أنشئ ابنًا له نطاق أسماء UTS الخاص به؛


       يبدأ الابن التنفيذ في childFunc().  */


    pid = clone(childFunc, stackTop, CLONE_NEWUTS | SIGCHLD, argv[1]);


    if (pid == -1)


        err(EXIT_FAILURE, "clone");


    if (munmap(stack, STACK_SIZE))


        err(EXIT_FAILURE, "munmap");


    printf("clone() returned %jd\n", (intmax_t) pid);


    /* يسقط الأب إلى هنا */


    sleep(1);           /* أعطِ الابن وقتًا لتغيير اسم مضيفه */


    /* اعرض اسم المضيف في نطاق أسماء UTS للأب. سيكون هذا


       مختلفًا عن اسم المضيف في نطاق أسماء UTS للابن.  */


    if (uname(&uts) == -1)


        err(EXIT_FAILURE, "uname");


    printf("uts.nodename in parent: %s\n", uts.nodename);


    if (waitpid(pid, NULL, 0) == -1)    /* انتظر الابن */


        err(EXIT_FAILURE, "waitpid");


    printf("child has terminated\n");


    exit(EXIT_SUCCESS);
}