Design review for Native File system support - ext2
3moonu3 at ...9...
Wed May 13 01:06:14 CEST 2015
On Mon, May 11, 2015 at 7:49 PM, Josef Söntgen <
josef.soentgen at ...1...> wrote:
> Hello Janani,
> * Janani k <3moonu3 at ...9...> [2015-05-10 16:32:49 +0530]:
> > I am trying to port an existing native file-system(ext2) to Genode. So, I
> > started porting this in the same place as rump_ext2 so that this can be
> > up fast to get quick running of the code. I designed it so as to call our
> > native implementation calls instead of rump calls. To get the block
> > sessions working and basic ext2 functionalities checking, I did quick
> > work to get it up and running. Sorry didn't follow the
> > Genode specifications in coding. I want get suggestions & feedback's on
> > this design and then I will align code to Genode specifications and move
> > further. I am attaching the patch file. And I will list out major things
> > did in this work to give an overview.
> I toke a brief look and also tried to build your code. Sadly, I am not
> able to compile it because a few source and header files are missing
> from your patch file.
Sorry the patch file missed some of the source and header files as they
were not added during development. And forgot to include in final patch.
I added all files now and have a final patch.
> 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
I dint get this point clearly. You want the repository online or all the
of commits ?
> 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
functionality. Regarding keeping block device I/O in filesystem was
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
namespace because the arguments and function implementation are tailored
Filesystems and they cant be used else where.
> 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
Can you please specify what step to take next.
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> genode-main mailing list
> genode-main at lists.sourceforge.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users