users

users@lists.genode.org

2357 discussions

base-linux/src/base/env/rm_session_mmap.cc/Platform_env::Rm_session_mmap::attach
by Sven Fülster 04 Aug '09

04 Aug '09

Hi all, is there a special reason why you don't have implemented the 'attach_at'-support to a local address in the base-linux code? I need this feature (and my fix seems to work well here). I'll also need this feature in the base-okl4 code (and I would try to add it also there if necessary...) Is there any risk/ nasty surprise when using it? Thank you and kind regards Sven -- Sven FÃ¼lster

2 2

Problem with 'test-pci'
by Frank Kaiser 04 Aug '09

04 Aug '09

Hello As a preparation of a certain task I want to check the PCI resources of my platform (IVI platform with Intel ATOM). For this purpose I built Genode-on-OKL4, only consisting of a minimum driver set and the test-pci application. Running this image in qemu looks good, but on the IVI platform the init process fails with a page fault before or when starting the PCI driver which is the first entry in the config file. The error message is: no RM attachment (READ pf_addr=6000 pf_ip=2001286 from 01) I have no clue what this message is trying to tell me. The given IP points to the function Genode::strncpy(). I also wonder why the system wants to read from virtual address 0x6000, because all modules are allocated beginning at virtual address 0x02000000. Checking init's pagetable with OKL4's KDB on qemu shows a number of allocations below: 00000000 [00140027]: tree=f0140000 00001000 [001f5067]: phys=001f5000 pg=f0140004 4KB rwx (RWX) user WB 00003000 [001f7067]: phys=001f7000 pg=f014000c 4KB rwx (RWX) user WB 00004000 [001f8067]: phys=001f8000 pg=f0140010 4KB rwx (RWX) user WB 00005000 [001df025]: phys=001df000 pg=f0140014 4KB r~x (R~X) user WB 00006000 [00275067]: phys=00275000 pg=f0140018 4KB rwx (RWX) user WB 00007000 [00276067]: phys=00276000 pg=f014001c 4KB rwx (RWX) user WB 00008000 [00277067]: phys=00277000 pg=f0140020 4KB rwx (RWX) user WB 00009000 [00278067]: phys=00278000 pg=f0140024 4KB rwx (RWX) user WB 0000a000 [00368067]: phys=00368000 pg=f0140028 4KB rwx (RWX) user WB 0000b000 [00369067]: phys=00369000 pg=f014002c 4KB rwx (RWX) user WB 0000c000 [0036a067]: phys=0036a000 pg=f0140030 4KB rwx (RWX) user WB 0000d000 [0036b067]: phys=0036b000 pg=f0140034 4KB rwx (RWX) user WB 0000e000 [0037b067]: phys=0037b000 pg=f0140038 4KB rwx (RWX) user WB 00012000 [003fa067]: phys=003fa000 pg=f0140048 4KB rwx (RWX) user WB 00016000 [00852067]: phys=00852000 pg=f0140058 4KB rwx (RWX) user WB 0004a000 [00336067]: phys=00336000 pg=f0140128 4KB rwx (RWX) user WB 00066000 [00370067]: phys=00370000 pg=f0140198 4KB rwx (RWX) user WB On the IVI platform this area at the time of the page fault looks: 00000000 [00141027]: tree=f0141000 00001000 [001f5067]: phys=001f5000 pg=f0141004 4KB rwx (RWX) user WB 00005000 [001df025]: phys=001df000 pg=f0141014 4KB r~x (R~X) user WB I'd like to get some hints where to look into the code for finding the cause of the problem. Since I cannot debug the platform, I probably have to add more trace messages to get additonal information about what is going on. Regards Frank

3 6

VESA framebuffer - minor bug with the PCI resource addressing
by Robert Wetzel 04 Aug '09

04 Aug '09

