Design review for Native File system support - ext2

Josef Söntgen josef.soentgen at ...1...
Wed May 13 12:44:14 CEST 2015

Hallo Janani,

* Janani k <3moonu3 at ...9...> [2015-05-13 04:36:14 +0530]:
> > It would make reviewing the code easier for us if
> > you could provide the whole patch-set as a structured series of commits
> > in a git repository instead of a patch file that has to be applied
> > manually.
> I dint get this point clearly. You want the repository online or all the
> patches of commits ?

To be honest I would prefer if I could simply add a remote git repo
but that's just lazy me ☺. Since we use github to coordinate the
development of Genode it is easier for us if contributors do that as
well and is therefore the advised procedure. As a bonus we can also
follow the development more closely. In any case, I am fine with a
series of patch files that are somewhat structured, like one for your
Ext2 implementation, one for incorporating it into the File_system
session component and so on.

> > Also, although incorporating your work directly into dde_rump
> > makes it easier for you to test the implementation it makes it more
> > cumbersome for us to follow the process (especially in this case where
> > the interesting bits are missing). For example, putting the functions
> > for reading and write chunks from a block device into the File_system
> > namespace is questionable and the reason for doing so is not clear.
> Yeah I got the point. I am trying to move this entire thing to new folder
> but till then I will continue developing in dde_rump as it makes little
> bit easier for testing ext2 functionality. Regarding keeping block device
> I/O in filesystem was intended because at later point we could plugin 
> other filesystems like ext3 or ext4. So this genode implementation of
> front end can be used directly. And especially in Filesystem namespace
> because the arguments and function implementation are tailored for
> Filesystems and they cant be used else where.

I see, thanks for explaining your reasoning. Well, at a later stage it
might be desirable to provide the Ext2 implementation as a library so
other components (e.g. fsck or mkfs) can utilize it. So making it
stand-alone, albeit being currently located in the fs server source
directory, is reasonable and the way it taps into the Block_session
backend is okay for now.

> > That being said, I think you are on the right track by seperating
> > the code handling the Ext2 processing from the File_system session
> > frontend. For the time being I would post-pone reviewing your work in
> > more detail and I would really appreciate it if you would clean up
> > your code a bit.
> Yeah I am cleaning up the code and thanks for reviewing the design part.
> And for a quick testing I could attach make a final patch with all source
> and headers included.

Thanks for taking the time to clean the code up, I am looking forward
to it!

> Can you please specify what step to take next.

I am afraid that is hard to do because it is not clear to me what your
actual goal here is. I guess you want to contribute your Ext2 fs server
to Genode in the end?


More information about the users mailing list