💪🏽 ☄️ 💂 Mkdir सिस्टम कॉल कोड खोजें 🧚🏼 ⏫ 🧑🏿‍🤝‍🧑🏼

यहां तक कि उबंटू के साथ अपने परिचित के पहले वर्ष में, मुझे इस बात में दिलचस्पी हो गई कि इस ओएस के कर्नेल कैसे काम करते हैं। मैंने इसका पता लगाने के लिए पूरी गंभीरता के साथ निर्णय लिया, 80-मेगाबाइट स्रोत संग्रह डाउनलोड किया, और ... यह बात है! मुझे नहीं पता था कि कहां से शुरू करना है, न ही कैसे खत्म करना है। मैंने बदले में यादृच्छिक फाइलें खोलीं और वहीं खो गया। मुझे लगता है कि यह हर अनुभवी Linuxoid के साथ हुआ। अब मुझे अनुभव प्राप्त हुआ है और मैं इसे साझा करना चाहूंगा।

इस लेख में मैं समझाऊंगा कि मैंने 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));

यह हेडर फ़ाइल POSIX मानक का हिस्सा है। लिनक्स लगभग पूरी तरह से POSIX- संगत है, जिसका अर्थ है कि इसे केवल हस्ताक्षर के साथ mkdir को लागू करना चाहिए।

लेकिन हस्ताक्षर जानने के बावजूद, वास्तविक सिस्टम कॉल कोड ढूंढना आसान नहीं है ...

और सच में ack "int mkdir" वापस आएगा:

सुरक्षा / इनकोड
103: स्थिर इंट mkdir (स्ट्रक्चर इनोड * dir, स्ट्रक्चर डेंट्री * डेंट्री, इंट मोड)

उपकरण / पूर्ण / उपयोग / उपयोग.c
4: int mkdir_p (char * path, mode_t mode)

उपकरण / इत्र / उपयोग / उपयोग
259: int mkdir_p (char * path, mode_t mode);

यह स्पष्ट है कि एक भी हस्ताक्षर पूरी तरह से मेल नहीं खाता है। एमकेडीआर फ़ंक्शन कार्यान्वयन कहाँ स्थित है? लिनक्स कर्नेल में सिस्टम कॉल के कार्यान्वयन को खोजने के लिए एल्गोरिथ्म क्या है?

सिस्टम कॉल नियमित कार्यों की तरह काम नहीं करते हैं। अधिक सटीक रूप से, वे सभी कार्य नहीं हैं। सिस्टम कॉल को निष्पादित करने के लिए, आपको कुछ कोडांतरक कोड की आवश्यकता होती है। द्वारा और बड़े, सिस्टम कॉल नंबर को EAX रजिस्टर में रखा जाता है (वैसे, सिस्टम कॉल नंबर द्वारा एक्सेस किया जाता है, एड्रेस नहीं), शेष रजिस्टर में दलीलें रखी जाती हैं: पहला EBX में, दूसरा ECX में, दूसरा EDX में, ESX में चौथा। ईडीआई में पांचवें। वैसे, यही कारण है कि एक सिस्टम कॉल में 5 से अधिक तर्क नहीं हो सकते हैं। सभी आवश्यक मान स्थित होने के बाद, प्रोग्राम जो एक सिस्टम कॉल करना चाहता है, वह 128 वां व्यवधान करता है (कोडांतरक: इंट 0 08080 पर)। रुकावट प्रोसेसर को कर्नेल मोड में रखता है और कर्नेल के साथ पहले से सहमत पते पर नियंत्रण स्थानांतरित करता है। जैसा कि आप देख सकते हैं, सिस्टम कॉल सी-फ़ंक्शंस की तुलना में निचले स्तर पर काम करते हैं।

किसी भी सिस्टम कॉल की संख्या usr/include/asm*/unistd.h में पाई जा सकती है usr/include/asm*/unistd.h :

 #define __NR_mkdir 83 __SYSCALL(__NR_mkdir, sys_mkdir)

यानी mkdir सिस्टम कॉल 83 नंबर की है।

यदि आपने लिनक्स के तहत यूजर स्पेस में प्रोग्राम किया है, तो आप शायद जानते हैं कि, एक नियम के रूप में, सिस्टम कॉल करने के लिए C फ़ंक्शन का उपयोग किया जाता है। वे कहाँ से आते हैं? वे कार्य GNU libc लाइब्रेरी से सिर्फ रैपर हैं। प्रत्येक सिस्टम कॉल में एक रैपर फ़ंक्शन होता है। कार्य स्वयं सभी समान व्यवधान करते हैं।

