On 30/07/14 10:58, Justin Cormack wrote: > On Jul 30, 2014 10:44 AM, <[email protected]> wrote: >> >>> On Tuesday, July 29, 2014 9:28:53 PM UTC+2, [email protected] wrote: >>>> Are you sure rump is actually suitable for handling file systems? >>>> Did anybody write such kind of shim as a proof of concept? >> >> On Tue, Jul 29, 2014 at 01:24:04PM -0700, Ben Gras wrote: >>> yes - http://www.netbsd.org/~stacktic/ebc09_fs-utils_paper.pdf >> >> Thanks, actually I was aware of this paper. >> >> Yes it is quite straightforward to replace the open/read/... layer with >> calls to the filesystem code, ignoring any issues of handling access >> rights or concurrent access by multiple parties. >> >> The omitted functionality is nevertheless vital and is the duty of the >> coordinating kernel. I am not sure that the involved primitives in the >> NetBSD and Minix kernels correspond to each other (not sufficiently >> conversant with either).
Just to clarify to others on the list(s), redirecting calls directly to the file system code is not what fs-utils does, nor does it ignore concurrency or permissions. That said, given that fs-utils are userspace applications, the efforts of not ignoring permissions or concurrency is like that of qemu guests not ignoring them. fs-utils still makes "system calls", except those system calls are handled by a rump kernel, not the host kernel. When you run e.g. fsu_ls -l, there's a full cycle of mount + getdents + stat + unmount. fs-utils is very convenient for accessing file system images, but it's not the approach you'd want for a file server. For the "file server & rump kernel" topic, look at p2k for inspiration: http://netbsd.gw.com/cgi-bin/man-cgi?p2k++NetBSD-current With p2k, the requests are received at the file system layer and calls into the rump kernel are made directly into the file system code. As a side note, I disagree that it's simple to replace calls in standard file system utilities with calls directly to file system code. I tried to do it many years ago, and the code was riddled with subtle bugs, so I had to find a better way to do it. That better way was to include the system call layer in rump kernels for clients to optionally call, upon which Arnaud eventually built fs-utils. There are a lot of seemingly innocent details between a syscall and the file system, all of which you need to handle 100% correctly if you want real applications to work. >> The file system internals layer and the VFS layer assume an OS-specific >> interface in between and it looks like we would have to connect one of >> NetBSD with the other of Minix. Are they compatible? Not a proof, but given that: 1) rump kernels can run as file servers on top of puffs on NetBSD (p2k) 2) Minix supports puffs (at least in some form, I don't know details) I'd say there's at least a good chance of them being somewhat compatible. That's not to say that I guarantee that an actual attempt will not run into any issues, just that it's not foreseeably doomed from the start. > I work on rump kernel development and happy to help. The VFS and IP stack > interfaces are pretty simple in rump - you just need a block device type > interface for file systems and an interface to write Ethernet frames for > the IP stack. These are good places to start. Yes, they are just a handful of lines of code. But you also need rump kernels to run at all on your platform, which is an even better place to start ;) (and not that many lines of code either) - antti p.s. this mail wasn't about USB or release script fixes, not 100% sure what the subject really is or if I'm talking completely out-of-topic ... ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
