คำถามติดแท็ก system-calls

คำถามเกี่ยวกับรายละเอียดว่าโปรแกรมใช้การเรียกของระบบเพื่อโต้ตอบกับเคอร์เนล API, การโทรใดที่พร้อมใช้งาน, วิธีการทำงาน ฯลฯ

7
ฉันจะค้นหาการนำไปใช้ของการเรียกระบบเคอร์เนล Linux ได้อย่างไร?
ฉันพยายามที่จะเข้าใจว่าฟังก์ชั่นพูด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, …

5
วิธีการค้นหาเส้นทางของแอปพลิเคชันจากบรรทัดคำสั่ง?
ตัวอย่างเช่นฉันได้gitติดตั้งบนระบบของฉัน แต่ฉันจำไม่ได้ว่าติดตั้งไว้ที่ใดดังนั้นคำสั่งใดเหมาะสมที่จะค้นหาคำตอบนี้

2
ระบบเรียก "tuxcall" ทำอะไร?
ในinclude/x86_64-linux-gnu/asm/unistd_64.hฉันเห็นเรียกระบบที่มีชื่อtuxcall, #define __NR_tuxcall 184 ไม่มีอะไรเกี่ยวกับเรื่องนี้man tuxcallนอกจากจะบอกว่าเป็นการเรียกใช้ระบบที่ไม่ได้ดำเนินการ มันทำอะไร มันไม่เคยนำมาใช้หรือทำบางสิ่งในสมัยโบราณ?

4
ทำไมระบบ UNIX / POSIX จึงเรียกการ namings ว่าอ่านไม่ออก?
เป็นเหตุผลที่จะใช้ชื่อเรียกระบบ untelling เช่นอะไรtimeและcreatแทนgetCurrentTimeSecsและcreateFileหรืออาจจะเหมาะสมกว่าบน Unix และget_current_time_secs create_fileซึ่งนำฉันไปยังจุดต่อไป: ทำไมบางคนควรต้องการบางสิ่งบางอย่างเช่นcfsetospeedโดยไม่มีกรณีอูฐหรืออย่างน้อยก็ขีดเพื่อให้สามารถอ่านได้? แน่นอนว่าการโทรจะมีตัวอักษรมากขึ้น แต่เราทุกคนรู้ว่าการอ่านโค้ดมีความสำคัญมากกว่าใช่มั้ย

3
เหตุใดหมายเลขการโทรระบบ Linux ใน x86 และ x86_64 จึงแตกต่างกัน?
ฉันรู้ว่าส่วนต่อประสานการโทรของระบบมีการใช้งานในระดับต่ำและด้วยเหตุนี้ขึ้นอยู่กับสถาปัตยกรรม / แพลตฟอร์มไม่ใช่รหัส "ทั่วไป" แต่ฉันไม่สามารถเห็นได้อย่างชัดเจนว่าทำไมการเรียกระบบในเคอร์เนล x86 แบบ 32 บิตมีหมายเลขที่ไม่เหมือนกันในสถาปัตยกรรมที่คล้ายกัน Linux 64-bit x86_64 แรงจูงใจ / เหตุผลเบื้องหลังการตัดสินใจนี้คืออะไร? การเดาครั้งแรกของฉันคือเหตุผลเบื้องหลังที่ทำให้แอปพลิเคชันแบบ 32 บิตสามารถทำงานได้บนระบบ x86_64 ดังนั้นการชดเชยออฟเซตที่เหมาะสมกับหมายเลขการโทรของระบบระบบจะรู้ว่าพื้นที่ผู้ใช้เป็น 32 บิตหรือ 64 บิต ตามลำดับ อย่างไรก็ตามนี่ไม่ใช่กรณี อย่างน้อยก็สำหรับฉันที่ read () เป็นสายระบบ 0 ใน x86_64 ไม่สามารถปรับให้เข้ากับความคิดนี้ อีกข้อหนึ่งคือการเปลี่ยนหมายเลขโทรศัพท์ของระบบอาจมีพื้นหลังด้านความปลอดภัย / แข็งตัวซึ่งเป็นสิ่งที่ฉันไม่สามารถยืนยันตัวเองได้ ด้วยความไม่รู้ถึงความท้าทายของการใช้งานส่วนของโค้ดที่ขึ้นอยู่กับสถาปัตยกรรมฉันยังสงสัยว่าการเปลี่ยนหมายเลขการโทรของระบบเมื่อดูเหมือนว่าไม่จำเป็น (เพราะแม้แต่การลงทะเบียนแบบ 16 บิตจะเก็บไว้มากกว่านั้นในปัจจุบัน ~ 346 การเรียกใช้) จะช่วยให้บรรลุผลทุกอย่างนอกเหนือจากความเข้ากันได้ของการแบ่ง (แม้ว่าการใช้การเรียกของระบบผ่านทางไลบรารี libc จะช่วยลดความมัน)

