Hi Michael, I'm CC'ing uml-devel as the discussion is very relevant and could be interesting for everybody.
On Wed, Sep 22, 2010 at 23:13, Michael Richardson <m...@sandelman.ca> wrote: >>>>>> "Paolo" == Paolo Giarrusso <blaisorbl...@yahoo.it> writes: > Any idea where to send patches/git-tree pull requests. > 2.6.31 still works, 2.6.35 core dumps. > I haven't bisected yet. I was writing GRE-over-IPv6 code. I've seen stuff on the UML MLs, but I believe you should send maybe them directly upstream. Which means "send patches to Andrew Morton/LKML in mail format (Andrew doesn't use Git)". My belief is that only subsystem maintainers can send pull requests, because maintainers are more "trusted" - we never used that, always send emails upstream. I recommend sending to Andrew Morton because he used not to silently drop patches, even because he can merge them into -mm even if they are not ready for inclusion. Which helps anyway even if your patch is ready - that's my personal experience (that's why I got UML updates merged in 2.6.9, while sending to Linus had stopped working for us) and it does not seems that things changed. Beyond that, Documentation/SubmittingPatches still applies. Which means that you have to CC Jeff Dike, since he's still listed in MAINTAINERS. Even if he doesn't answer, it's important for Andrew Morton: you are giving Jeff the opportunity to say "No" if he thinks you really made some mistake. > No other VM system is as light weight, and supports hostfs-style usage. > (yeah, you can use NFS, but that sucks if you are doing work > tinkering...) Please share these thoughts upstream, even on LKML - somebody might actually realize that these properties are interesting to users, realize there is a "market", and fill the need. Miklos Srezedi and Anton Altaparmakov, working on FUSE and NTFS, kept using UML for a long time - that has to mean something, right? KVM seems to target process-style usage (while relying on HW extensions, OK), and at least VirtualBox, VMWare and so on provides some "shared folders" facility, which seems hostfs-like. It would _maybe_ make sense to rewrite some "SKAS0-like" operation mode for KVM, since they have the most similar philosophy, but with a codebase generally in better shape, and I believe they have less driver code to maintain, since they reuse pieces of QEMU. And rewriting UML from the ground up (no offense intended) could anyway make sense, to reevaluate some design decisions. - On the one hand, nowadays I think that you can't speed up something as much as needed and keep it stable; you better start from the core (most common operations), optimize it down to the last bit, and then add the rest on top. I wrote the core of a small Python interpreter this way for a student project, and the results are beyond expectation. - On the other hand, having as few UML drivers as possible is also a very good idea - simply fixing the locking of those drivers was complicated, I couldn't finish it (but rewriting them using Linux Device Drivers could have been faster). To eventually speed up SKAS0, _after_ there is any "SKAS0" code at all in KVM, we had some ideas, very little manpower to implement them, and some old proof-of-concept by Ingo Molnar. I'll (slowly) elaborate on them in detail if you get the interest of KVM developers and _then_ CC me, but I won't make the effort to contact them first as my lack of time is too huge. Best regards -- Paolo Giarrusso - Ph.D. Student http://www.informatik.uni-marburg.de/~pgiarrusso/ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel