Hallo Janani, * Janani k <3moo...@gmail.com> [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? Regards Josef ------------------------------------------------------------------------------ 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. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main