2
การขัดจังหวะของการโทรของระบบเมื่อจับสัญญาณ
จากการอ่าน man page บนread()และการwrite()โทรปรากฏว่าการโทรเหล่านี้ถูกขัดจังหวะด้วยสัญญาณโดยไม่คำนึงว่าพวกเขาจะต้องปิดกั้นหรือไม่ โดยเฉพาะสมมติว่า กระบวนการสร้างตัวจัดการสำหรับสัญญาณบางอย่าง อุปกรณ์ถูกเปิด (พูดเทอร์มินัล) โดยที่O_NONBLOCK ไม่ได้ตั้งค่า (เช่นทำงานในโหมดบล็อก) กระบวนการนี้ทำให้การread()เรียกระบบอ่านจากอุปกรณ์และผลลัพธ์จะดำเนินการพา ธ ควบคุมเคอร์เนลในเคอร์เนลพื้นที่ ในขณะที่กระบวนการดำเนินการอยู่read()ใน kernel-space สัญญาณที่ติดตั้งตัวจัดการไว้ก่อนหน้านี้จะถูกส่งไปยังกระบวนการนั้นและตัวจัดการสัญญาณถูกเรียกใช้ การอ่าน man man และส่วนที่เหมาะสมในSUSv3 'System Interfaces volume (XSH)' , หนึ่งพบว่า: ผม. หาก a read()ถูกขัดจังหวะโดยสัญญาณก่อนที่จะอ่านข้อมูลใด ๆ (นั่นคือต้องปิดกั้นเพราะไม่มีข้อมูล) จะส่งกลับ -1 ด้วยการerrnoตั้งค่าเป็น [EINTR] ii หาก a read()ถูกขัดจังหวะโดยสัญญาณหลังจากอ่านข้อมูลเรียบร้อยแล้ว (เช่นเป็นไปได้ที่จะเริ่มให้บริการตามคำขอทันที) มันจะส่งคืนจำนวนไบต์ที่อ่าน คำถาม A): ฉันถูกต้องหรือไม่ที่จะสมมติว่าในกรณีใด ๆ (บล็อก / ไม่มีบล็อก) …

2
fork () อยู่ที่ fork fork ที่ไหน: () {: |: &};:?
คำเตือน: การเรียกใช้คำสั่งนี้ในเชลล์ส่วนใหญ่จะส่งผลให้ระบบแตกหักซึ่งจะต้องบังคับให้ปิดระบบเพื่อแก้ไข ฉันเข้าใจฟังก์ชั่นวนซ้ำ:(){ :|: & };:และสิ่งที่ทำ แต่ฉันไม่รู้ว่าระบบสายส้อมอยู่ที่ไหน ผมไม่แน่ใจ |แต่ผมสงสัยว่าในท่อ

2
อะไรคือจุดประสงค์ของอาร์กิวเมนต์แรกในการเลือกการเรียกของระบบ?
จาก man select int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout); nfds เป็นตัวบอกไฟล์ที่มีหมายเลขสูงสุดในสามชุดใด ๆ บวก 1 วัตถุประสงค์ของการคืออะไรnfdsเมื่อเรามีอยู่แล้วreadfds, writefdsและexceptfdsจากการที่อธิบายไฟล์สามารถกำหนด?

1
การเรียกระบบ getrusage: อะไรคือ“ ขนาดชุดผู้พักอาศัยสูงสุด
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. ดังนั้นตัวเลขนี้มีความหมายว่าอะไร?

4
วิธีทำความเข้าใจท่อ
เมื่อฉันใช้ไปป์ในการทุบตีฉันไม่ได้คิดถึงเรื่องนี้มากขึ้น แต่เมื่อฉันอ่านตัวอย่างรหัส C โดยใช้ system call pipe () ร่วมกับ fork () ฉันสงสัยว่าจะเข้าใจไพพ์ได้อย่างไรรวมถึงไพพ์นิรนามและไพพ์ที่มีชื่อ มักจะได้ยินว่า "ทุกอย่างใน Linux / Unix เป็นไฟล์" ฉันสงสัยว่าไพพ์เป็นไฟล์จริงหรือไม่เพื่อให้ส่วนหนึ่งเชื่อมต่อการเขียนไปยังไฟล์ไพพ์และอีกส่วนหนึ่งอ่านจากไฟล์ไพพ์หรือไม่ ถ้าใช่ไฟล์ไพพ์ของไพพ์นิรนามจะถูกสร้างขึ้นที่ไหน? ใน / tmp, / dev หรือ ... ? อย่างไรก็ตามจากตัวอย่างของ pipes ที่มีชื่อฉันยังได้เรียนรู้ว่าการใช้ไพพ์มีข้อได้เปรียบด้านพื้นที่และเวลามากกว่าการใช้ไฟล์ชั่วคราวอย่างชัดเจนอาจเป็นเพราะไม่มีไฟล์ที่เกี่ยวข้องในการใช้ไพพ์ ท่อดูเหมือนจะไม่เก็บข้อมูลเช่นเดียวกับไฟล์ ดังนั้นฉันจึงสงสัยว่าไพพ์เป็นไฟล์จริงๆ

4
แห่กัน (2) กับ fcntl (2) มากกว่า NFS
เอกสารประกอบของ Perl 5.x ระบุว่าการใช้งาน flock (.. ) จะใช้หนึ่งในการโทรแบบเนทีฟต่อไปนี้เริ่มต้นที่ 1 และทำงานไปที่ 3 หากไม่พร้อมใช้งาน: แห่กัน (2) fcntl (2) lockf (3) ไม่เป็นไร. อย่างไรก็ตามคุณอาจสังเกตเห็นข้อจำกัดความรับผิดชอบของพวกเขาว่าไม่ควรใช้ฝูง (2) ผ่าน NFS เอกสารแนะนำให้ใช้แฟล็ก -Ud_flock เพื่อบังคับให้ Perl ใช้ฝูง (2) หน้าคนของฝูง (2) (บน Redhat) ระบุข้อจำกัดความรับผิดชอบที่คล้ายกันเกี่ยวกับปัญหา NFS คำถามของฉันคือทำไม!?!? ฉันไม่สามารถหาบทความเชิงลึกหรือคำอธิบายของ WHY flock (2) ที่ไม่ปลอดภัยผ่าน NFS ฉันได้เขียนสคริปต์ทดสอบหลายชุดใน C และ Perl ทั้งบน Redhat (ที่มีการใช้ฝูง (2)) …
19 nfs  system-calls 

3
ความสัมพันธ์ระหว่างการเรียกของระบบการส่งข้อความและการขัดจังหวะคืออะไร?
ฉันอ่านบทความวิกิพีเดียสำหรับการจัดการกระบวนการ ฉันมุ่งเน้นไปที่ Linux ฉันไม่สามารถหาความสัมพันธ์และความแตกต่างระหว่างการเรียกของระบบการส่งข้อความและขัดจังหวะในแนวคิดและวัตถุประสงค์ของพวกเขา พวกเขาทั้งหมดสำหรับกระบวนการในการร้องขอเคอร์เนลสำหรับทรัพยากรและบริการ? บางคำพูดจากบทความและอื่น ๆ : มีสองวิธีที่เป็นไปได้สำหรับระบบปฏิบัติการที่จะได้รับการควบคุมของหน่วยประมวลผลในระหว่างการดำเนินการของโปรแกรมเพื่อให้ระบบปฏิบัติการที่จะทำการจัดสรรหรือการจัดสรร: กระบวนการออกสายระบบ (บางครั้งเรียกว่าซอฟต์แวร์ขัดจังหวะ); ตัวอย่างเช่นคำขอ I / O เกิดขึ้นเพื่อขอให้เข้าถึงไฟล์บนฮาร์ดดิสก์ การขัดจังหวะของฮาร์ดแวร์เกิดขึ้น ตัวอย่างเช่นมีการกดแป้นบนแป้นพิมพ์หรือตัวจับเวลาหมด (ใช้ในมัลติทาสก์แบบ pre-emptive) มีสองเทคนิคที่โปรแกรมดำเนินการในโหมดผู้ใช้สามารถร้องขอบริการของเคอร์เนลได้: * System call * Message passing อินเทอร์รัปต์เป็นสัญญาณอะซิงโครนัสที่ระบุถึงความต้องการความสนใจหรือเหตุการณ์ซิงโครนัสในซอฟต์แวร์ที่ระบุถึงความต้องการการเปลี่ยนแปลงในการดำเนินการ ฮาร์ดแวร์ขัดจังหวะทำให้โปรเซสเซอร์บันทึกสถานะของการดำเนินการและเริ่มต้นการดำเนินการของตัวจัดการขัดจังหวะ การขัดจังหวะของซอฟต์แวร์มักจะนำมาใช้เป็นคำแนะนำในชุดคำสั่งซึ่งทำให้การสลับบริบทเป็นตัวจัดการขัดจังหวะคล้ายกับการขัดจังหวะฮาร์ดแวร์

5
“ การเรียกของระบบ” มีความหมายอย่างไรหากไม่มีการใช้งานในภาษาโปรแกรม
ฉันต้องการที่จะเข้าใจคำว่า "การเรียกระบบ" ฉันคุ้นเคยกับการเรียกใช้ระบบเพื่อรับบริการเคอร์เนลจากแอปพลิเคชัน userspace ส่วนที่ฉันต้องการชี้แจงด้วยคือความแตกต่างระหว่าง "การเรียกระบบ" และ "การใช้งาน C ของการเรียกระบบ" นี่คือข้อความที่ทำให้ฉันสับสน: บนระบบที่คล้าย Unix API นั้นมักจะเป็นส่วนหนึ่งของการใช้งาน C library (libc) เช่น glibc ซึ่งมีฟังก์ชั่น wrapper สำหรับการโทรของระบบซึ่งมักจะตั้งชื่อเหมือนกับการเรียกระบบที่พวกเขาเรียก "การเรียกระบบที่พวกเขาเรียก" คืออะไร? แหล่งของพวกเขาอยู่ที่ไหน ฉันสามารถรวมพวกเขาโดยตรงในรหัสของฉัน? "การเรียกของระบบ" ในแง่สามัญเพียงแค่ POSIX อินเตอร์เฟสที่กำหนด แต่จริง ๆ แล้วเห็นการใช้งานอย่างใดอย่างหนึ่งสามารถตรวจสอบแหล่ง C และในนั้นดูว่าผู้ใช้จริงเพื่อการสื่อสารเคอร์เนลจริงไป? บันทึกพื้นหลัง: /devฉันพยายามที่จะเข้าใจถ้าในท้ายที่สุดแต่ละฟังก์ชั่นคปลายขึ้นโต้ตอบกับอุปกรณ์จาก
14 kernel  c  posix  system-calls 

1
TCP แอดเดรสซ็อกเก็ตโลคัลที่ถูกผูกไว้ไม่พร้อมใช้งานนานเท่าใดหลังจากปิดแล้ว
บน 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 วินาที" ที่ซึ่งฉันสะดุดอยู่ในการเชื่อมช่องว่างระหว่างโมเดลของเคอร์เนลของวงจรชีวิต …

2
ความแตกต่างระหว่างการเรียกของระบบช้าและการเรียกของระบบอย่างรวดเร็ว
ความแตกต่างระหว่างการเรียกของระบบช้าและการเรียกของระบบเร็วคืออะไร ฉันได้เรียนรู้ว่าการเรียกของระบบที่ช้าสามารถบล็อกได้หากกระบวนการจับสัญญาณบางอย่างเนื่องจากสัญญาณที่จับได้อาจทำให้การโทรของระบบถูกปิดกั้น แต่ฉันไม่เข้าใจกลไกนี้อย่างแน่นอน ตัวอย่างใด ๆ ที่จะได้รับการชื่นชม

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.