On 21/10/14 08:19, Martin Lucina wrote: > [better control for block device limitations] > > There are three approaches to how this could be done in the rump_etfs API: > > 1) Change the ftype argument to a bitmask and include RUMP_O_XXXX as > possible flags. This is the minimal API change, but not very pretty. > > 2) Add a oflags argument to rump_pub_etfs_register. > > 3) Add a new API where instead of hostpath the caller passes in an existing > file descriptor. This seems like the most flexible approach. > > What do you think?
Humh, well, the problem is certainly valid. Your "3" proposal seems like an adequate quick solution. Though, it doesn't make a whole lot of sense for platforms without file descriptors (e.g. Xen blkfront). therefore ... I've been wanting to revamp the "virtual" block device interface and code a bit more. For example, currently it's not possible to use more than one block device. Example: assume you want to choose between an aio backend and read/write backend. For network interfaces this already works: you can have for example a dpdk interface and a netmap interface in the same rump kernel and send some traffic out of one and other traffic out of a another. So, if you want a hobby in addition to a solution, the above is something I'd like to fix (or see fixed). Per minimum, it requires rethinking the rump_pub_etfs API. I'm not sure the magical invisible devices created by rump_etfs are the best possible idea... After all, I think the block device code in rump kernels got rewritten over the years only once, and I think etfs got no rewrites. That's pretty exceptional in rump kernel context ;) > This is something we could do on the hackathon in November, if I don't get > to it before. Yes, definitely, we're holding the hackathon exactly for things like this. ------------------------------------------------------------------------------ Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
