[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1/2])
> > OK, it's not a very cunning hack to do but it makes the blkback driver > > more complex whilst duplicating functionality that's already in the > > kernel. You'd have to deal with a load of VFS APIs as well as the > > existing block APIs, which would be unfortunate. > > Maybe reuse the loopback code? Maybe it has an abstract device->file > conversion group of functions/structures. Arguably the ideal in-kernel solution is to fix the loopback driver itself. > > Does anybody know why the existing loopback device performs badly anyway? > > As Adam says, it shouldn't be rocket science to make it work well... > > Default kernel limit of 8 loops. Requires a recompile, and then probably > only supports 256 devices max. Yup the default limit could (arguably) be raised in our default config. I was especially referring to the performance, which is reported to be rather bad. > > > blktap? Is that similiar to what I described above? > > > > Blktap allows you to write a userspace program to provide a block device > > to another domain. It makes what you described a bit more > > straightforward than implementing directly in the blkback driver. > > That would be more complex I would think then doing file access in the > kernel. I'm not sure it would, the blocktap library is designed for this sort of thing. From what Andy says there is actually already a tool to do it, which might be worth investigating further. Cheers, Mark _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |