ट्रस्टी एपीआई रेफ़रंस

Trusty ऐप्लिकेशन/सेवाओं के दो क्लास डेवलप करने के लिए एपीआई उपलब्ध कराता है:

• TEE प्रोसेसर पर चलने वाले भरोसेमंद ऐप्लिकेशन या सेवाएं
• सामान्य/भरोसेमंद ऐप्लिकेशन, जो मुख्य प्रोसेसर पर चलते हैं और दी गई सेवाओं का इस्तेमाल करते हैं भरोसेमंद ऐप्लिकेशन से

भरोसेमंद आम तौर पर, एपीआई एक ट्रस्टी इंटर-प्रोसेस कम्यूनिकेशन (आईपीसी) सिस्टम के बारे में बताता है, जिसमें असुरक्षित दुनिया से संपर्क करना भी शामिल है. Android पर मुख्य प्रोसेसर, भरोसेमंद ऐप्लिकेशन/सेवाओं से कनेक्ट करने के लिए Trusty API का इस्तेमाल कर सकता है और आईपी पर नेटवर्क सेवा की तरह ही आर्बिट्रेरी मैसेज का लेन-देन करते हैं. इनके डेटा फ़ॉर्मैट और सिमेंटिक्स का फ़ैसला ऐप्लिकेशन पर निर्भर करता है मैसेज भी खोज सकते हैं. भरोसेमंद मैसेज डिलीवर करने की सुविधा ट्रस्टी इन्फ़्रास्ट्रक्चर से मिलने वाली गारंटी (ड्राइवर के रूप में) मुख्य प्रोसेसर पर चल रहा है), और कम्यूनिकेशन पूरी तरह से एसिंक्रोनस है.

पोर्ट और चैनल

ट्रस्टी ऐप्लिकेशन, पोर्ट का इस्तेमाल सेवा के आखिरी पॉइंट को फ़ॉर्म में दिखाने के लिए करते हैं का नाम पाथ है, जिससे क्लाइंट कनेक्ट होते हैं. यह एक आसान, स्ट्रिंग-आधारित सेवा आईडी डालें. नाम रखने का तरीका रिवर्स डीएनएस-स्टाइल है नाम, जैसे com.google.servicename.

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

सिर्फ़ सुरक्षित-साइड के भरोसेमंद ऐप्लिकेशन या ट्रस्टी कर्नेल मॉड्यूल ही बना सकते हैं पोर्ट. असुरक्षित साइट पर चलने वाले ऐप्लिकेशन (सामान्य दुनिया में) सिर्फ़ सुरक्षित पक्ष से पब्लिश की गई सेवाओं से कनेक्ट करें.

ज़रूरत के हिसाब से भरोसेमंद ऐप्लिकेशन, क्लाइंट और एक ही समय पर सेट करें. एक भरोसेमंद ऐप्लिकेशन, जो आपकी साइट पर आने वाली सर्वर) को अन्य सेवाओं (क्लाइंट के रूप में) से कनेक्ट करने की ज़रूरत पड़ सकती है.

हैंडल एपीआई

हैंडल, बिना हस्ताक्षर वाले पूर्णांक होते हैं. इनसे पोर्ट और पोर्ट जैसे संसाधनों के बारे में पता चलता है चैनल, जो UNIX में फ़ाइल डिस्क्रिप्टर से मिलते-जुलते हैं. हैंडल बनने के बाद, एक खास ऐप्लिकेशन के हिसाब से बनाई गई हैंडल टेबल में रखे जाते हैं और उनका रेफ़रंस दिया जा सकता है. बाद में.

कॉल करने वाला (कॉलर) निजी डेटा को हैंडल से जोड़ सकता है. इसके लिए, set_cookie() तरीका.

हैंडल एपीआई में तरीके

हैंडल सिर्फ़ ऐप्लिकेशन के लिए मान्य होते हैं. ऐप्लिकेशन को यह करना चाहिए किसी हैंडल की वैल्यू को तब तक दूसरे ऐप्लिकेशन को पास नहीं करता है, जब तक कि बताया गया है. हैंडल वैल्यू की तुलना, हैंडल वैल्यू से की जानी चाहिए INVALID_IPC_HANDLE #define,, जिसका इस्तेमाल ऐप्लिकेशन यह बताता है कि हैंडल अमान्य है या सेट नहीं किया गया है.

set_cookie()

कॉलर से मिले निजी डेटा को किसी खास हैंडल से जोड़ता है.

long set_cookie(uint32_t handle, void *cookie)

[in] handle: एपीआई कॉल से रिस्पॉन्स मिलने वाला कोई भी हैंडल

[in] cookie: ट्रस्टी ऐप्लिकेशन में आर्बिट्रेरी यूज़र-स्पेस डेटा की ओर पॉइंटर

[retval]: सही होने पर NO_ERROR, नहीं तो < 0 गड़बड़ी कोड

इस कॉल की मदद से, बाद के इवेंट मैनेज किए जा सकते हैं हैंडल बना दिया गया है. इवेंट को हैंडल करने का तरीका, हैंडल को उपलब्ध कराता है और इसकी कुकी को इवेंट हैंडलर पर वापस ले जाता है.

किसी इवेंट के लिए, wait() कॉल का इस्तेमाल करके हैंडल का इंतज़ार किया जा सकता है.

इंतज़ार करें()

तय समय के लिए, दिए गए हैंडल पर इवेंट के होने का इंतज़ार करता है.

long wait(uint32_t handle_id, uevent_t *event, unsigned long timeout_msecs)

[in] handle_id: एपीआई कॉल से रिस्पॉन्स मिलने वाला कोई भी हैंडल

[out] event: उस स्ट्रक्चर का पॉइंटर जो इस हैंडल में हुआ कोई इवेंट

[in] timeout_msecs: मिलीसेकंड में टाइम आउट वैल्यू; एक -1 की वैल्यू, अनंत टाइम आउट है

[retval]: NO_ERROR अगर इवेंट के दौरान कोई मान्य इवेंट हुआ हो बताया गया टाइम आउट इंटरवल; ERR_TIMED_OUT अगर टाइम आउट बीत गया है, लेकिन नहीं कोई गतिविधि हुई है; अन्य गड़बड़ियों के लिए < 0

(retval == NO_ERROR) पूरा होने पर, wait() कॉल किसी तय uevent_t स्ट्रक्चर में, कुछ भी नहीं हुआ.

typedef struct uevent {
    uint32_t handle; /* handle this event is related to */
    uint32_t event;  /* combination of IPC_HANDLE_POLL_XXX flags */
    void    *cookie; /* cookie associated with this handle */
} uevent_t;

event फ़ील्ड में इन वैल्यू का कॉम्बिनेशन शामिल होता है:

