Using a real harddisk

Sebastian Sumpf Sebastian.Sumpf at ...1...
Wed May 14 22:06:25 CEST 2014


Hi again,

On 05/14/2014 09:27 PM, w_schmidt at ...181... wrote:
> Hi,
> 
> Thanks for the answer.
> 
>>> I want to access files from a harddisk using a block cache. The partition
>>> would be /sda7/test in ext2 format. (and for example file1.txt) I tried 
>>> to
>>> start nova directly form disc - works with mouse & keyboard now.
> 
>> Assuming your machine is an x86 derivative and supports AHCI, you could
>> use Genode's AHCI driver, which will expose a block sesssion (see:
>> os/src/drivers/ahci/README). In order to access the partitions on your
>> disk, a server called 'part_blk' is required (see:
>> os/src/server/part_blk/README for its configuration). So, you would have
>> to remove 'ram_blk' and add 'ahci_drv', 'part_blk' (routed to
>> 'ahci_drv'), adjust 'rump_fs' to be routed to 'part_blk' partition 7.
> 
> I have 2 possible machines with AHCI and AMD64/Intel64.
> 
> Maybe I understand it completly wrong, but in the AHCI description there is 
> a part with
> "On real hardware and on kernels taking advantage of I/O APICs (namely NOVA 
> and
> Fiasco.OC) we still lack support for ACPI parsing and thus for interrupts,
> leading to a non-working driver." ( 
> https://github.com/genodelabs/genode/blob/master/repos/os/src/drivers/ahci/README 
>  )
> 
> Doesn't that mean that the AHCI driver won't work with nova or real hard 
> drive? That sentence is one of the reasons why I ask.
> If nova /real hardware does not work like mentioned in the readme, is there 
> another way to load from disc? Or should another kernel (?L4k?) do the 
> trick?

Ops, I should take this part out of the README. We do have ACPI parsing
and interrupt re-write support by now. You will need to build
'drivers/acpi', 'drivers/pci', and if you use NOVA and if your machine
has an IOMMU 'drivers/pci/device_pd'. In the Genode configuration you
only need to start the 'acpi_drv', which will start the other one or two
as children. A sample run script can be found under 'os/run/ahci.run'

Another way to access hard disks (again on x86) is to use the IDE
interface, which is supported by the ATAPI driver ('drivers/atapi'),
again have a look at the README in 'os/drivers/atapi'.

>> The cache is greedy and tries to get as much memory from its parent as
>> possible. By the way, rump has a build in block cache also.
> 
> Yes I have seen that in the rump description there stood something that the 
> server will use most of the RAM for cache.
> 
> I thought I coudl do the following:
> Give the block cache e.g. 16MB RAM.
> Give the Rump Server 6 MB, and load different 4 MB files. I thought that by 
> loading the second file the first one will get out of the Rump cache but 
> loaded by the block cache.

Okay that should work, I would give rump a little more memory.

> I have seen that the framebuffer seems to have a sort of multiplexer. Is 
> something similiar available for filesystems?

The rump server supports connections from multiple clients, so one could
see it as sort of a multiplexer.

>>> RAM...
>> I think the author just did not want to calculate the amount of RAM
>> required for the test program.
> 
> O.K.
> 
>>> Afterwards i included in the set build_components section 
>>> server/blk_cache
>>> (after drivers/timer) and entered as boot module blk_cache.  Is this the
>>> correct way of including the cache?
> 
>> Yes it is!
> 
> Good. :-)
> 
>>> The result of this was that I got an output with: [init -> blk_cache]
>>> updating quota for SIGNAL session, an init rump_fs upgrade quota output 
>>> and
>>> afterwards and a long stop after init->rump_fs Backend::Backend() Backend
>>> blk_size 512 Afterwards the script stopped with   Test execution timeout.
>>> with error 254) What could I have done wrong with the configuration of 
>>> this
>>> scenario?
> 
>> Ok, I will try to reproduce the behavior.
> 
> Thanks, that would be interesting. If it helps I can upload my configuration 
> file somewhere?

I will try it out first as described above, if I cannot reproduce it you
could fork Genode on GitHub and push it into a branch there, or if it is
just a run script just send it via email.

> I think I can try file access and AHCI first on friday (ATM a lot of work, 
> I'm interested at genode because of part time study)

Good luck!

Sebastian


-- 
Sebastian Sumpf
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth







More information about the users mailing list