Hi, while having punched the VESA framebuffer driver to work properly with the PCI driver I stumbled over a minor bug in the handle_pci_port_read() function in ifx86emu.cc, lines 183 and 185. The resource index is calculated as an address offset, whereas it should be an index (which equals the address offset divided by 4). Some additional info (in the context of VESA BIOS madness): The VESA BIOS in use here also required 16bit read accesses (easy to add, the port offset to 0xcfc can be used to shift the value) and some other odd stuff from the PCI config space. Interestingly, it also knows exactly where to look for the gfx card in the PCI space; there was no enumeration at all (probably initialized the values at the startup). After the changes pci_drv and vesa_drv decided to work together again instead of stealing each others cookies. Greets, Robert

2 1

Tracing with Genode on OKL4
by Frank Kaiser 30 Jul '09

30 Jul '09

Hello Is there any specific reason why trace output generated with printf() or similar functions is not routed to OKL4's KDB interface (functions L4_KDB...)? Instead in file okl4_console.cc a direct access to COM1's hardware registers is implemented. This creates the problem that there is a concurrency access to the hardware by the OKL4 kernel and any Genode-based application. In my case it is even worth, because I deal with a hardware which does not provide a legacy COM port. I have adapted the KDB to the specific hardware, so any application using the KDB interface would benefit from it. But Gernode ignoring it makes it unrunnable on this special platform. Since the problem is urgent, I require some hints to make Genode able using OKL4's KDB interface. Regards Frank

2 2

Some very minor typos in the documentation
by ross mcginnis 28 Jul '09

28 Jul '09

