==+== FAST '09 Paper Review Form
==-== Set the paper number and fill out lettered sections A through G.
==-== DO NOT CHANGE LINES THAT START WITH ”==+==”!
==+== RAJU MUST REPLACE THIS LINE BEFORE UPLOADING
==+== Begin Review
==+== Paper #19
==-== Replace '000000' with the actual paper number.
==+== Review Readiness
==-== Enter “Ready” here if the review is ready for others to see:
Ready
==+== A. Overall merit
==-== Enter a number from 1 to 5.
==-== Choices: 1. Reject
==-== 2. Weak reject
==-== 3. Weak accept
==-== 4. Accept
==-== 5. Strong accept
4
==+== B. Novelty
==-== Enter a number from 1 to 5.
==-== Choices: 1. Published before
==-== 2. Done before (not necessarily published)
==-== 3. Incremental improvement
==-== 4. New contribution
==-== 5. Surprisingly new contribution
4
==+== C. Longevity
==-== How important will this work be over time?
==-== Enter a number from 1 to 5.
==-== Choices: 1. Not important now or later
==-== 2. Low importance
==-== 3. Average importance
==-== 4. Important
==-== 5. Exciting
4
==+== D. Reviewer expertise
==-== Enter a number from 1 to 4.
==-== Choices: 1. No familiarity
==-== 2. Some familiarity
==-== 3. Knowledgeable
==-== 4. Expert
3
==+== E. Paper summary
This paper presents the design and implementation of a framework (“rump”) capable of executing preexisting and heavily tested file filesystem kernel code in user-space. The authors have implemented this framework for the NetBSD operating system. The implementation offers all the kernel interfaces required for the filesystem code in order to execute at this level. The authors map all this interfaces to user-space libraries that simulate the normal behavior of the kernel. There are two ways of accessing this framework. The first one allows an application to access the library that make filesystem calls to the underlying disk. The second option offers the use of puffs (similar to FUSE but for NetBSD) to mount the file system at the kernel level but execute the filesystem code in user space. The major benefits of this work are attributed as stronger security guarantees in case of mounting corrupted file-systems, reuse of available kernel code in developing applications which require file system repair and image access.
==+== F. Comments for author
The authors take an interesting idea (running existing kernel file system code in user-space) and explore it fairly completely. A substantial implementation (already included in the NetBSD operating system) is another strong point. The paper is fairly well written, though there are improvements (as suggested below) that can be made.
The framework proposed offers some new advantages like:
- access to a filesystem whose implementation is not offered by the kernel in use
- possible simplification of porting file systems across
- simplied development and testing environment for new in-kernel file systems
- reuse of file system code in user-level file system tools
- improved reliability with modularity by embracing the micro-kernel approach.
Some comments for improvement follow:
I would recommend the authors to explore the motivating reasons for their work in more detail in favor of the involved details of their implementation. This would go much farther in increasing the impact of this work in the research community.
Similarly, it is much more important for readers to understand the key ideas that were used in recreating kernel abstractions in user-space. This only appears in Section 3.2 briefly.
Further, it would be more informative if details such as the differences in developing such a framework for NetBSD vs. Linux due to their respective designs. Are there some fundamental OS constructs that cannot be emulated in user-space w.r.t. file systems in kernel?
Another area of improvement is more systematically expand fully and classify the support functions listed in Figure 2 (e.g. along the dimensions of threading, timing, disk, etc. and provide examples in each class). This will help the reader understand the various classes of concerns. Additional details are also called for about how environment independent modules (to directly include in rump) would be identified.
Finally, as a general comment, it is important to explain some of the figures further. For example, I do not understand the purpose of Figure 5, What is the dashed line? fork() + exec()?. Moreover, Figure 1 could be improved by adding the information of what component ends up comunicating with the disk as well as adding in where rumpuser and rumpkern fit into this picture.
Minor Comments/Edits:
1) In page 7, check the sentence “The results is the ability run binary…..”
2) In page 4, change “..emulates the kernel proper.” → “..emulates the kernel properly.”
3) In page 10, I believe the statement “the FAT implementation does not use synchronous writes as heavily, and therefore the speed disfference is much more modest.” must be revisited given that %-wise the difference is around 17% vs. 19%.
4) In page 12, “an a translator” → “a translator”
5) “Chapter” → “Section” (multiple places).
6) In page 3, “some certain” → “certain”
7) In page 3, The following sentence construction is very awkward : “The ABI of the library is regrettably currently not precisely ….”
==+== G. Comments for PC (hidden from authors)
[Enter your comments here]
==+== End Review