enum {
  IPC_HANDLE_POLL_NONE    = 0x0,
  IPC_HANDLE_POLL_READY   = 0x1,
  IPC_HANDLE_POLL_ERROR   = 0x2,
  IPC_HANDLE_POLL_HUP     = 0x4,
  IPC_HANDLE_POLL_MSG     = 0x8,
  IPC_HANDLE_POLL_SEND_UNBLOCKED = 0x10,
  … more values[TBD]
};

IPC_HANDLE_POLL_NONE - कोई भी इवेंट अधूरी है, कॉलर को इंतज़ार करना होगा

IPC_HANDLE_POLL_ERROR - कोई ऐसी अंदरूनी गड़बड़ी हुई है जिसके बारे में जानकारी नहीं है

IPC_HANDLE_POLL_READY - हैंडल टाइप के आधार पर, नीचे दिया गया है:

• पोर्ट के लिए, यह मान संकेत देता है कि कोई कनेक्शन लंबित है
• चैनलों के लिए, इस वैल्यू से पता चलता है कि एसिंक्रोनस कनेक्शन (connect() देखें) को स्थापित किया गया था

ये इवेंट सिर्फ़ चैनलों के लिए काम के हैं:

• IPC_HANDLE_POLL_HUP - इससे पता चलता है कि किसी साथी ने चैनल को बंद कर दिया है
• IPC_HANDLE_POLL_MSG - बताता है कि इस चैनल के लिए एक मैसेज को मंज़ूरी मिलना बाकी है
• IPC_HANDLE_POLL_SEND_UNBLOCKED - से पता चलता है कि पहले भेजने वाला ब्लॉक किया गया कॉलर फिर से मैसेज भेजें (ज़्यादा जानकारी के लिए send_msg() का ब्यौरा देखें)

एक इवेंट हैंडलर को तय किए गए कॉम्बिनेशन को हैंडल करने के लिए तैयार किया जाना चाहिए इवेंट लिए जाते हैं, क्योंकि एक ही समय में कई बिट सेट किए जा सकते हैं. उदाहरण के लिए, हों, तो हो सकता है कि मैसेज की मंज़ूरी बाकी न हो. साथ ही, एक साथ.

ज़्यादातर इवेंट स्टिकी हैं. वे तब तक बने रहते हैं, जब तक बुनियादी स्थितियां तय होती हैं बनी रहती है (उदाहरण के लिए, सभी मैसेज मिल गए हैं और कनेक्शन बाकी है अनुरोधों को हैंडल किया जाता है). अपवाद का मामला है IPC_HANDLE_POLL_SEND_UNBLOCKED इवेंट हुआ, जो उसे पढ़ने पर साफ़ कर दिया जाता है और ऐप्लिकेशन में हैंडल करें.

close() तरीके का इस्तेमाल करके, हैंडल मिटाए जा सकते हैं.

बंद करें()

बताए गए हैंडल से जुड़े संसाधन को खत्म कर देता है और इसे यहां से हटा देता है हैंडल टेबल.

long close(uint32_t handle_id);

[in] handle_id: मिटाने के लिए हैंडल करें

[retval]: अगर सफलता मिली है, तो 0; अगर कोई गड़बड़ी हुई है, तो

सर्वर एपीआई

सर्वर की शुरुआत एक या एक से ज़्यादा ऐसे नाम वाले पोर्ट बनाने से होती है जो इसके सेवा के आखिरी पॉइंट. हर पोर्ट को एक हैंडल से दिखाया जाता है.

Server API में तरीके

Port_create()

नाम वाला सर्विस पोर्ट बनाता है.

long port_create (const char *path, uint num_recv_bufs, size_t recv_buf_size,
uint32_t flags)

[in] path: पोर्ट का स्ट्रिंग नाम (जैसा कि ऊपर बताया गया है). यह नाम पूरे सिस्टम में यूनीक होना चाहिए; डुप्लीकेट बनाने की कोशिश फ़ेल हो जाएगी.

[in] num_recv_bufs: बफ़र की वह ज़्यादा से ज़्यादा संख्या जिस पर किसी चैनल यह पोर्ट, क्लाइंट के साथ डेटा के लेन-देन की सुविधा के लिए पहले से तय कर सकता है. बफ़र को गिना जाता है अलग-अलग डेटा के लिए अलग-अलग हैं, इसलिए यहां 1 बताने का मतलब 1 होगा भेजें और 1 पाएं बफ़र पहले से ही तय है. आम तौर पर, बफ़र की संख्या यह क्लाइंट और सर्वर. बहुत सिंक्रोनस प्रोटोकॉल के मामले में, संख्या 1 तक हो सकती है (मैसेज भेजें, दूसरा भेजने से पहले जवाब पाएं). हालांकि, यह संख्या अगर ग्राहक एक से ज़्यादा मैसेज भेजने की उम्मीद करता है, तो दिखना चाहिए (उदाहरण के लिए, एक मैसेज प्रस्तावना के तौर पर और दूसरा मैसेज असल निर्देश के तौर पर). कॉन्टेंट बनाने तय किए गए बफ़र सेट हर चैनल के हिसाब से होते हैं, इसलिए दो अलग कनेक्शन (चैनल) होते हैं अलग-अलग बफ़र सेट होंगे.

[in] recv_buf_size: ऊपर बफ़र सेट किया गया है. यह मान है यह प्रोटोकॉल पर निर्भर करता है. साथ ही, यह तय करता है कि ज़्यादा से ज़्यादा मैसेज का साइज़ बदला जा सकता है या नहीं साथी के साथ

[in] flags: यह फ़्लैग का एक ऐसा कॉम्बिनेशन होता है जिससे पोर्ट के अतिरिक्त व्यवहार की जानकारी मिलती है

इस वैल्यू में इन वैल्यू को शामिल किया जाना चाहिए:

IPC_PORT_ALLOW_TA_CONNECT - अन्य सुरक्षित ऐप्लिकेशन से कनेक्ट करने की अनुमति देता है

IPC_PORT_ALLOW_NS_CONNECT - असुरक्षित दुनिया से कनेक्ट करने की अनुमति देता है

[retval]: नेगेटिव या किसी खास तरह की गड़बड़ी वाले पोर्ट पर हैंडल करें नकारात्मक