Hello, I am just emailing with a list of some typos that I noticed when I read the project documentation a while back. These are very minor and hardly worth fixing and some aren't even true errors but just stylistic opinion, but I hope my mentioning them helps the project in some (very small) way. The erros are in square brackets in the list of notes below: GENERAL OVERVIEW: >General overview : The high functional requirements and the broad range of existing hardware [let =>causes?] such a kernel grow huge. >General overview : Each user application runs within a dedicated address space and [interact => interacts] in a safe, well-controlled manner with other user applications only via mechanisms provided by the kernel. >General overview : Even though Genode allows for dynamic workload and arbitrarily structured process trees, the system remains [to behave => ""] deterministic. ------------------------ ARCHITECTURE: >Genode architecture documents :This correlation is [particular=>particularly] perturbing for todays commodity operating systems with their tremendous complexity. >Goals and Challenges: Given the special liability of such an application, it is very carefully designed, low [complex=>complexity : This sentence could perhaps be reworded: "... it is very carefully designed to have low complexity and require as little infrastructure as possible."], and requires as little as possible infrastructure. >Interfaces and Mechanisms: The parent, in turn, can mediate such a service to [his=>its] other children. >Interfaces and Mechanisms: is called by a child to request a connection to the specified service as known by [his=>its] parent whereas service_name is the name of the desired service interface. >Interfaces and Mechanisms: Each parent can decide [upon=>""] itself whether to further announce services of their children to the outer world or not >Interfaces and Mechanisms: Once a session [got=>is/has been?] established, its properties are fixed and cannot be changed. >Core:The only policy of core is the startup of the init process to which core grants all available resources[ to init=>""]. >Core:To make the RAM session functional, it must be loaded with quota from another already existing RAM session, which we call [""=>the?] reference account. >Core:On session construction, a file identifier must be specified as [""=>a] session argument using the tag filename. >Core:For platforms that rely on I/O ports for device access, core's IO_PORT service enables [fain=>fine]-grained assignment of port ranges to individual processes. >Core: The set_pager function registers the thread's pager whereas pager_cap (obtained by calling add_client at a RM session) refers to the RM session to be used as [""=>the] address-space layout >Core: Once a new thread [got=>is/has been?] created from a CPU session, it can be assigned to the PD by calling: >Process creation: [ctc=>csc].set_pager(thread_cap, pager_cap); >Process creation: [ctc=>csc].start(thread_cap, ip, sp); >Framework infrastructure: The special object IPC_REPLY_WAIT replies [""=>to] the request of the previous server-loop iteration with the message stored in snd_buf (ignored for the first iteration) and then waits for an incoming RPC request to be received in rcv_buf. >Framework infrastructure: The interface of the server entrypoint [envisions=> ? : prehaps a better word here, unfortunately I can't really think of one. I would reword it slightly and use the word "provides"?] to attach multiple server activations to one and the same server entrypoint to enable the concurrent handling of multiple RPC requests. ----------------------------------------- DEVELOPER RESOURCES: >How to start exploring Genode: If you now issue make again, you will see some additional targets such as init, nitpicker, timer, and fb_sdl [to be=>are] created. >How to start exploring Genode: When specifying search locations for header files via the INC_DIR variable or for source [file=>files] via vpath, relative pathnames are illegal to use >Walking through the Genode demo scenario: The creation [of=>and] destruction of single processes as well as arbitrarily complex sub systems >Walking through the Genode demo scenario: In Figure 3, you see an illustration of the current setup. At the very bottom, there are the kernel, core, and init. Init has started framebuffer, timer, input [Figure 3 doesn't have the input server], nitpicker, and launchpad as it children (note: on Linux, input and framebuffer are both contained in the fb_sdl process). >Walking through the Genode demo scenario: When started, testnit tells us some status information. By further starting the program called nitlog, we create a new LOG service as [""=>a] child of launchpad. >Walking through the Genode demo scenario: Init as the parent of scout again overrides this label [by=>with] the name of its immediate child from which the GUI request comes from >Creating your first Genode application: The Genode build system enables developers to create software in different repositories that don't need to [interfer=>interfere] with the rest of the Genode tree. >Creating your first Genode application: [For=>A] client using the Hello service will invoke the service functions by using a session capability. >Creating your first Genode application: This function is responsible for parsing the parameter string the client hands over to the server and [create=>creates] a Hello::Session_component object from these parameters. >Conventions for the Genode development: Each directory should contain a file called README that [shortly=>concisely/briefly?] explains what the directory is about. In doc/Makefile is a rule for generating an directory overview from the README files automatically. >Conventions for the Genode development: In doc/Makefile is a rule for generating [an=>a] directory overview from the README files automatically. ---------------------------------------- API REFERENCE INDEX: >Base API: The PD [services is=>service is/services are] rarely used by applications directly. >Base API: The heap can be used for anonymous memory allocation and is [""=>the] front end for allocating RAM dataspaces from the process' RAM session and attaching these dataspaces to the process' RM session. >Base API: By default, the process environment holds one initial LOG session used as [""=>the] standard text-output facility. >Base API: Most book-keeping tasks in Genode rely [in=>on] single-connected lists, which use the List template. >Base API: Signals are communicated in a reliable fashion, which means that the exact number of signals submitted to a signal transmitter [is=>are?] communicated to the corresponding signal receiver. >Base API: Timed sleep is rather [be=>"" : you could also perhaps replace "rather" with "instead"] provided by a server implementing a timer-device driver. -------------------------------------- Hope this helps the project, Ross McGinnis _________________________________________________________________ View photos of singles in your area Click Here http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fdating%2Eninemsn%2Ecom%2Eau…

2 1

Executable file loading from weaver.elf
by Sven Fülster 16 Jul '09

16 Jul '09

Hi all, I'm working on debugging some code, and going along with that, the qemu remote debugging turned out to be really nasty concerning an elfweaver-merged image. I have a small elf image (built with elfweaver due to the OKL stuff), and this elf image contains a dde driver I've written. Originally, my driver code was linked to a standard base address like any other executable built with the genode buildsystem. -- kamikaze@...22...:~/okl4/okl4_2.1.1-fix.7/genode-okl4-x86/bin$ readelf -S test-dde_linux26_net There are 30 section headers, starting at offset 0x46b030: Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .text PROGBITS 02000000 001000 06c1cc 00 AX 0 0 128 [ 2] .altinstr_replace PROGBITS 0206c1cc 06d1cc 00011d 00 AX 0 0 1 [ 3] .sched.text PROGBITS 0206c2f0 06d2f0 000f26 00 AX 0 0 16 [ 4] .kprobes.text PROGBITS 0206d216 06e216 000058 00 AX 0 0 1 [ 5] .spinlock.text PROGBITS 0206d26e 06e26e 0001e7 00 AX 0 0 1 [ 6] .fixup PROGBITS 0206d455 06e455 00002a 00 AX 0 0 1 [ 7] __ex_table PROGBITS 0206d47f 06e47f 000130 00 A 0 0 1 [ 8] .data PROGBITS 0206e000 06f000 009cc8 00 WA 0 0 128 [ 9] .got PROGBITS 02077cc8 078cc8 000088 04 WA 0 0 4 [10] .got.plt PROGBITS 02077d50 078d50 00000c 04 WA 0 0 4 [11] .init.setup PROGBITS 02077d5c 078d5c 000030 00 WA 0 0 4 [12] .eh_frame PROGBITS 02077d8c 078d8c 006c2c 00 A 0 0 4 [13] .gcc_except_table PROGBITS 0207e9b8 07f9b8 0012e0 00 A 0 0 4 [14] .altinstructions PROGBITS 0207fc98 080c98 000473 00 A 0 0 4 [15] .smp_locks PROGBITS 0208010c 08110c 0004ec 00 A 0 0 4 [16] __param PROGBITS 020805f8 0815f8 000208 00 A 0 0 4 [17] .bss NOBITS 02080800 081800 01e4e0 00 WA 0 0 128 [18] .debug_abbrev PROGBITS 00000000 081800 0236a2 00 0 0 1 [19] .debug_info PROGBITS 00000000 0a4ea2 2be0b6 00 0 0 1 [20] .debug_line PROGBITS 00000000 362f58 03d9ac 00 0 0 1 [21] .debug_frame PROGBITS 00000000 3a0904 01ff78 00 0 0 4 [22] .debug_loc PROGBITS 00000000 3c087c 06426e 00 0 0 1 [23] .debug_pubnames PROGBITS 00000000 424aea 015b4b 00 0 0 1 [24] .debug_aranges PROGBITS 00000000 43a638 003858 00 0 0 8 [25] .debug_str PROGBITS 00000000 43de90 029bf7 01 MS 0 0 1 [26] .debug_ranges PROGBITS 00000000 467a88 003460 00 0 0 8 [27] .shstrtab STRTAB 00000000 46aee8 000147 00 0 0 1 [28] .symtab SYMTAB 00000000 46b4e0 011760 10 29 1788 4 [29] .strtab STRTAB 00000000 47cc40 01b474 00 0 0 1 -- Upon merging all the binaries with elfweaver, only the base address of 'core' remained almost as it was linked originally. My driver instead was re-linked, so that its sections didn't overlap with any other. -- Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [10] core.text PROGBITS 02000000 04b000 033590 00 AX 0 0 32 [11] core.data PROGBITS 02034000 07f000 000ca4 00 WA 0 0 32 [12] core.got PROGBITS 02034ca4 07fca4 000088 04 WA 0 0 4 [13] core.got.plt PROGBITS 02034d2c 07fd2c 00000c 04 WA 0 0 4 [14] core.eh_frame PROGBITS 02034d38 07fd38 007c88 00 A 0 0 4 [15] core.gcc_except_t PROGBITS 0203c9c0 0879c0 001858 00 A 0 0 4 [16] core.bss NOBITS 0203e220 089218 01a570 00 WA 0 0 32 [21] test-dde_linux26_ PROGBITS 00c00000 2ff000 4980b4 00 WA 0 0 1 [22] bootinfo PROGBITS 04004000 798000 001000 00 WA 0 0 1 [23] .shstrtab STRTAB 00000000 799000 000116 00 0 0 1 -- When I now start to remote-debug my stuff... -- add-symbol-file /home/kamikaze/okl4/okl4_2.1.1-fix.7/genode-okl4-x86/bin/test-dde_linux26_net 0x00c00000 -- ...and set a breakpoint in dde_thread_main... -- (gdb) b dde_thread_main Breakpoint 2 at 0xc0183e: file /home/kamikaze/genode/sandbox/src/test/dde_linux26_net/main.cc, line 156. (gdb) c -- ...this breakpoint is never triggered, although the thread obviously passes it. So I wonder what init does when it starts up my code. Does my program's virtual address space look like the elfweaver-merged stuff? Or does it look like the original (how would that work)? Or does init even choose another base address? How would I then introduce the symbol-file to gdb? Thanx in advance Sven -- Sven FÃ¼lster

2 5

Genode on OKL4 Startup kicks pci driver when reading [cfc,d00) port range
by Sven Fülster 08 Jul '09

08 Jul '09

Hi all, sorry that I must repeat bothering you :) I've now set up Genode on the OKL4 kernel for use on my Intel Atom hardware, and I see that sometime during the startup process, the pci-driver is kicked due to an error I don't understand: -- [init -> test-dde_linux26_usbhid] Initializing DDE Linux 2.6 pa ge cache Genode::Io_port_session_component::Io_port_session_component(Genode::Ran ge_allocator*, const char*): I/O port [cfc,d00) not available [init -> pci_drv] v oid* fwrite(): fwrite - not yet implemented [init -> pci_drv] void* fputs(const c har*, void*): fputs: "Genode::Parent::Service_denied" [init -> pci_drv] void* fwr ite(): fwrite - not yet implemented [init -> pci_drv] void* abort(): abort called -- Do you have any idea what's missing in my setup? Thanx in advance Sven -- Full startup log (sorry for the nasty tab width - what funny serial driver is this in the OKL kernel? :) ): OKL4 - (provider: Open Kernel Labs) built on Jul 7 2009 09:27:57 using gcc vers ion 3.3.4. kimg: 0x100200 - 0x147000 Found l4 kernel heap! at [00400000, 00800000) pc99 heap [00400000, 00800000) mapping heap at 0x400000 zero base f0400000 to end f0800000 done zero parsing boot info at 0x4004000... int main(): --- create local services --- int ma in(): --- start init --- int main(): Ok we have 48 MB transfered to init int main( ): --- init created, waiting for exit condition --- [init] our quota limit is 503 64416 [init] our used quota is 147456 [init] starting timer with quota=1048576 [in it] using unique child name "timer" [init] starting pci_drv with quota=1048576 [in it] using unique child name "pci_drv" [init] starting test-dde_linux26_usbhid wit h quota=1048576 [init] using unique child name "test-dde_linux26_usbhid" [init] ti mer registered service Timer [init -> pci_drv] PCI driver started [init] pci_drv r egistered service PCI [init] starting vesa_drv with quota=1048576 [init] using uni que child name "vesa_drv" [init] starting nitpicker with quota=1048576 [init] usin g unique child name "nitpicker" [init] vesa_drv registered service Framebuffer [in it] test-dde_linux26_usbhid registered service Input [init -> vesa_drv] bool hand le_pci_port_write(short unsigned int, T) [with T = long unsigned int]: accessing unknown PCI device 10 [init -> vesa_drv] bool handle_pci_port_read(short unsigne d int, T*) [with T = X86emu::x86emuu16]: reading with size 2 not supported [init -> vesa_drv] Found: VESA BIOS version 3.0 [init -> vesa_drv] OEM: Intel(r)Poulsbo Graphics Chip Accelerated VGA BIOS [init -> vesa_drv] bool handle_pci_port_write (short unsigned int, T) [with T = long unsigned int]: accessing unknown PCI devi ce 10 [init -> vesa_drv] bool handle_pci_port_read(short unsigned int, T*) [with T = X86emu::x86emuu16]: reading with size 2 not supported [init -> vesa_drv] bool handle_pci_port_write(short unsigned int, T) [with T = long unsigned int]: acce ssing unknown PCI device 10 [init -> test-dde_linux26_usbhid] Softirq daemon star ting [init -> vesa_drv] bool handle_pci_port_write(short unsigned int, T) [with T = long unsigned int]: accessing unknown PCI device 10 [init -> vesa_drv] bool ha ndle_pci_port_read(short unsigned int, T*) [with T = X86emu::x86emuu16]: reading with size 2 not supported [init -> test-dde_linux26_usbhid] void dde_thread_main (): --- initcalls [init -> test-dde_linux26_usbhid] Initializing DDE Linux 2.6 pa ge cache Genode::Io_port_session_component::Io_port_session_component(Genode::Ran ge_allocator*, const char*): I/O port [cfc,d00) not available [init -> pci_drv] v oid* fwrite(): fwrite - not yet implemented [init -> pci_drv] void* fputs(const c har*, void*): fputs: "Genode::Parent::Service_denied" [init -> pci_drv] void* fwr ite(): fwrite - not yet implemented [init -> pci_drv] void* abort(): abort called [init -> vesa_drv] bool handle_pci_port_write(short unsigned int, T) [with T = l ong unsigned int]: accessing unknown PCI device 10 [init -> vesa_drv] bool handle _pci_port_read(short unsigned int, T*) [with T = X86emu::x86emuu16]: reading wit h size 2 not supported [init -> vesa_drv] bool handle_pci_port_write(short unsign ed int, T) [with T = long unsigned int]: accessing unknown PCI device 10 [init -> vesa_drv] int Framebuffer_drv::set_mode(long unsigned int, long unsigned int, l ong unsigned int): FB phys at 0x81000000 size: 0x003d0000 [init -> nitpicker] fra mebuffer is 1024x768@...23... [init] nitpicker registered service Nitpicker -- Sven FÃ¼lster

