| /barrelfish-master/usr/skb/programs/ |
| H A D | count_loc_pci_linux | 3 LINUX_PCI_PATH=/home/scadrian/abaglada/linux/kernel/linux-2.6.33.3/drivers/pci
|
| H A D | plat_omap44xx.pl | 29 driver_deps, % Dependencies on other drivers
|
| H A D | pci_queries.pl | 38 % because the drivers expect them in this order. A explicit
|
| H A D | bridge_bios.pl | 23 % Filter IO BARs because some device drivers aren't able to handle them...
|
| H A D | device_db.pl | 6 core_offset, % Core offset where to start the drivers (multi instance)
|
| /barrelfish-master/usr/drivers/dma/ |
| H A D | main.c | 26 size_t drivers = 0; local
28 driverkit_list(&cur, &drivers);
29 for (size_t i=0; i<drivers; i++) {
|
| /barrelfish-master/lib/driverkit/ |
| H A D | modules.c | 42 * \param[out] num How many drivers there are.
57 size_t drivers = 0; local
59 driverkit_list(&cur, &drivers);
61 for (size_t i=0; i<drivers; i++) {
|
| /barrelfish-master/lib/acpica/generate/linux/ |
| H A D | libacpica.sh | 23 drivers/acpi/acpica \
123 drivers/acpi/acpica/utclib.c \
368 elif [ ! -f $to/drivers/acpi/acpica/$inc ] ; then
386 mkdir -p drivers/acpi/acpica
391 mv source/$path/*.[ch] drivers/acpi/acpica/
395 mv source/$path drivers/acpi/acpica/
|
| /barrelfish-master/doc/019-device-drivers/ |
| H A D | DeviceDriver.tex | 62 This document describes how we write device drivers in Barrelfish. It will walk
70 There are three main entities when discussing drivers:
73 \item[Driver Domain] Is a domain that executes one or more drivers. It is
92 domain can be found in \pathname{usr/drivers/domain/main.c}, with most of the
115 \pathname{usr/drivers/domain/drivertpl.c}. The driver is then statically linked
121 For an example, take a look at \pathname{usr/drivers/domain/Hakefile}.
157 \chapter{Legacy device drivers}
160 Legacy drivers live within a 9single) domain and the structure, as well as the control
164 device drivers are still legacy drivers
[all...] |
| /barrelfish-master/doc/023-coreboot/ |
| H A D | coreboot.tex | 68 \section{Boot drivers}
70 Barrelfish uses \textit{boot drivers}, which is a piece of code running on a
72 functionality to boot, suspend, resume, and power-down the latter. Boot drivers
73 run as processes, but closely resemble device drivers and could equally run as
77 drivers and kernels for them. The code for the Barrelfish boot driver can be
78 found in \texttt{usr/drivers/cpuboot/}. From the source folder, a binary called
85 Is the binary that runs on a core and executes in privileged mode. CPU drivers
87 and they share no state or synchronization. CPU drivers are typically
91 a more detailed explanation of CPU drivers and the provided functionality.
93 The code for the Barrelfish CPU drivers ca
[all...] |
| /barrelfish-master/doc/016-serial-ports/ |
| H A D | Serial.tex | 53 to serial ports, used internally by CPU drivers for debugging and
57 drivers and other console subsystems.
61 CPU drivers use serial port access for printing debug information,
135 Barrelfish CPU drivers have access to two logical serial ports:
212 implementation (for example, some x86 CPU drivers use a global
|
| /barrelfish-master/doc/021-cpudriver/ |
| H A D | cpudriver.tex | 28 \title{CPU drivers in Barrelfish}
31 \tnkey{CPU drivers}
73 Barrelfish currently supports the following CPU drivers for
137 logic that boots APP cores resides in \pathname{usr/drivers/cpuboot}.
140 \pathname{usr/drivers/cpuboot/x86boot.c}, specifically in the function called
|
| /barrelfish-master/doc/000-overview/ |
| H A D | Overview.tex | 96 \section{CPU drivers}
100 CPU driver, and there is no reason why these drivers have to be the
103 In a heterogeneous Barrelfish system, CPU drivers will be different
105 drivers for different cores can be specialized for some purposes (for
109 CPU drivers are single-threaded and non-preemptible.
111 with other cores. CPU drivers can be thought of as serially executing
129 CPU drivers do not provide kernel threads, for two reasons. Firstly,
136 CPU drivers schedule dispatchers. The scheduling algorithm employed
438 from the optimized nature of interconnect drivers. For example,
484 \section{Device drivers}
[all...] |
| /barrelfish-master/doc/003-hake/ |
| H A D | Hake.tex | 220 dynamic discovery of code (e.g., device drivers modules).
355 \texttt{drivers/e1000/Hakefile} will appear in the resulting Makefile
356 as {drivers/e1000/e1000.c}.
363 \texttt{drivers/e1000/Hakefile} will appear in the resulting Makefile
364 as {./x86\_64/drivers/e1000/e1000.o}.
460 Hence, if a Hakefile at ``\texttt{drivers/e1000/Hakefile}'' contained
467 ./x86_64/drivers/e1000/libe1000drv.a: \
468 ./x86_64/drivers/e1000/e1000.o \
469 ./x86_64/drivers/e1000/e1000srv.o
470 ar cr ./x86_64/drivers/e100
[all...] |
| /barrelfish-master/doc/012-services/ |
| H A D | Services.tex | 149 device drivers inlcude IO devices, as well as internal devices such as
462 %% drivers, etc.
473 %% interaction. This is at a higher level than device drivers, and
616 Device drivers depend on the capability management service since they
622 Since drivers must react to system power events (e.g., to turn devices
631 determine current power state and possibly inform drivers of changes
694 The network stack service requires access to NIC drivers to access the
696 network hardware and drivers are available in the system.
703 The power management service requires access to device drivers and the
739 management, bus management, drivers, storag
[all...] |
| /barrelfish-master/doc/011-idc/ |
| H A D | IDC.tex | 354 drivers, with implementations varying widely according to the properties of
355 the interconnect driver. However, common to all interconnect drivers for a
752 The following operations on channels are used by interconnect drivers to change
766 These operations are available only to interconnect drivers, using
833 \section{Interconnect drivers}
836 Interconnect drivers implement the runtime support needed by specific
839 interconnect drivers, they typically support the following:
853 The interconnect drivers that are available in a given domain are determined by
862 The export and binding process for all interconnect drivers is mediated by
885 different interconnect drivers us
[all...] |
| /barrelfish-master/doc/017-arm/ |
| H A D | ARM.tex | 254 The Barrelfish ARMv7 CPU drivers can handle up to 1GB RAM,
258 to map many kernel devices since most drivers run in user space on
603 Since most Barrelfish device drivers run in userspace, the difference
623 code and individual device and macrocell drivers.
631 \item[serial.h]: Low-level drivers for a multiple UART devices.
633 coordinating access to e.g. serial devices between CPU drivers on
|
| /barrelfish-master/doc/006-routing/ |
| H A D | Routing.tex | 146 The multi-hop interconnect driver was designed to be independent of the type of the underlying ICD links between the nodes on the multi-hop channel. This means that it uses the common flounder interface supported by all ICDs when interacting with the underlying ICD link and uses no ICD-specific knowledge. This design involves a performance penalty: Interacting directly with the underlying ICDs instead of via the common flounder-interface would certainly perform better. Nevertheless, we chose this design, as it gives us more flexibility: The multi-hop interconnect channel can run over all present and future interconnect drivers in Barrelfish, as long as they support the common flounder interface.
150 Interconnect drivers in Barrelfish generally provide a reliable messaging service: A message is delivered only once and each message sent is eventually delivered and its content is not corrupted. Furthermore, messages are delivered in FIFO order. The multi-hop interconnect driver is designed to provide a reliable messaging service in principle. However, contrary to the end-to-end argument, it does not provide any \emph{end-to-end} reliability, but builds on the reliability provided by the interconnect drivers of the underlying links. We accept that the multi-hop interconnect driver can fail in case any of the interconnect drivers of the underlying link fail.
242 Because capabilities are maintained as references to per-core state in the CPU drivers, only the LMP interconnect driver which traverses kernel-mode code can directly deliver a capability along with message payload. In the multi-hop interconnect driver, capabilities travel out-of-band from other message payload.
292 Flounder is a stub compiler which generates stubs for defined interfaces. To support multi-hop messaging, we created a new back-end code generator for the flounder stub compiler that generates code to use the multi-hop interconnect driver. Applications do not interact with the multi-hop interconnect driver directly, but only over the generated stubs. The stubs for the multi-hop interconnect driver have the exact same interface as stubs for other interconnect drivers. This makes application code independent of the interconnect driver used for communication.
299 In order to initiate a binding, a client dispatcher calls the bind function for a given interface. Because Barrelfish features multiple interconnect drivers, the interface's bind function will have to decide which interconnect driver to use in order to establish the binding. Currently, it ''asks'' the different interconnect drivers to establish a binding in a predefined order (for example, the LMP driver is always first). As soon as an interconnect driver manages to establish the binding, the binding process is finished. Should one interconnect driver fail, the next one in order is tried.
301 If an application wants to create a new multi-hop channel, it can pass the flag \texttt{IDC\_BIND\_FLAG\_MULTIHOP} as an argument to the interface's bind function. This changes the order of the interconnect drivers: The multi-hop interconnect driver will come in second place, directly after the LMP driver. The LMP driver is first, because it is preferable to the multi-hop interconnect driver if client and service are running on the same core. If the multi-hop interconnect driver fails to establish a binding for some reason, the binding process continues as normal with the other interconnect drivers
[all...] |
| /barrelfish-master/doc/002-mackerel/ |
| H A D | Mackerel.tex | 956 \chapter{C mapping for device drivers}\label{chap:shiftdriver}
1442 \chapter{Bitfield C mapping for device drivers}\label{chap:bitfielddriver}
1946 \item[BitFieldDriver.hs] Old code generator for device drivers using
1958 \item[ShiftDriver.hs] Code generator for device drivers using shifts and masks.
|
| /barrelfish-master/doc/022-armv8/ |
| H A D | report.tex | 484 The x86-32, x86-64, and ARMv7 CPU drivers all store the address of the running
|