तो अब मुक्दिर की तलाश कहाँ करें? सिद्धांत रूप में, एक सिस्टम कॉल को केवल कोडांतरक में लागू किया जा सकता है, फिर संबंधित सी-फ़ंक्शन बस मौजूद नहीं होगा, लेकिन ऐसा नहीं है। लिनक्स पर, हर सिस्टम कॉल include/linux/syscalls.h :

 asmlinkage long sys_mkdir(const char __user *pathname, int mode);

कार्यान्वयन कर्नेल के संगत भाग में स्थित है। यहाँ आपको यह जानना होगा कि mkdir VFS फाइल सबसिस्टम का हिस्सा है और इसे fs/namei.c में परिभाषित किया गया है:

 SYSCALL_DEFINE2(mkdir, const char __user *, pathname, umode_t, mode) { return sys_mkdirat(AT_FDCWD, pathname, mode); }

SYSCALL_DEFINE2 SYSCALL_DEFINEx श्रृंखला में मैक्रोज़ में से एक है, जहाँ x सिस्टम कॉल के लिए तर्कों की संख्या है। उपरोक्त कोड में, एक और सिस्टम कॉल कहा जाता है - sys_mkdirat, जो fs/namei.c में भी स्थित है। कृपया ध्यान दें कि यहां फ़ंक्शन कॉल करके सिस्टम कॉल किया जाता है, क्योंकि कॉलिंग कोड पहले से ही कर्नेल मोड में निष्पादित हो रहा है।

 SYSCALL_DEFINE3(mkdirat, int, dfd, const char __user *, pathname, umode_t, mode) { struct dentry *dentry; struct path path; int error; dentry = user_path_create(dfd, pathname, &path, 1); if (IS_ERR(dentry)) return PTR_ERR(dentry); if (!IS_POSIXACL(path.dentry->d_inode)) mode &= ~current_umask(); error = security_path_mkdir(&path, dentry, mode); if (!error) error = vfs_mkdir(path.dentry->d_inode, dentry, mode); done_path_create(&path, dentry); return error; }

और यहाँ पहले से ही दिलचस्प है! हम पहले चेक और फिर से दूसरे फ़ंक्शन पर नियंत्रण के हस्तांतरण को पूरा करते हैं - vfs_mkdir, जो सभी को एक ही fs/namei.h में परिभाषित किया गया है:

 int vfs_mkdir(struct inode *dir, struct dentry *dentry, umode_t mode) { int error = may_create(dir, dentry); unsigned max_links = dir->i_sb->s_max_links; if (error) return error; if (!dir->i_op->mkdir) return -EPERM; mode &= (S_IRWXUGO|S_ISVTX); error = security_inode_mkdir(dir, dentry, mode); if (error) return error; if (max_links && dir->i_nlink >= max_links) return -EMLINK; error = dir->i_op->mkdir(dir, dentry, mode); if (!error) fsnotify_mkdir(dir, dentry); return error; }

एक और जाँच, नियंत्रण का एक और हस्तांतरण। यह कहने योग्य है कि लिनक्स एक बहु-स्तरीय प्रणाली है, जहां सिस्टम के विभिन्न हिस्सों में जिम्मेदारियां वितरित की जाती हैं। इसलिए, यह अजीब नहीं है कि ऊपर दिए गए कोड में, तर्क को लगातार प्रत्यायोजित किया जाता है। कोड के अंतिम टुकड़े में, dir-> i_op-> mkdir (dir, dentry, mode) कहा जाता है। राह का अनुसरण करो! dir टाइप इनोड * का है। इनोड संरचना की परिभाषा से, हम सीखते हैं कि i_op पॉइंटर inode_operations * प्रकार का है। अंतिम संरचना में इस नोड पर किए जाने वाले संचालन के कार्यों के लिए पॉइंटर्स होते हैं, और कार्यान्वयन अलग-अलग फ़ाइल सिस्टम के लिए अलग-अलग होते हैं। यह है कि, जो फ़ाइल सिस्टम हमारे dir से संबंधित है, उस पर निर्भर करता है कि इनोड_ऑपरेशन संरचना में कुछ कार्यान्वयन के लिए पॉइंटर्स होंगे।