2 2

Early memory allocation
by mx＠...19... 07 Jul '09

07 Jul '09

Hi all, first of all thank you Christian for the quick bugfix concerning the dde/usb makefile. This time, I have a question related to the allocation of memory during system startup. At the moment, I'm just working with qemu/ l4ka-pistachio, and I've noticed that the initial memory allcation ("Trying to allocate 4K pages from sigma0") requests over 100MB, and this allocation takes about 3 seconds on my machine (without kqemu acceleration). In core/platform.cc I saw, that you ask sigma0 for the entire amount of memory it has concerning this page size and that you also memset the returned memory to zero. When playing around with that, I saw that omitting the zeroing does not seem to have any impact on the running system (I only have a dde driver running...). I also saw that I may - for a start - limit the memory allocation to a much smaller size. This involved a much better startup performance. So I wonder why the zeroing is needed, and I'd like to know if your memory management allowed for subsequent allocations from sigma0, so that I could save some startup time and allocate the remaining memory later. (Is this question - from your point of view - worth the investigation at all? Or is the delay only related to my slow qemu having no impact on an average hardware?) Thanx in advance Sven -- Sven Fülster

3 5

Genode/ l4ka-pistachio build error
by mx＠...19... 17 Jun '09

17 Jun '09

Hi all, I've tried to build the genode framework for the l4ka-pistachio kernel using your 4.2.4 cross toolchain. When building the dde-usbhid driver (test-dde_linux26_usbhid / REPOSITORIES += ../linux_drivers), the compiler throws a linktime error: Program test-dde_linux26_usbhid COMPILE main.o LINK test-dde_linux26_usbhid ./dde_linux26-arch.lib.a(dde_linux26-arch_dummies.o): In function `add_input_randomness': /home/krebserregend/genode/linux_drivers/src/lib/dde_linux26/arch/dde_kit/dummie s.c:15: multiple definition of `add_input_randomness' ./dde_linux26-drivers.lib.a(dde_linux26-drivers_random.o):/home/krebserregend/ge node/linux_drivers/src/linux26/drivers/char/random.c:636: first defined here ./dde_linux26-drivers.lib.a(dde_linux26-drivers_random.o): In function `random_write': random.c:(.text+0x11e2): undefined reference to `__mark_inode_dirty' ./dde_linux26-drivers.lib.a(dde_linux26-drivers_random.o): In function `secure_ip_id': random.c:(.text+0x1231): undefined reference to `half_md4_transform' ./dde_linux26-drivers.lib.a(dde_linux26-drivers_random.o): In function `random_read': random.c:(.text+0x1484): undefined reference to `touch_atime' collect2: ld returned 1 exit status make[2]: *** [/home/krebserregend/genode/build.pistachio_x86/test/dde_linux26_usbhid/test-dde _linux26_usbhid] Error 1 make[1]: *** [single_target] Error 2 make: *** [.] Error 2 Is there perhaps anything missing in my host OS (Ubuntu 9.04)? Cheers Sven

2 1

Re: newbie questions
by ross mcginnis 11 Jun '09

11 Jun '09

Thank you Norman very much answering all my questions. > >> 1- Is there anyway that a child can be endowed with any extra >> capabilities to server services at creation by its parent?.... > > At start time of a new child, the parent provides the child with > only one capability that we call parent capability. ..... Do you see > the need to statically preconfigure the environment of a child with a > set of capabilities? > No, I don't see any need for the parent to be able endow a set of capabilities at creation. (I was just checking to see that I understood the new child creation process properly. Some other cap theory and projects websites I've previously looked at mention or have endowment at creation so was wondering if genode could do this as well) >> 2- In the documentation it says that the parent of a server ... > > In fact, it is just a decision of the parent to keep the root > capability. A root capability could be transferred to another protection > domain via IPC just like any other capability. ..... Then however, RAM allocations are not anymore > individually accountable to those processes. > Thanks for clearing this up for me. I did wonder a bit about the memory quota sharing implications and thought that there might be problems like you've outlined. > Just out of curiosity, do you see a practical case for sharing a root > capability among multiple processes? No, I don't. (Please note though that I don't think I'm in a position to give much opinion cause I've only just started learning about genode- also I'm only a amateur/hobbyist so my opinions don't count for much sorry) > >> 3- The documentation mentions the use of unix file permissions. .... > > The use of UNIX file permissions .... In fact, we do not plan to introduce > UNIX file permissions into the base framework of Genode..... > I'm very happy/relieved to here this :) (As a suggestion -although from an amateur- perhaps you should specifically mention that ACL's/unix file permissions are not intrinsic to genode nor are they planned to be. Because on first pass reading I go the impression that the file permissions might be planned although it is a cap based system-- and I was reading it from the perspective of someone familiar with cap theory and knows the difference between caps and ACLs. I feel that if someone who read this wasn't already familiar cap OSes and all they knew were traditional ACL systems then they would assume that the file permissions are indeed already present and necessarily intrinsic.) > Right now, Genode creates the capability network dynamically at the > system's boot time according to the policy of each involved parent. So > there is no central ACL but the policy is distributed among all nodes > that play a parent role. This approach neither requires persistency nor > a statically configured ACL. ..... > This sound very interesting! Thanks once again for answering, but if you don't mind can I bother you with just few more last questions: A: Two questions regarding the interfaces between parent and child- 1) How does a server to signal to the client that it will need/does need more quota. (The interface methods given in the "Interfaces and Mechanisms" document allows a client to give quota to a server, but hows does the client know when and how much it needs to give?) 2)Are the session request strings expected to follow a format and naming standard for common types of services? B:Other questions- 1)Do you eventually intend to formally verify the software? (I believe the NICTA /OK-labs L4 kernel that genode can target is in the process of being verified and was wondering if you will likewise wish to verify genode to supply a fully mathematically verified framework for building OS personalities on). Lastly, I re-read the "Interfaces and Mechanisms" and I think I've found another minor error- in the section "Quota" in the sentence "Once, the server requests to close the session, the child is responsible to release all resources that were used for this session.". Aren't the words "server" and "child" meant to be swaped around here? Thanks Ross McGinnis _________________________________________________________________ Get the latest news, goss and sport Make ninemsn your homepage! http://windowslive.ninemsn.com.au/article.aspx?id=813730

2 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users