net: data reception system, fixed bugs in rtl8139
[quarnos.git] / docs / Device_detection.tex
blob55bb0f956c2104d8ea271128f622a61ce5a76447
1 \documentclass[a4paper,10pt]{article}
3 \usepackage{hyperref}
4 \usepackage{ucs}
5 \usepackage{graphicx}
6 \usepackage{pgf}
8 \begin{document}
10 \title{\textbf{Device detection}}
11 \author{Pawel Dziepak}
12 \date{\textit{April 4, 2009}}
13 \maketitle
15 \begin{abstract}
16 This article is a description of algorithms and data structures used to manage and store device information including automatic detection at the system startup and after registering new device driver.
17 \end{abstract}
19 \section{Introduction}
20 \paragraph{} \textit{to be completed}
22 \section{Device objects}
23 \paragraph{} In Quarn OS each device is represented as an object managed by the Manes system. \cite{manes_doc} The parent of each device and bus (except the root one) is the bus it is connected to. Manes allows to create hierarchy of devices that corresponds to the real connections between them, while accesing them is still very simple and doesn't need any knowledge about its position. From the client point of view devices are completely independent from each other whereas drivers can obtain specific information about buses and other relations that is needed to use hardware properly.
24 \subsection{Device drivers}
25 \paragraph{} Device drivers in Manes are registered as special object types. They can be added to the system at any time gaining control over previously detected (but unrecognized) devices. What makes them different to other types is abilitiy (and somehow obligation) to provide certain interface\footnote{In Quarn OS each type is in fact an object but in most cases its possibilities are significantly reduced. In fact only drivers are allowed to provide a minimalistic interface to check if they can communicate with a device.}.
26 \subsection{Device Identifiers}
27 \paragraph{} In order to let drivers communicate with devices DID (\textit{device identifier}) objects were introduced. They store bus-dependent information that are essential to access hardware. Each device and bus object stores reference to its own DID.
28 \paragraph{} DID may store either general information needed to access device directly or internal bus address that requires device driver to use bus driver in order to comunicate with attended piece of hardware. However a reference to the bus is always present.
31 \section{Bus initialization}
32 \paragraph{} \textit{to be completed}
34 \section{Detection algorithm}
35 \paragraph{} Device detection is performed while scanning bus in search for new devices. The whole procedure what happens when a device is found is presented on figure \ref{fig:devdet} and described below.
36 \paragraph{} If device is found, bus driver asks each possible drivers if they support it. At this stage device is represented only by its DID. To reduce performance hit drivers may be organized into groups assigned to certain buses or even device classes while the latter depends on the amount of information the bus provides.
37 \paragraph{} If a driver claims that it is able to manage the device, new object of appropiate type is created. At this point bus driver is permitted to continue bus scan while device initializtation can be performed asynchrously and does not affect other parts of the system.
38 \paragraph{} If there is no registered driver that recognize new device, an object of type \texttt{unknown} is created. It stores only DID and its own type information what may be needed when new driver is registered to check if it support that device.
40 \begin{figure}
41 \centering
42 \begin{center}
43 \includegraphics[width=50ex,height=41ex]{devicedetect.eps}
44 \end{center}
45 \caption{Device detection algorithm}
46 \label{fig:devdet}
47 \end{figure}
50 \section{Related work}
51 \paragraph{} \textit{to be completed}
53 \begin{thebibliography}{100}
54 \bibitem{manes_doc} P. Dziepak: \textit {Managed Execution System}, Quarn OS Documentation, 2009.
55 \end{thebibliography}
57 \end{document}