| /haiku/docs/develop/file_systems/ |
| H A D | xfs.rst | 13 There are three ways we can test XFS :
19 But before that we will need to create XFS images for all testing purposes.
24 Currently only linux has full XFS support so we will use linux for generating file system images.
26 First we need to create an empty sparse image using command::
36 Do note that we can create images of whatever size or name we want, for example the above command
37 creates fs.img of size 5 GB, if we alter seek = 10G it will create fs.img with size 10 GB.
76 Now we can mount our file system image and create entries for testing XFS haiku driver.
85 First we have to compile it::
93 Where fs.img is the file system image we created from linux kernel.
98 First build a version of haiku with XFS support, to do this we need to add "xfs" to the `image
[all …]
|
| /haiku/docs/user/interface/ |
| H A D | _layout_intro.dox | 16 which is itself a BLayoutItem. Before we go any further, it is a good idea
38 above would work, but we'll use a BGroupLayout, because it suits this
47 Because we only have one item in this layout, \c orientation and \c spacing
57 Before we can add anything to our layout, we must attach it to something,
58 and here we've used the BWindow::SetLayout() method to accomplish that.
60 to manually <tt>delete group</tt> when we're done with it.
62 Now that we've got our BGroupLayout in place, we can start adding things
69 Now we've got a BWindow with a horizontal BGroupLayout holding
70 a single BView. However, if we want to ensure that our BStringView is always
71 centered in the window, we should give it an explicit BAlignment. So the
[all …]
|
| /haiku/3rdparty/kallisti5/ |
| H A D | howto-iommu.md | 7 true hardware emulation. In this guide we will be configuring a secondary
13 example, we have two graphics cards installed in the Linux system.
27 Now, all we need to do is to reserve the PCI device. We want to make sure
30 First we need to find the PCIID for the device in question. We can find
45 Now that we have our target PCI IDs (in this case, `1002:68c8,1002:aa60`), we can bind this device …
62 Now that the requirements are met, we can attach the target GPU to the vfio driver using the inform…
63 we have collected so far.
83 Now we reboot and cross our fingers.
89 On my AMD Linux system, we can see that IOMMU is active and functional:
104 And checking for vfio we can see it successfully took over my graphics card:
[all …]
|
| H A D | howto-iommu-old.md | 10 true hardware emulation. In this guide we will be configuring a secondary
16 example, we have two graphics cards installed in the Linux system.
49 Now, all we need to do is to reserve the PCI device. We want to make sure
52 First we need to find the PCIID for the device in question. We can find
61 the matching BUS ID and we get our PCI ID:
67 Now that we have our target PCI ID (`1002:68f9`), we can bind this device to
87 Now we reboot and cross our fingers.
89 On my AMD Linux system, we can see that IOMMU is active and functional:
101 And checking for pci-stub we can see it successfully took over my graphics card:
109 Now, we simply attach the device to a VM:
|
| /haiku/docs/develop/kernel/vm/ |
| H A D | swap_file_support.rst | 27 pages and swap space, so we can page in/out when needed. (2) manage the
31 In order to maintain a map between pages and swap space, we need to record
32 the pages' swap address somewhere. Here we use swap blocks. A "swap_block"
34 consecutive pages from a same cache. So whenever we look for a page in swap
35 files, we should get the swap block for it. But how to get the swap block?
36 Here we use hash table. All swap blocks in the system are arranged into a global
42 using address of the cache and page index as hash key, if successful, we get
44 block to get the exact swap address of this page. After that, we can read the
70 and we use swap page index (slot index) as swap space address instead of offset.
71 All the swap pages in the system are given a unified address and we leave one
[all …]
|
| H A D | vm_daemon | 4 Do we need free space?
17 …If the page is not accessed and is active and we need space (free_target), unmap it. If this is th…
19 Move to the next region in this address space, wrap around until we hit the first one.
|
| H A D | vm_cache | 22 …If the cache_ref is null, panic. Otherwise, if we are to aquire a reference and there is an aquire…
25 …If this cache_ref is the last reference to its cache, we call destroy on the store, remove all of …
26 Otherwise, we call the store's release ref and return.
|
| /haiku/build/jam/ |
| H A D | TestsRules | 18 # if TEST_DEBUG is defined, we turn on debugging
23 # define TEST_R5/TEST_HAIKU depending on the platform we build for
52 # define TEST_R5/TEST_HAIKU depending on the platform we build for
79 # define TEST_R5/TEST_HAIKU depending on the platform we build for
96 # if TEST_DEBUG is defined, we turn on debugging
|
| H A D | KernelRules | 26 # override regular CCFLAGS/C++FLAGS, as we don't want them
68 # TODO: Do we really want to invoke SetupKernel here? The objects should
69 # have been compiled with KernelObjects anyway, so we're doing that twice.
72 # Show that we depend on the libraries we need
204 # Show that we depend on the libraries we need
|
| H A D | BootRules | 102 # override regular CCFLAGS/C++FLAGS, as we don't want them
140 # TODO: Do we really want to invoke SetupBoot here? The objects should
141 # have been compiled with BootObjects anyway, so we're doing that twice.
144 # Show that we depend on the libraries we need
210 # Show that we depend on the libraries we need
|
| H A D | SystemLibraryRules | 125 # we need to use the 64-bit libsupc++.a built by the cross-compiler
128 # we need to use the 32-bit libsupc++.a built by the cross-compiler
131 # TODO: ideally, we would build this as part of gcc_syslibs_devel,
135 # no special boot version of libsupc++.a needed, so we return
247 # we need to use the 64-bit libgcc.a built by the cross-compiler
250 # we need to use the 32-bit libgcc.a built by the cross-compiler
253 # TODO: ideally, we would build this as part of gcc_syslibs_devel,
257 # no special boot version of libgcc needed, so we return
|
| H A D | OverriddenJamRules | 49 # uses separate files, we need to remove the target explicitely first, so that
436 # bonefish: No, don't. The Library rule does that anyway, and when we
437 # have an object from another dir, we certainly don't want that.
463 # For compatibility, we only do this if the library doesn't
479 # If we can't scan the library to timestamp its contents,
480 # we have to just make the library depend directly on the
485 # If we can scan the library, we make the library depend
503 # If we can't scan the library, we have to leave the .o's around.
596 # Bail out when reaching the CWD (".") or a directory we've already
613 # $(dir:P) = $(dir)'s parent, & we recurse until root
|
| /haiku/docs/develop/midi/ |
| H A D | todo.rst | 7 midi_driver.h file lists a number of ioctl() opcodes that we are
8 currently not using. Should we? In addition, do we really need to spawn
21 module. Unfortunately, we only know how the v1 interface works; v2 is
24 be a problem for us? It depends on whether we will be able to use the
25 closed-source Be drivers with our own kernel — if not, then we can
31 endpoints must be removed again. Philippe Houdoin suggested we use the
39 slowly reduce the volume and abort the loop after a few seconds. But we
45 existed), but we cannot destroy be_synth from the BMidiSynth destructor
|
| /haiku/docs/develop/build/rc/ |
| H A D | beres-deres.rst | 15 Our handling of the minus sign is more restrictive; we don't treat it like a unary minus operator,
34 beres allows multiple type codes and/or type casts per resource statement/data field, but we allow
35 only one of each. Because we don't associate type codes with data (but only with the resource
36 itself or with individual message fields), we don't allow the shortcut notation that lets you put a
39 We do not allow arrays to have named fields, nor do we allow messages (and archives) to have
40 unnamed fields. beres apparently treats all compound data the same, but we don't, because not all
52 (beres ignores that anyway). When you cast an archive to a message, we don't strip the "class"
53 field (in fact, we don't perform any conversion).
60 "explicit names only" option is set. We do that the other way around: we don't automatically add
|
| H A D | notes.rst | 10 negative numbers too. Maybe we can replace the calls to 'integer' with 'data' and allow the data
17 the name of the field is an IDENT token, but we already have something like that in the 'type'
45 Right now, archives are treated as messages. Maybe we should give them their own type,
73 (or instead) we can extend user-defined types to have their own (local) defines too. If we use the
74 #define keyword, we should infer the type of the constant from the data (100 is integer, 10.5 is a
75 float, etc). This is necessary because we don't have a separate preprocessor step like C/C++ does --
|
| /haiku/3rdparty/pulkomandy/ |
| H A D | haiku_arm_qemu_gdb | 21 # Load the bootloader symbols so we can see what we're doing
24 # Set a breakpoint at our entry point, so we can watch things roll after the
|
| /haiku/src/tests/kits/storage/disk_device/ |
| H A D | Jamfile | 12 # We compile these classes in. If we would link against libbe_haiku
13 # instead, we couldn't use any GUI. At least not at this time.
|
| /haiku/src/servers/app/drawing/Painter/ |
| H A D | NOTES | 4 some other modes act weird on the dest alpha channel, I guess we should not copy that behaviour
12 …ogically 255, it wouldn't even need to be assigned. Maybe we could save a few CPU cycles if we adj…
|
| /haiku/docs/develop/kernel/boot/ |
| H A D | Debugging_Bootloaders_GEF.rst | 27 In the example below, we will prepare Haiku arm in QEMU for debugging.
47 In the example above, we are Emulating a Raspberry Pi 2, and using
60 Once GEF is installed, we can step through the process to attach gdb to
66 First we run gdb pointed at our boot loader. We use the native ELF
76 This may not be required, but re-enforces to gef/gdb that we’re working
84 Now we tell gdb/gef about out running (but paused) QEMU instance.
|
| /haiku/docs/develop/kernel/arch/sparc/ |
| H A D | overview.rst | 24 The input and local registers are callee-saved, but we have hardware assistance
59 give back control to the application. This is, of course, very slow, so we
83 In the end, we just need to be careful about pointer math resulting in unalined
85 (where the alignment is preserved even when casting to other types). So we
87 identify places where we do a lot of misaligned accesses that trigger it, and
88 rework the code as needed. But in general, except for these cases, we're fine.
96 The Ultrasparc-II we are supporting for now is documented in the Ultrasparc
106 have at hand, later on we will need support for the more recent systems.
121 keep track of the mappings. This means we are relatively free to manage things
122 however we want, as long as eventually we can feed the iTLB and dTLB with the
[all …]
|
| /haiku/docs/user/app/ |
| H A D | _app_keystore.dox | 101 We are working on the infamous Langlaufer web browser, and we are adding
102 a feature where we autocomplete user names and passwords. It is decided to
103 use the Password and Key Storage API to do our key management. Whenever we
104 land on a web page with a login screen, we will try to see if we have
105 credentials for that web page. Part of the requirements is that we support
109 own keyring, as we do not want to interfere with any other keys in the
110 master key. Additionally, we will use both the primary and secondary
133 // There may be more than one match, so we use the iteration methods.
159 // authorization, or we are at the end of the list.
201 Instead of building one monolithic application, we make several small tools
[all …]
|
| /haiku/src/kits/screensaver/ |
| H A D | README | 31 This is a ScreenSaver addon we wrote for fun. It will be installed in
46 This is a partial list of what we intend to implement. Suggestions are welcome:
|
| /haiku/src/tools/makebootable/platform/pxe_ia32/ |
| H A D | Jamfile | 3 # we don't need this tool for creating PXE boot image
|
| /haiku/headers/private/system/arch/arm/ |
| H A D | arch_arm_version.h | 11 #error we do not support this
|
| /haiku/data/system/boot/ |
| H A D | SetupEnvironment | 2 # First we set up a bunch of environment variables that we want everyone
73 # XXX: Should we add B_USER_ETC_DIRECTORY?
|