इसके बाद सर्वर, इनकमिंग कनेक्शन के लिए पोर्ट हैंडल की सूची पोल करता है wait() कॉल का उपयोग किया जा रहा है. कनेक्शन मिलने पर अनुरोध को IPC_HANDLE_POLL_READY बिट में सेट किया गया है uevent_t स्ट्रक्चर का event फ़ील्ड, सर्वर को accept() को कॉल करना चाहिए, ताकि कनेक्ट करने की प्रोसेस पूरी की जा सके और चैनल (इन्होंने प्रतिनिधि बनाया ताकि आने वाले मैसेज के लिए पोल का इस्तेमाल किया जा सके.

स्वीकार करें()

आने वाले कनेक्शन को स्वीकार करता है और चैनल को हैंडल करता है.

long accept(uint32_t handle_id, uuid_t *peer_uuid);

[in] handle_id: उस पोर्ट को दिखाने वाला हैंडल जिससे क्लाइंट कनेक्ट है

[out] peer_uuid: कर्सर को uuid_t के स्ट्रक्चर की ओर ले जाना है कनेक्टिंग क्लाइंट ऐप्लिकेशन का यूयूआईडी भरा गया है. यह अगर कनेक्शन असुरक्षित दुनिया से शुरू हुआ है, तो सभी शून्य पर सेट हो जाएगा

[retval]: ऐसे चैनल को हैंडल करें (अगर यह नेगेटिव न हो), जिस पर सर्वर क्लाइंट को मैसेज भेजें (या गड़बड़ी का कोई कोड डालें)

क्लाइंट API

इस सेक्शन में Client API के तरीके मौजूद हैं.

Client API में तरीके

कनेक्ट()

नाम से तय किए गए पोर्ट से कनेक्शन शुरू करता है.

long connect(const char *path, uint flags);

[in] path: ट्रस्टी ऐप्लिकेशन से पब्लिश किए गए पोर्ट का नाम

[in] flags: अतिरिक्त, वैकल्पिक व्यवहार के बारे में बताता है

[retval]: चैनल को हैंडल करें, जिस पर सर्वर; अगर नेगेटिव है, तो गड़बड़ी है

अगर कोई flags तय नहीं किया गया है (flags पैरामीटर सेट है, तो connect() को कॉल करने से सिंक्रोनस कनेक्शन शुरू हो जाता है किसी खास पोर्ट को पोर्ट के मौजूद न होने पर गड़बड़ी दिखाता है और सर्वर किसी कनेक्शन को स्वीकार करता है.

इस व्यवहार को बदला जा सकता है. इसके लिए, दो वैल्यू, नीचे बताया गया है:

enum {
IPC_CONNECT_WAIT_FOR_PORT = 0x1,
IPC_CONNECT_ASYNC = 0x2,
};

IPC_CONNECT_WAIT_FOR_PORT - connect() को लागू करता है अगर इस्तेमाल किया जाने वाला पोर्ट तुरंत मौजूद नहीं होता है, तो इंतज़ार करने के लिए कॉल करें, मदद मिलती है.

IPC_CONNECT_ASYNC - अगर इसे सेट किया जाता है, तो एसिंक्रोनस कनेक्शन शुरू करता है. अगर आप ऐप्लिकेशन को के लिए पोल करना है वापस किया गया हैंडल (इसके लिए wait() को कॉल करके IPC_HANDLE_POLL_READY ने कनेक्शन पूरा करने का इवेंट दिखाया है शुरू करने से पहले, uevent_t स्ट्रक्चर के इवेंट फ़ील्ड में बिट सेट करें सामान्य कार्रवाई.

मैसेजिंग एपीआई

Messaging API कॉल, मैसेज को पहले से बनाया गया कनेक्शन (चैनल). मैसेजिंग एपीआई कॉल सर्वर और क्लाइंट पर एक ही तरह से काम करता है.

connect() जारी करके, क्लाइंट को चैनल का हैंडल मिलता है कॉल आता है और सर्वर को accept() कॉल से चैनल हैंडल मिलता है, ऊपर बताया गया है.

भरोसेमंद मैसेज का स्ट्रक्चर

जैसा कि नीचे दिखाया गया है, Trusty API से भेजे गए मैसेज में कम से कम के सिमेंटिक्स पर सहमत होने के लिए उसे सर्वर और क्लाइंट पर छोड़ दिया जाता है वास्तविक सामग्री:

/*
 *  IPC message
 */
typedef struct iovec {
        void   *base;
        size_t  len;
} iovec_t;

typedef struct ipc_msg {
        uint     num_iov; /* number of iovs in this message */
        iovec_t  *iov;    /* pointer to iov array */

        uint     num_handles; /* reserved, currently not supported */
        handle_t *handles;    /* reserved, currently not supported */
} ipc_msg_t;

किसी मैसेज में एक या एक से ज़्यादा ऐसे बफ़र हो सकते हैं जो लगातार एक जैसी स्थिति में न हों. इन बफ़र को इस तरह दिखाया जाता है iovec_t स्ट्रक्चर का कलेक्शन. ट्रस्टी स्कैटर-गेदर कर रहा है इन ब्लॉक में पढ़ता और लिखता है iov कलेक्शन का इस्तेमाल करके. बफ़र का वह कॉन्टेंट जिसके बारे में जानकारी दी जा सकती है 'iov' कलेक्शन का इस्तेमाल करता है.

मैसेजिंग एपीआई में तरीके

send_msg()

किसी बताए गए चैनल पर मैसेज भेजता है.

long send_msg(uint32_t handle, ipc_msg_t *msg);

[in] handle: मैसेज भेजने के लिए, चैनल हैंडल करें

[in] msg: मैसेज की जानकारी देने वाले ipc_msg_t structure की ओर ले जाने वाला पॉइंट

[retval]: प्रोसेस पूरी होने के बाद भेजी गई बाइट की कुल संख्या; अगर कोई गड़बड़ी हुई है, तो

अगर क्लाइंट (या सर्वर) चैनल पर मैसेज भेजने की कोशिश कर रहा है और मिलते-जुलते ऐप्लिकेशन के मैसेज की सूची में जगह नहीं है. इसलिए, चैनल 'भेजा गया' ब्लॉक किया गया स्टेटस डालें (किसी सामान्य सिंक्रोनस के तहत ऐसा कभी नहीं होना चाहिए) अनुरोध/जवाब प्रोटोकॉल का इस्तेमाल कर सकते हैं, लेकिन ज़्यादा जटिल मामलों में ऐसा हो सकता है कि ERR_NOT_ENOUGH_BUFFER गड़बड़ी कोड देकर दिखाया जाता है. ऐसे में, कॉल करने वाले व्यक्ति को तब तक इंतज़ार करना होगा, जब तक साथी मैसेज की हैंडलिंग और रिसीयरिंग मैसेज की लाइन में जगह पाने पर, इसमें IPC_HANDLE_POLL_SEND_UNBLOCKED बिट सेट से दिखाया गया है uevent_t स्ट्रक्चर का event फ़ील्ड wait() कॉल पर वापस आया.

get_msg()

इनकमिंग मैसेज की सूची के अगले मैसेज के बारे में मेटा-जानकारी देता है

का इस्तेमाल किया जा सकता है.

long get_msg(uint32_t handle, ipc_msg_info_t *msg_info);

[in] handle: उस चैनल का हैंडल जिस पर नया मैसेज वापस पाना ज़रूरी है

[out] msg_info: मैसेज की जानकारी का स्ट्रक्चर इस तरह बताया गया है:

typedef struct ipc_msg_info {
        size_t    len;  /* total message length */
        uint32_t  id;   /* message id */
} ipc_msg_info_t;

बाकी बचे मैसेज के सेट में, हर मैसेज को एक यूनीक आईडी असाइन किया जाता है, और हर मैसेज में कुल लंबाई भरी गई हो. अगर कॉन्फ़िगर किया गया है और अनुमति दी गई है प्रोटोकॉल के लिए, एक बार में एक किसी खास चैनल पर.

[retval]: सफलता मिलने पर NO_ERROR; अगर कोई गड़बड़ी हुई है, तो

Read_msg()

इससे शुरू होने वाले, तय किए गए आईडी वाले मैसेज के कॉन्टेंट को पढ़ता है बताया गया ऑफ़सेट.

long read_msg(uint32_t handle, uint32_t msg_id, uint32_t offset, ipc_msg_t
*msg);

[in] handle: उस चैनल का हैंडल मैनेज करें जिससे मैसेज पढ़ना है

[in] msg_id: पढ़े जाने वाले मैसेज का आईडी

[in] offset: उस मैसेज में ऑफ़सेट करें जिससे पढ़ना शुरू करना है

[out] msg: ipc_msg_t के स्ट्रक्चर की जानकारी देने वाला पॉइंटर बफ़र का एक सेट जिसमें आने वाले मैसेज को सेव किया जाता है डेटा

[retval]: msg बफ़र में सेव की गई बाइट की कुल संख्या कामयाबी; अगर कोई गड़बड़ी हुई है, तो

read_msg तरीके को एक से ज़्यादा बार कॉल किया जा सकता है. ऐसा यहां से शुरू होता है कोई अलग (ज़रूरी नहीं है कि क्रम में).

enter_msg()

किसी खास आईडी वाला मैसेज हटाता है.

long put_msg(uint32_t handle, uint32_t msg_id);

[in] handle: उस चैनल का हैंडल मैनेज करना जिस पर मैसेज मिला है

[in] msg_id: मैसेज का आईडी बंद किया जा रहा है

[retval]: सफलता मिलने पर NO_ERROR; अगर कोई गड़बड़ी हुई है, तो

किसी संदेश के बंद हो जाने के बाद और आपने जो बफ़र किया था उसे खाली कर दिया गया है.

फ़ाइल विवरण API

फ़ाइल Descriptor API में read(), write(), और ioctl() कॉल. ये सभी कॉल पहले से तय (स्टैटिक) फ़ाइल के सेट पर चल सकते हैं डिस्क्रिप्टर को पारंपरिक रूप से छोटी संख्याओं से दिखाया जाता है. मौजूदा लागू करने पर, फ़ाइल डिस्क्रिप्टर स्पेस आईपीसी हैंडल से अलग होता है स्पेस. ट्रस्टी में फ़ाइल डिस्क्रिप्टर एपीआई है जो पारंपरिक फ़ाइल डिस्क्रिप्टर-आधारित एपीआई से मिलती-जुलती है.

डिफ़ॉल्ट रूप से, पहले से तय तीन (स्टैंडर्ड और लोकप्रिय) फ़ाइल डिस्क्रिप्टर मौजूद होते हैं:

• 0 - स्टैंडर्ड इनपुट. स्टैंडर्ड इनपुट fd को डिफ़ॉल्ट रूप से लागू करना नहीं है (क्योंकि भरोसेमंद ऐप्लिकेशन के लिए कंसोल) इसलिए उपलब्ध है, ताकि fd पर ioctl() को पढ़ा, लिखा या शुरू किया जा सके 0 को ERR_NOT_SUPPORTED गड़बड़ी दिखानी चाहिए.
• 1 - स्टैंडर्ड आउटपुट. स्टैंडर्ड आउटपुट पर लिखे गए डेटा को रूट किया जा सकता है (यह LK डीबग लेवल पर) और/या असुरक्षित मेमोरी लॉग में उपलब्ध वाला हिस्सा, प्लैटफ़ॉर्म और कॉन्फ़िगरेशन के आधार पर तय होता है. गैर-ज़रूरी डीबग लॉग और मैसेज स्टैंडर्ड आउटपुट में जाने चाहिए. read() और ioctl() तरीके काम नहीं कर रहे हैं और उन्हें ERR_NOT_SUPPORTED गड़बड़ी देनी चाहिए.
• 2 - स्टैंडर्ड गड़बड़ी. स्टैंडर्ड गड़बड़ी पर लिखे गए डेटा को UART पर रूट किया जाना चाहिए या मेमोरी लॉग का इस्तेमाल असुरक्षित पेज पर किया जा सकता है. यह सुरक्षा प्लैटफ़ॉर्म और कॉन्फ़िगरेशन. यह सुझाव दिया जाता है कि स्टैंडर्ड पेज पर, सिर्फ़ ज़रूरी मैसेज लिखें गड़बड़ी दिखेगी, क्योंकि इस स्ट्रीम को थ्रॉटल नहीं किया जाएगा. read() और ioctl() तरीके काम नहीं कर रहे हैं और इनसे ERR_NOT_SUPPORTED गड़बड़ी मिलेगी.

हालांकि, फ़ाइल डिस्क्रिप्टर के इस सेट को लागू करने के लिए बढ़ाया जा सकता है fds (प्लैटफ़ॉर्म के हिसाब से एक्सटेंशन लागू करने के लिए), फ़ाइल डिस्क्रिप्टर की ज़रूरतों को बढ़ाएं इस्तेमाल करने में सावधानी बरतनी चाहिए. फ़ाइल डिस्क्रिप्टर को एक्सटेंडेड करने की वजह से, हैं और आम तौर पर इसका सुझाव नहीं दिया जाता.

File Descriptor API में तरीके

पढ़ें()

किसी तय फ़ाइल डिस्क्रिप्टर से, count बाइट तक डेटा पढ़ने की कोशिश करता है.

long read(uint32_t fd, void *buf, uint32_t count);

[in] fd: फ़ाइल डिस्क्रिप्टर जिससे पढ़ना है

[out] buf: उस बफ़र की ओर ले जाने वाला पॉइंट जिसमें डेटा सेव करना है

[in] count: पढ़ने के लिए, बाइट की ज़्यादा से ज़्यादा संख्या

[retval]: पढ़े गए बाइट की संख्या दी गई; अगर कोई गड़बड़ी हुई है, तो

लिखें()

बताए गए फ़ाइल डिस्क्रिप्टर में ज़्यादा से ज़्यादा count बाइट डेटा लिखता है.

long write(uint32_t fd, void *buf, uint32_t count);

[in] fd: फ़ाइल डिस्क्रिप्टर जिस पर लिखना है

[out] buf: लिखने के लिए डेटा की ओर पॉइंटर

[in] count: लिखने के लिए, बाइट की ज़्यादा से ज़्यादा संख्या

[retval]: लिखे गए बाइट की संख्या; अगर कोई गड़बड़ी हुई है, तो

आईओसीटीएल()

दिए गए फ़ाइल डिस्क्रिप्टर के लिए, दिए गए ioctl कमांड को शुरू करता है.

long ioctl(uint32_t fd, uint32_t cmd, void *args);

[in] fd: फ़ाइल डिस्क्रिप्टर जिस पर ioctl() को शुरू करना है

[in] cmd: ioctl निर्देश

[in/out] args: ioctl() आर्ग्युमेंट की ओर ले जाने वाला पॉइंट

मिसलेनियस एपीआई

मिसलेनियस एपीआई में तरीके

गेटटाइम()

यह फ़ंक्शन मौजूदा सिस्टम टाइम (नैनोसेकंड में) दिखाता है.

long gettime(uint32_t clock_id, uint32_t flags, int64_t *time);

[in] clock_id: प्लैटफ़ॉर्म पर निर्भर करता है; डिफ़ॉल्ट के लिए शून्य पास करें

[in] flags: रिज़र्व किया गया, यह शून्य होना चाहिए

[out] time: मौजूदा समय को सेव करने के लिए, int64_t वैल्यू का पॉइंटर

[retval]: सफलता मिलने पर NO_ERROR; अगर कोई गड़बड़ी हुई है, तो

naosleep()

एक खास समयावधि के लिए, कॉल करने वाले ऐप्लिकेशन की प्रोसेस निलंबित हो जाती है और उस अवधि के बाद उसे फिर से शुरू कर सकता है.

long nanosleep(uint32_t clock_id, uint32_t flags, uint64_t sleep_time)

[in] clock_id: रिज़र्व किया गया, यह शून्य होना चाहिए

[in] flags: रिज़र्व किया गया, यह शून्य होना चाहिए

[in] sleep_time: नींद का समय नैनोसेकंड में

[retval]: सफलता मिलने पर NO_ERROR; अगर कोई गड़बड़ी हुई है, तो

भरोसेमंद ऐप्लिकेशन सर्वर का उदाहरण

नीचे दिया गया ऐप्लिकेशन का सैंपल, ऊपर दिए गए एपीआई के इस्तेमाल को दिखाता है. सैंपल एक "इको" बनाता है ऐसी सेवा जो आने वाले कई कनेक्शन को मैनेज करती है और क्लाइंट से मिलने वाले सभी मैसेज कॉलर को वापस दिखते हैं से सुरक्षित करना है.

#include <uapi/err.h>
#include <stdbool.h>
#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <trusty_ipc.h>
#define LOG_TAG "echo_srv"
#define TLOGE(fmt, ...) \
    fprintf(stderr, "%s: %d: " fmt, LOG_TAG, __LINE__, ##__VA_ARGS__)

# define MAX_ECHO_MSG_SIZE 64

static
const char * srv_name = "com.android.echo.srv.echo";

static uint8_t msg_buf[MAX_ECHO_MSG_SIZE];

/*
 *  Message handler
 */
static int handle_msg(handle_t chan) {
  int rc;
  struct iovec iov;
  ipc_msg_t msg;
  ipc_msg_info_t msg_inf;

  iov.iov_base = msg_buf;
  iov.iov_len = sizeof(msg_buf);

  msg.num_iov = 1;
  msg.iov = &iov;
  msg.num_handles = 0;
  msg.handles = NULL;

  /* get message info */
  rc = get_msg(chan, &msg_inf);
  if (rc == ERR_NO_MSG)
    return NO_ERROR; /* no new messages */

  if (rc != NO_ERROR) {
    TLOGE("failed (%d) to get_msg for chan (%d)\n",
      rc, chan);
    return rc;
  }

  /* read msg content */
  rc = read_msg(chan, msg_inf.id, 0, &msg);
  if (rc < 0) {
    TLOGE("failed (%d) to read_msg for chan (%d)\n",
      rc, chan);
    return rc;
  }

  /* update number of bytes received */
  iov.iov_len = (size_t) rc;

  /* send message back to the caller */
  rc = send_msg(chan, &msg);
  if (rc < 0) {
    TLOGE("failed (%d) to send_msg for chan (%d)\n",
      rc, chan);
    return rc;
  }

  /* retire message */
  rc = put_msg(chan, msg_inf.id);
  if (rc != NO_ERROR) {
    TLOGE("failed (%d) to put_msg for chan (%d)\n",
      rc, chan);
    return rc;
  }

  return NO_ERROR;
}

/*
 *  Channel event handler
 */
static void handle_channel_event(const uevent_t * ev) {
  int rc;

  if (ev->event & IPC_HANDLE_POLL_MSG) {
    rc = handle_msg(ev->handle);
    if (rc != NO_ERROR) {
      /* report an error and close channel */
      TLOGE("failed (%d) to handle event on channel %d\n",
        rc, ev->handle);
      close(ev->handle);
    }
    return;
  }
  if (ev->event & IPC_HANDLE_POLL_HUP) {
    /* closed by peer. */
    close(ev->handle);
    return;
  }
}

/*
 *  Port event handler
 */
static void handle_port_event(const uevent_t * ev) {
  uuid_t peer_uuid;

  if ((ev->event & IPC_HANDLE_POLL_ERROR) ||
    (ev->event & IPC_HANDLE_POLL_HUP) ||
    (ev->event & IPC_HANDLE_POLL_MSG) ||
    (ev->event & IPC_HANDLE_POLL_SEND_UNBLOCKED)) {
    /* should never happen with port handles */
    TLOGE("error event (0x%x) for port (%d)\n",
      ev->event, ev->handle);
    abort();
  }
  if (ev->event & IPC_HANDLE_POLL_READY) {
    /* incoming connection: accept it */
    int rc = accept(ev->handle, &peer_uuid);
    if (rc < 0) {
      TLOGE("failed (%d) to accept on port %d\n",
        rc, ev->handle);
      return;
    }
    handle_t chan = rc;
    while (true){
      struct uevent cev;

      rc = wait(chan, &cev, INFINITE_TIME);
      if (rc < 0) {
        TLOGE("wait returned (%d)\n", rc);
        abort();
      }
      handle_channel_event(&cev);
      if (cev.event & IPC_HANDLE_POLL_HUP) {
        return;
      }
    }
  }
}


/*
 *  Main application entry point
 */
int main(void) {
  int rc;
  handle_t port;

  /* Initialize service */
  rc = port_create(srv_name, 1, MAX_ECHO_MSG_SIZE,
    IPC_PORT_ALLOW_NS_CONNECT |
    IPC_PORT_ALLOW_TA_CONNECT);
  if (rc < 0) {
    TLOGE("Failed (%d) to create port %s\n",
      rc, srv_name);
    abort();
  }
  port = (handle_t) rc;

  /* enter main event loop */
  while (true) {
    uevent_t ev;

    ev.handle = INVALID_IPC_HANDLE;
    ev.event = 0;
    ev.cookie = NULL;

    /* wait forever */
    rc = wait(port, &ev, INFINITE_TIME);
    if (rc == NO_ERROR) {
      /* got an event */
      handle_port_event(&ev);
    } else {
      TLOGE("wait returned (%d)\n", rc);
      abort();
    }
  }
  return 0;
}

run_end_to_end_msg_test() तरीका, एसिंक्रोनस तरीके से 10,000 मैसेज भेजता है "ईको" वाली आवाज़ में सेवा और हैंडल जवाब.

static int run_echo_test(void)
{
  int rc;
  handle_t chan;
  uevent_t uevt;
  uint8_t tx_buf[64];
  uint8_t rx_buf[64];
  ipc_msg_info_t inf;
  ipc_msg_t   tx_msg;
  iovec_t     tx_iov;
  ipc_msg_t   rx_msg;
  iovec_t     rx_iov;

  /* prepare tx message buffer */
  tx_iov.base = tx_buf;
  tx_iov.len  = sizeof(tx_buf);
  tx_msg.num_iov = 1;
  tx_msg.iov     = &tx_iov;
  tx_msg.num_handles = 0;
  tx_msg.handles = NULL;

  memset (tx_buf, 0x55, sizeof(tx_buf));

  /* prepare rx message buffer */
  rx_iov.base = rx_buf;
  rx_iov.len  = sizeof(rx_buf);
  rx_msg.num_iov = 1;
  rx_msg.iov     = &rx_iov;
  rx_msg.num_handles = 0;
  rx_msg.handles = NULL;

  /* open connection to echo service */
  rc = sync_connect(srv_name, 1000);
  if(rc < 0)
    return rc;

  /* got channel */
  chan = (handle_t)rc;

  /* send/receive 10000 messages asynchronously. */
  uint tx_cnt = 10000;
  uint rx_cnt = 10000;

  while (tx_cnt || rx_cnt) {
    /* send messages until all buffers are full */
while (tx_cnt) {
    rc = send_msg(chan, &tx_msg);
      if (rc == ERR_NOT_ENOUGH_BUFFER)
      break;  /* no more space */
    if (rc != 64) {
      if (rc > 0) {
        /* incomplete send */
        rc = ERR_NOT_VALID;
}
      goto abort_test;
}
    tx_cnt--;
  }

  /* wait for reply msg or room */
  rc = wait(chan, &uevt, 1000);
  if (rc != NO_ERROR)
    goto abort_test;

  /* drain all messages */
  while (rx_cnt) {
    /* get a reply */
      rc = get_msg(chan, &inf);
    if (rc == ERR_NO_MSG)
        break;  /* no more messages  */
  if (rc != NO_ERROR)
goto abort_test;

  /* read reply data */
    rc = read_msg(chan, inf.id, 0, &rx_msg);
  if (rc != 64) {
    /* unexpected reply length */
    rc = ERR_NOT_VALID;
    goto abort_test;
}

  /* discard reply */
  rc = put_msg(chan, inf.id);
  if (rc != NO_ERROR)
    goto abort_test;
  rx_cnt--;
  }
}

abort_test:
  close(chan);
  return rc;
}

दुनिया भर के असुरक्षित एपीआई और ऐप्लिकेशन

ट्रस्टी सेवाओं का एक सेट, जिसे सुरक्षित साइड से पब्लिश किया जाता है और जिस पर IPC_PORT_ALLOW_NS_CONNECT एट्रिब्यूट को कर्नेल से ऐक्सेस किया जा सकता है और उपयोगकर्ता स्पेस प्रोग्राम का हिस्सा असुरक्षित होता है.

गैर-सुरक्षित साइड पर एक्ज़ीक्यूशन एनवायरमेंट (कर्नेल और यूज़र स्पेस) यह है ये सुरक्षित-साइड पर एक्ज़ीक्यूशन एनवायरमेंट से बहुत अलग होते हैं. इसलिए, दोनों एनवायरमेंट के लिए एक लाइब्रेरी के बजाय, दो के अलग-अलग सेट का इस्तेमाल कर रहे हैं. कर्नेल में, Client API, Trusty-ipc कर्नेल ड्राइवर में है और एक वर्ण डिवाइस नोड रजिस्टर करता है, जिसका इस्तेमाल किया जा सकता है सुरक्षित तरीके से चल रही सेवाओं के साथ संपर्क करने के लिए, उपयोगकर्ता स्पेस प्रोसेस की ओर.

उपयोगकर्ता स्पेस ट्रस्टी आईपीसी क्लाइंट एपीआई

यूज़र स्पेस Trusty IPC Client API लाइब्रेरी एक थिन लेयर होती है. यह स्प्रेडशीट के सबसे ऊपर डिवाइस नोड fd.

यूज़र स्पेस प्रोग्राम की मदद से, कम्यूनिकेशन सेशन शुरू किया जाता है tipc_connect() पर कॉल करके, किसी तय भरोसेमंद सेवा से कनेक्शन शुरू करना. अंदरूनी तौर पर, tipc_connect() कॉल से तय किया गया डिवाइस नोड खुलता है एक फ़ाइल डिस्क्रिप्टर लेता है और TIPC_IOC_CONNECT ioctl() को शुरू करता है एक ऐसा कॉल जिसमें argp पैरामीटर शामिल हो, जो उस स्ट्रिंग पर ले जाता हो जिसमें सेवा का नाम जिससे कनेक्ट करना है.

#define TIPC_IOC_MAGIC  'r'
#define TIPC_IOC_CONNECT  _IOW(TIPC_IOC_MAGIC, 0x80, char *)

नतीजे के तौर पर मिलने वाले फ़ाइल डिस्क्रिप्टर का इस्तेमाल सिर्फ़ सेवा से संपर्क करने के लिए किया जा सकता है जिसके लिए इसे बनाया गया था. फ़ाइल डिस्क्रिप्टर कनेक्शन की ज़रूरत न होने पर, tipc_close() पर कॉल करें.

tipc_connect() कॉल से मिला फ़ाइल डिस्क्रिप्टर सामान्य वर्ण डिवाइस नोड की तरह काम करता है; फ़ाइल डिस्क्रिप्टर:

• ज़रूरत पड़ने पर, ब्लॉक नहीं करने वाले मोड पर स्विच किया जा सकता है
• स्टैंडर्ड write() का इस्तेमाल करके लिखा जा सकता है दूसरी तरफ़ मैसेज भेजने के लिए कॉल करो
• पोल किया जा सकता है (poll() कॉल या select() कॉल का इस्तेमाल करके) नियमित फ़ाइल डिस्क्रिप्टर के रूप में आने वाले मैसेज की उपलब्धता के लिए
• आने वाले मैसेज वापस पाने के लिए, इसे पढ़ा जा सकता है

एक कॉलर, राइट कॉल करके ट्रस्टी सेवा को मैसेज भेजता है fd बताया गया है. पूरा डेटा ऊपर दिए गए write() कॉल में भेजा गया को भरोसेमंद आईपीसी ड्राइवर की ओर से मैसेज में बदल दिया जाता है. मैसेज है को सुरक्षित रखा जाता है, जहां डेटा को आईपीसी सबसिस्टम मैनेज करता है ट्रस्टी कर्नेल को सही डेस्टिनेशन पर भेजा और किसी ऐप्लिकेशन पर डिलीवर कर दिया किसी खास चैनल पर IPC_HANDLE_POLL_MSG इवेंट के तौर पर इवेंट लूप हैंडल. विशेष रूप से, सेवा-विशिष्ट प्रोटोकॉल, ट्रस्टी सेवा एक या ज़्यादा उत्तर भेज सकती है जो गैर-सुरक्षित पक्ष में वापस भेज दिए जाते हैं और उपयोगकर्ता को वापस लाने के लिए सही चैनल फ़ाइल डिस्क्रिप्टर मैसेज क्यू स्पेस ऐप्लिकेशन read() कॉल.

Tipc_connect()

तय किया गया tipc डिवाइस नोड खोलता है और शुरू करता है किसी तय भरोसेमंद सेवा से कनेक्ट करना है.

int tipc_connect(const char *dev_name, const char *srv_name);

[in] dev_name: ट्रस्टी आईपीसी डिवाइस नोड को खोलने के लिए पाथ

[in] srv_name: पब्लिश की गई उस ट्रस्टी सेवा का नाम जिससे कनेक्ट करना है

[retval]: सही होने के बारे में मान्य फ़ाइल डिस्क्रिप्टर, नहीं तो -1.

Tipc_close()

फ़ाइल डिस्क्रिप्टर से तय की गई ट्रस्टी सेवा से कनेक्शन बंद करता है.

int tipc_close(int fd);

[in] fd: फ़ाइल डिस्क्रिप्टर को पहले इन्होंने खोला था tipc_connect() कॉल

Kernel Trusty IPC क्लाइंट एपीआई

kernel Trusty IPC Client API, कर्नेल ड्राइवर के लिए उपलब्ध है. किसी उपयोगकर्ता इस एपीआई के सबसे ऊपर स्पेस Trusty IPC API लागू किया गया है.

आम तौर पर, इस एपीआई को इस्तेमाल करने के लिए कॉलर का इस्तेमाल किया जाता है tipc_create_channel() का इस्तेमाल करके, एक struct tipc_chan ऑब्जेक्ट फ़ंक्शन का इस्तेमाल किया जा सकता है और फिर tipc_chan_connect() कॉल का इस्तेमाल करके का इस्तेमाल, सुरक्षित प्लैटफ़ॉर्म पर की जाने वाली की ओर. रिमोट साइड का कनेक्शन इनके ज़रिए खत्म किया जा सकता है tipc_chan_shutdown() को कॉल किया जा रहा है संसाधनों का स्टोरेज खाली करने के लिए, tipc_chan_destroy().

सूचना मिलने पर (handle_event() कॉलबैक से) कि कनेक्शन सफलतापूर्वक बन गया है, तो कॉलर निम्न:

• tipc_chan_get_txbuf_timeout() कॉल का इस्तेमाल करके मैसेज बफ़र पाएं
• मैसेज लिखता है और
• tipc_chan_queue_msg() का इस्तेमाल करके मैसेज को सूची में जोड़ देता है किसी भरोसेमंद सेवा को डिलीवर करने का तरीका (सुरक्षित पक्ष में), जिसके लिए चैनल कनेक्ट है

सूची में शामिल होने के बाद, कॉल करने वाले (कॉलर) को मैसेज बफ़र याद नहीं रहेगा क्योंकि मैसेज बफ़र आखिरकार फ़्री बफ़र पूल में वापस आ जाता है रिमोट की मदद से प्रोसेस किया जा रहा है (बाद में, दूसरे मैसेज के लिए इस्तेमाल किया जा सकता है). किसी उपयोगकर्ता tipc_chan_put_txbuf() को कॉल करने की ज़रूरत सिर्फ़ तब होगी, जब यह ऐसा न कर पाए ऐसा बफ़र हो सकता है या अब इसकी ज़रूरत नहीं है.

एपीआई उपयोगकर्ता को रिमोट साइड से मैसेज मिलते हैं. इसके लिए, वह handle_msg() सूचना कॉलबैक (जिसे इसमें कॉल किया जाता है के संदर्भ में हो सकती है)rx rx बफ़र के लिए पॉइंटर देता है जिसमें आने वाले मैसेज को हैंडल करना है.

handle_msg() कॉलबैक ज़रूरी है लागू करने पर, मान्य struct tipc_msg_buf पर पॉइंटर मिल जाएगा. अगर इसे स्थानीय तौर पर हैंडल किया जाता है, तो यह इनकमिंग मैसेज बफ़र के जैसा हो सकता है और अब इसकी ज़रूरत नहीं है. इसके अलावा, यह एक नया बफ़र हो सकता है, जिसे अगर इनकमिंग बफ़र सूची में है, तो tipc_chan_get_rxbuf() कॉल ताकि आगे की प्रोसेस पूरी की जा सके. डिटैच किया गया rx बफ़र को ट्रैक करना ज़रूरी है साथ ही, जब उपयोगकर्ता ने tipc_chan_put_rxbuf() कॉल का इस्तेमाल करके सदस्यता छोड़ दी, तो अब इसकी ज़रूरत नहीं है.

Kernel Trusty IPC Client API में तरीके

Tipc_create_channel()

किसी खास आईपीसी चैनल का इंस्टेंस बनाता और कॉन्फ़िगर करता है भरोसेमंद-ipc डिवाइस.

struct tipc_chan *tipc_create_channel(struct device *dev,
                          const struct tipc_chan_ops *ops,
                              void *cb_arg);

[in] dev: उस भरोसेमंद आईपीसी की ओर इशारा करता है जिसके लिए डिवाइस चैनल बना दिया गया है

[in] ops: struct tipc_chan_ops की ओर पॉइंटर, कॉलर के हिसाब से कॉलबैक भरे गए

[in] cb_arg: पास किए जाने वाले डेटा के लिए पॉइंटर tipc_chan_ops कॉलबैक के लिए

[retval]: यह वैल्यू के नए बनाए गए इंस्टेंस की ओर इशारा करता है सफलता मिलने पर struct tipc_chan, अन्य मामलों में ERR_PTR(err)

आम तौर पर, कॉल करने वाले (कॉलर) को दो कॉलबैक उपलब्ध कराने चाहिए, जिन्हें एसिंक्रोनस रूप से शुरू किया जाता है जब संबंधित गतिविधि हो रही हो.

void (*handle_event)(void *cb_arg, int event)इवेंट शुरू किया गया का इस्तेमाल कर सकते हैं.

[in] cb_arg: tipc_create_channel() कॉल

[in] event: ऐसा इवेंट जो इनमें से कोई एक वैल्यू हो सकता है:

• TIPC_CHANNEL_CONNECTED - कनेक्शन सफल होने का संकेत देता है रिमोट साइड की तरफ़
• TIPC_CHANNEL_DISCONNECTED - यह बताता है कि रिमोट साइड ने नए कनेक्शन का अनुरोध या अनुरोध किया गया पहले से कनेक्ट किए गए चैनल के लिए डिस्कनेक्शन
• TIPC_CHANNEL_SHUTDOWN - इससे पता चलता है कि रिमोट साइड बंद हो रही है. सभी कनेक्शन को हमेशा के लिए बंद किया जा रहा है

struct tipc_msg_buf *(*handle_msg)(void *cb_arg, struct tipc_msg_buf *mb) कॉलबैक का अनुरोध किया जाता है, ताकि यह सूचना दी जा सके कि नया मैसेज जनरेट हो गया है किसी खास चैनल पर मिले:

• [in] cb_arg: tipc_create_channel() कॉल
• [in] mb: struct tipc_msg_buf की ओर पॉइंटर किसी इनकमिंग मैसेज के बारे में बताना
• [retval]: कॉलबैक लागू करने से struct tipc_msg_buf, जो एक ही पॉइंटर मिल सकता है इस रूप में mb पैरामीटर, अगर मैसेज को स्थानीय तौर पर हैंडल किया जाता है और नहीं अब ज़रूरी नहीं है (या यह tipc_chan_get_rxbuf() कॉल से मिला नया बफ़र हो सकता है)

Tipc_chan_connect()

तय की गई Trusty IPC सेवा से कनेक्शन शुरू करता है.

int tipc_chan_connect(struct tipc_chan *chan, const char *port);

[in] chan: चैनल की ओर से दिखाया गया पॉइंटर tipc_create_chan() कॉल

[in] port: उस स्ट्रिंग की ओर पॉइंटर सेवा का नाम जिससे कनेक्ट करना है

[retval]: सफलता पर 0, नहीं तो एक नेगेटिव गड़बड़ी

जब कोई व्यक्ति handle_event कॉलबैक.

Tipc_chan_shutdown()

पहले शुरू की गई ट्रस्टी आईपीसी सेवा से कनेक्शन खत्म करता है tipc_chan_connect() कॉल के ज़रिए.

int tipc_chan_shutdown(struct tipc_chan *chan);

[in] chan: चैनल के लिए पॉइंटर tipc_create_chan() कॉल

Tipc_chan_destroy()

किसी चुनिंदा भरोसेमंद आईपीसी चैनल को बंद करता है.

void tipc_chan_destroy(struct tipc_chan *chan);

[in] chan: चैनल की ओर से दिखाया गया पॉइंटर tipc_create_chan() कॉल

Tipc_chan_get_txbuf_timeout()

इससे मैसेज बफ़र का पता चलता है, जिसका इस्तेमाल किसी बताई गई जगह पर डेटा भेजने के लिए किया जा सकता है चैनल. बफ़र तुरंत उपलब्ध न होने पर, कॉल करने वाले (कॉलर) को ब्लॉक किया जा सकता है का उपयोग करें.

struct tipc_msg_buf *
tipc_chan_get_txbuf_timeout(struct tipc_chan *chan, long timeout);

[in] chan: मैसेज को सूची में जोड़ने के लिए, उस चैनल की ओर कर्सर ले जाएं

[in] chan: ज़्यादा से ज़्यादा इतनी देर तक इंतज़ार किया जा सकेगा tx बफ़र हो जाएगा

[retval]: सही नतीजे मिलने पर एक मान्य मैसेज बफ़र, गड़बड़ी होने पर ERR_PTR(err)

Tipc_chan_queue_msg()

तय किए गए पते पर भेजे जाने वाले मैसेज की सूची बनाता है भरोसेमंद आईपीसी चैनल.

int tipc_chan_queue_msg(struct tipc_chan *chan, struct tipc_msg_buf *mb);

[in] chan: मैसेज को सूची में जोड़ने के लिए, उस चैनल की ओर कर्सर ले जाएं

[in] mb: मैसेज की सूची में ले जाने के लिए पॉइंटर (tipc_chan_get_txbuf_timeout() कॉल से मिला)

[retval]: सफलता पर 0, नहीं तो एक नेगेटिव गड़बड़ी

Tipsc_chan_put_txbuf()

चुने गए Tx मैसेज बफ़र को रिलीज़ करता है यह मैसेज, पहले tipc_chan_get_txbuf_timeout() कॉल पर आया था.

void tipc_chan_put_txbuf(struct tipc_chan *chan,
                         struct tipc_msg_buf *mb);

[in] chan: इससे, उस चैनल की ओर कर्सर ले जाने का कर्सर चलता है जिस पर कर्सर ले जाते हैं यह मैसेज बफ़र इससे जुड़ा है

[in] mb: रिलीज़ के लिए, मैसेज बफ़र का पॉइंटर

[retval]: कोई नहीं

Tipc_chan_get_rxbuf()

नया मैसेज बफ़र पाएं जिसका इस्तेमाल इस ईमेल पते पर मैसेज पाने के लिए किया जा सके चुना गया चैनल.

struct tipc_msg_buf *tipc_chan_get_rxbuf(struct tipc_chan *chan);

[in] chan: यह मैसेज बफ़र से जुड़े चैनल की ओर इशारा करता है

[retval]: पूरा होने पर एक मान्य मैसेज बफ़र, गड़बड़ी होने पर ERR_PTR(err)

Tipc_chan_put_rxbuf()

तय किए गए मैसेज बफ़र को रिलीज़ करता है, जो पहले tipc_chan_get_rxbuf() कॉल.

void tipc_chan_put_rxbuf(struct tipc_chan *chan,
                         struct tipc_msg_buf *mb);

[in] chan: यह मैसेज बफ़र से जुड़े चैनल की ओर इशारा करता है

[in] mb: रिलीज़ के लिए, मैसेज बफ़र का पॉइंटर

[retval]: कोई नहीं