उदाहरण के लिए, ext4 के लिए, हम fs / ext4 / namei.c में mkdir का कार्यान्वयन पाते हैं

वास्तव में वांछित कोड!

 static int ext4_mkdir(struct inode *dir, struct dentry *dentry, umode_t mode) { handle_t *handle; struct inode *inode; struct buffer_head *dir_block = NULL; struct ext4_dir_entry_2 *de; struct ext4_dir_entry_tail *t; unsigned int blocksize = dir->i_sb->s_blocksize; int csum_size = 0; int err, retries = 0; if (EXT4_HAS_RO_COMPAT_FEATURE(dir->i_sb, EXT4_FEATURE_RO_COMPAT_METADATA_CSUM)) csum_size = sizeof(struct ext4_dir_entry_tail); if (EXT4_DIR_LINK_MAX(dir)) return -EMLINK; dquot_initialize(dir); retry: handle = ext4_journal_start(dir, EXT4_DATA_TRANS_BLOCKS(dir->i_sb) + EXT4_INDEX_EXTRA_TRANS_BLOCKS + 3 + EXT4_MAXQUOTAS_INIT_BLOCKS(dir->i_sb)); if (IS_ERR(handle)) return PTR_ERR(handle); if (IS_DIRSYNC(dir)) ext4_handle_sync(handle); inode = ext4_new_inode(handle, dir, S_IFDIR | mode, &dentry->d_name, 0, NULL); err = PTR_ERR(inode); if (IS_ERR(inode)) goto out_stop; inode->i_op = &ext4_dir_inode_operations; inode->i_fop = &ext4_dir_operations; inode->i_size = EXT4_I(inode)->i_disksize = inode->i_sb->s_blocksize; if (!(dir_block = ext4_bread(handle, inode, 0, 1, &err))) { if (!err) { err = -EIO; ext4_error(inode->i_sb, "Directory hole detected on inode %lu\n", inode->i_ino); } goto out_clear_inode; } BUFFER_TRACE(dir_block, "get_write_access"); err = ext4_journal_get_write_access(handle, dir_block); if (err) goto out_clear_inode; de = (struct ext4_dir_entry_2 *) dir_block->b_data; de->inode = cpu_to_le32(inode->i_ino); de->name_len = 1; de->rec_len = ext4_rec_len_to_disk(EXT4_DIR_REC_LEN(de->name_len), blocksize); strcpy(de->name, "."); ext4_set_de_type(dir->i_sb, de, S_IFDIR); de = ext4_next_entry(de, blocksize); de->inode = cpu_to_le32(dir->i_ino); de->rec_len = ext4_rec_len_to_disk(blocksize - (csum_size + EXT4_DIR_REC_LEN(1)), blocksize); de->name_len = 2; strcpy(de->name, ".."); ext4_set_de_type(dir->i_sb, de, S_IFDIR); set_nlink(inode, 2); if (csum_size) { t = EXT4_DIRENT_TAIL(dir_block->b_data, blocksize); initialize_dirent_tail(t, blocksize); } BUFFER_TRACE(dir_block, "call ext4_handle_dirty_metadata"); err = ext4_handle_dirty_dirent_node(handle, inode, dir_block); if (err) goto out_clear_inode; set_buffer_verified(dir_block); err = ext4_mark_inode_dirty(handle, inode); if (!err) err = ext4_add_entry(handle, dentry, inode); if (err) { out_clear_inode: clear_nlink(inode); unlock_new_inode(inode); ext4_mark_inode_dirty(handle, inode); iput(inode); goto out_stop; } ext4_inc_count(handle, dir); ext4_update_dx_flag(dir); err = ext4_mark_inode_dirty(handle, dir); if (err) goto out_clear_inode; unlock_new_inode(inode); d_instantiate(dentry, inode); out_stop: brelse(dir_block); ext4_journal_stop(handle); if (err == -ENOSPC && ext4_should_retry_alloc(dir->i_sb, &retries)) goto retry; return err; }

कर्नेल के संचालन को समझना किसी भी लिनक्सॉइड के शस्त्रागार में एक उपयोगी कौशल है। आशा है कि यह लेख भी उपयोगी रहा है!

संसाधन:
लिनक्स सिस्टम कॉल टेबल
लिनक्स 3.6 स्रोत
Unix.stackexchange.com पर चर्चा

Mkdir सिस्टम कॉल कोड खोजें

More articles: