Lập trình Driver

Hình 1-1 là một sơ đồ chức năng rất viết tắt của hệ điều hành Windows XP, trong đó nhấn mạnh các tính năng quan trọng cho những người viết trình điều khiển thiết bị. Mỗi nền tảng Windows XP chạy hỗ trợ hai chế độ thực hiện. Phần mềm thực hiện hoặc trong chế độ người dùng hoặc trong chế độ hạt nhân. Một chương trình người sử dụng, chế độ mà muốn, nói, đọc một số dữ liệu từ một thiết bị sẽ gọi một giao diện lập trình ứng dụng (API) như ReadFile. Một module hệ thống phụ như Kernel32.dll thực hiện API này bằng cách gọi một hàm API bản địa như NtReadFile. Hãy tham khảo để thanh bên để biết thêm thông tin về các API bản địa. Chúng ta thường nói rằng NtReadFile là một phần của một thành phần hệ thống được gọi là I / O Manager. Nhiệm kỳ I / O Manager có lẽ là một chút sai lệch bởi vì không có bất kỳ thành phần thực thi duy nhất với tên đó. Chúng tôi cần một tên để sử dụng khi thảo luận về các "đám mây" của các dịch vụ hệ thống điều hành xung quanh điều khiển của chúng tôi, mặc dù, và tên này là một trong chúng ta thường chọn.

docx2 trang | Chia sẻ: tlsuongmuoi | Lượt xem: 2390 | Lượt tải: 0download
Bạn đang xem nội dung tài liệu Lập trình Driver, để tải tài liệu về máy bạn click vào nút DOWNLOAD ở trên
Hình 1-1 là một sơ đồ chức năng rất viết tắt của hệ điều hành Windows XP, trong đó nhấn mạnh các tính năng quan trọng cho những người viết trình điều khiển thiết bị. Mỗi nền tảng Windows XP chạy hỗ trợ hai chế độ thực hiện. Phần mềm thực hiện hoặc trong chế độ người dùng hoặc trong chế độ hạt nhân. Một chương trình người sử dụng, chế độ mà muốn, nói, đọc một số dữ liệu từ một thiết bị sẽ gọi một giao diện lập trình ứng dụng (API) như ReadFile. Một module hệ thống phụ như Kernel32.dll thực hiện API này bằng cách gọi một hàm API bản địa như NtReadFile. Hãy tham khảo để thanh bên để biết thêm thông tin về các API bản địa. Chúng ta thường nói rằng NtReadFile là một phần của một thành phần hệ thống được gọi là I / O Manager. Nhiệm kỳ I / O Manager có lẽ là một chút sai lệch bởi vì không có bất kỳ thành phần thực thi duy nhất với tên đó. Chúng tôi cần một tên để sử dụng khi thảo luận về các "đám mây" của các dịch vụ hệ thống điều hành xung quanh điều khiển của chúng tôi, mặc dù, và tên này là một trong chúng ta thường chọn. Thói quen phục vụ một mục đích tương tự như NtReadFile. Họ hoạt động ở chế độ hạt nhân để phục vụ yêu cầu của một ứng dụng để tương tác với một thiết bị một cách nào đó. Tất cả họ đều xác nhận các thông số của họ, qua đó đảm bảo rằng họ không vô tình cho phép một hành vi vi phạm an ninh bằng cách thực hiện một hoạt động, hoặc truy cập vào một số dữ liệu, rằng chương trình chế độ người dùng sẽ không thể thực hiện hoặc truy cập của chính nó. Sau đó, họ tạo ra một cấu trúc dữ liệu gọi là một I / O yêu cầu gói (IRP) mà họ vượt qua một điểm vào trong một số trình điều khiển thiết bị. Trong trường hợp của một ReadFile gọi, NtReadFile sẽ tạo ra một IRP với IRP_MJ_READ mã chức năng chính (một hằng số trong một DDK [Kit phát triển trình điều khiển phần đầu tập tin). Chi tiết xử lý tại thời điểm này có thể khác nhau, nhưng một kịch bản có khả năng là một thói quen như NtReadFile để trả lại cho người gọi chế độ với người dùng với một dấu hiệu cho thấy các hoạt động được mô tả bởi IRP đã không hoàn thành được nêu ra. Chương trình chế độ người dùng có thể tiếp tục kinh doanh của mình và sau đó chờ đợi cho hoạt động để kết thúc, hoặc nó có thể chờ đợi ngay lập tức. Dù bằng cách nào, trình điều khiển thiết bị tiến hành một cách độc lập của ứng dụng để phục vụ yêu cầu. API Native NtReadFile là một phần của API bản địa gọi là Windows XP. Lý do có một API có nguồn gốc lịch sử. Hệ điều hành Windows NT có một số hệ thống con để thực hiện ngữ nghĩa của một số hệ điều hành mới và hiện có. Có một hệ thống con OS / 2, một hệ thống con POSIX, và một hệ thống con Win32. Các hệ thống con đã được thực hiện bằng cách làm cho người sử dụng chế độ cuộc gọi đến các API bản địa, được thực hiện trong chế độ hạt nhân. Một DLL người sử dụng chế độ đặt tên (chứ không phải dư thừa, tôi đã luôn luôn nghĩ rằng) ntdll.dll thực hiện các API bản địa cho người gọi Win32. Mỗi mục trong DLL này là một wrapper mỏng quanh một cuộc gọi đến một chức năng hạt nhân-chế độ mà trên thực tế thực hiện chức năng. Các cuộc gọi sử dụng một nền tảng phụ thuộc vào giao diện dịch vụ hệ thống để chuyển giao kiểm soát trên biên giới user-mode/kernel-mode. Trên các bộ vi xử lý Intel mới hơn, giao diện dịch vụ hệ thống này sử dụng hướng dẫn SYSENTER. Trên các bộ xử lý Intel cũ hơn, giao diện sử dụng hướng dẫn INT với 0x2E mã chức năng. Trên bộ xử lý khác, vẫn còn các cơ chế khác được tuyển dụng. Bạn và tôi không cần phải hiểu các chi tiết của cơ chế để viết các trình điều khiển, mặc dù. Tất cả chúng ta cần phải hiểu là cơ chế cho phép một chương trình đang chạy trong chế độ người dùng để gọi một chương trình con thực hiện trong chế độ hạt nhân và điều đó cuối cùng sẽ trở lại cho người gọi chế độ sử dụng của nó. Chủ đề Không có bối cảnh chuyển đổi xảy ra trong quá trình này: tất cả thay đổi đó là mức độ đặc quyền của mã thực thi (cùng với một vài chi tiết khác mà chỉ lắp ráp ngôn ngữ lập trình sẽ bao giờ thông báo hoặc quan tâm). Hệ thống con Win32 là một trong hầu hết các lập trình ứng dụng quen thuộc bởi vì nó thực hiện chức năng thường liên kết với giao diện đồ họa người dùng Windows. Các hệ thống con khác đã giảm bên đường theo thời gian. API bản địa vẫn còn, tuy nhiên, và các hệ thống con Win32 vẫn dựa vào nó trong cách tôi mô tả ví dụ trong văn bản.

Các file đính kèm theo tài liệu này:

  • docxLập trình Driver.docx
Tài liệu liên quan