search for: uncontroversi

I think this patch is also uncontroversial. If selinux=1 then we mount /selinux in the appliance. We also bind-mount it into guests when running commands, just like we do for /proc, /dev etc. If SELinux is disabled, then /selinux doesn't get mounted. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~r...

...: 1. Allow SCCIterator to work with GraphT types that are constant. 2. Allow SCCIterator to work with inverse graphs. 3. Fix an incorrect comment in GraphTraits.h (the type in the comment was given as GraphType* when it is actually const GraphType &). I think these changes should be pretty uncontroversial. Would someone with commit authority please apply this for me? --Patrick Index: include/llvm/ADT/SCCIterator.h =================================================================== --- include/llvm/ADT/SCCIterator.h (revision 88920) +++ include/llvm/ADT/SCCIterator.h (working copy) @@...

Hi, I was trying to migrate some VM's to Virtio-SCSI block devices, as this gives some advantages. While checking the virt-v2v code, I found out that it supported Virtio-SCSI, but some bits were missing. In attachment a small patch that adds the missing bits :) Best regards Jean-Louis

...line flag or so (for now). > > - - - > > I think this patch as it stands has two problems: > > (a) It should be split up into 3 patches. > > Patch #1 would contain the change to v2v/linux_kernels.mli and > v2v/linux_kernels.ml. IMHO this patch #1 would be completely > uncontroversial and would go straight upstream. > > Patch #2 would contain the change to v2v/create_ovf.ml, and is also > uncontroversial and ready to go upstream (but as a separate change > from patch #1). But then you end up in a situation like the code is now. In some places Virtio_SCSI is added a...

...last few months and also given some of the recent changes to various backends to "update" the default tunings for a generic processor it made me think again about adding support for tuning to a processor rather than generating processor specific code - hence, mtune. I hope this is rather uncontroversial, but happy to discuss at length if anyone thinks we shouldn't add this functionality to the compiler. That said, I have a bit of a strawman outline for what I think needs to happen in general, and while I don't have any concrete plans to attack this soon I thought I'd post it in case...

Hi Patrick, > I think these changes should be pretty uncontroversial. Would someone > with commit authority please apply this for me? thanks for the patch. Applied in commit 89091. Ciao, Duncan.

I'm happy to announce that I've added Roman Kagan as a committer to the https://github.com/libguestfs/libguestfs repo. Roman has contributed many high quality patches over a period of one year. Roman, the rules are: - Post patches first on the mailing list. - Uncontroversial patches should receive one ACK before being pushed upstream. - Very complex or "controversial" changes should get two ACKs and general agreement before being pushed upstream. Thank you for your contributions to the project, Rich. -- Richard Jones, Virtualization Group, Red H...

As we discussed on IRC, patch 1 is obvious and uncontroversial, let's do it. I think patch 2 is overkill really, and weird pointer tricks have a habit of breaking on big endian / 32 bit / obscure platforms. Why don't we just create a brand new filter API number (6 I think), reject everything with API != 6, and as a further test verify that strcmp (...

...morning :-) I'm definitely looking forward also to the SMP changes. - - - I think this patch as it stands has two problems: (a) It should be split up into 3 patches. Patch #1 would contain the change to v2v/linux_kernels.mli and v2v/linux_kernels.ml. IMHO this patch #1 would be completely uncontroversial and would go straight upstream. Patch #2 would contain the change to v2v/create_ovf.ml, and is also uncontroversial and ready to go upstream (but as a separate change from patch #1). (b) Now the problem is patch #3: > diff --git a/v2v/convert_linux.ml b/v2v/convert_linux.ml > index a871d...

These patches provide the infrastructure for paravirtualized MMU operations while at the same time cleaning up and optimizing the pagetable accessors for i386. They should be largely uncontroversial and are well tested. There are still some performance gains to be had for paravirtualization, but it is more important to get the native code base that will enable them checked in first. Zach

This is a pretty uncontroversial patch which just allows the selinux=? and enforcing=? flags on the kernel command line to be controlled. Currently libguestfs unconditionally passes selinux=0. By default this patch does the same thing, but allows programs to enable SELinux in the kernel and/or set it to enforcing mode. Rich....

These patches provide the infrastructure for paravirtualized MMU operations while at the same time cleaning up and optimizing the pagetable accessors for i386. They should be largely uncontroversial and are well tested. There are still some performance gains to be had for paravirtualization, but it is more important to get the native code base that will enable them checked in first. Zach

...is feature (COFF for the moment, but maybe ELF one day as an optimization), LLVM will emit the appropriate comdat bits so that the system linker behaves similarly. On platforms lacking this support, the old behavior will be used, in which case guard variables are still necessary. This seems fairly uncontroversial, but let me know if anyone objects. I'll try to send patches later this week. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130826/30ed914b/attachment.html>

...moment, but maybe ELF one day as > an optimization), LLVM will emit the appropriate comdat bits so that the system > linker behaves similarly. On platforms lacking this support, the old behavior > will be used, in which case guard variables are still necessary. > > This seems fairly uncontroversial, but let me know if anyone objects. I'll try > to send patches later this week. > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmde...

Hi, several of the patches I submitted last week have not yet been applied, and most of it was really uncontroversial stuff like adding some #includes and some typecasts, fixing alloca for visual C etc. I guess I just wrote too many mails so it was lost in the process, so here is a diff which includes all changes I have made, except those related to hash_map differences since my solution here is just too ugl...

...I would need to actually see the trace output and the lsof output. See what I wrote here: https://www.redhat.com/archives/libguestfs/2014-July/msg00051.html > + p_part_num: int; (* partition number *) I think you should split out this change into a separate patch. It's uncontroversial to keep p_part_num in the structure, and will simplify review of the patch. > + mutable p_partitions : partition list; (* MBR logical partitions. Non-empty > + list implies extended partition I'm very unclear about this change to the struct...

...> an optimization), LLVM will emit the appropriate comdat bits so that the >> system >> linker behaves similarly. On platforms lacking this support, the old >> behavior >> will be used, in which case guard variables are still necessary. >> >> This seems fairly uncontroversial, but let me know if anyone objects. >> I'll try >> to send patches later this week. >> >> >> ______________________________**_________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://li...

Hi all, I have a distribution, and take a sample of it. Then I compare that sample with the mean of the population like here in "Wilcoxon signed rank test with continuity correction": > wilcox.test(Sample,mu=mean(All), alt="two.sided") Wilcoxon signed rank test with continuity correction data: AlphaNoteOnsetDists V = 63855, p-value = 0.0002093 alternative hypothesis:

Here''s a question for those well-versed in rforum or engines -- or both, ideally :) I''ve spent some time today turning RForum into an engine, using rails 1.0, engines trunk, and rforum 0.1 (as rforum trunk didn''t appear to work out of the box). My rforum engine works, but only when I do two things that I found by trial and error: 1) All rforum controllers subclass

...ing old binaries) and a lot of new > high-level passes (LoopVectorisationAnalysis) which will need a long > review on their own before we even start thinking about SVE. > > I recommend you guys separate the refactoring from the implementation > and try to upstream the initial and uncontroversial refactorings (name > changes, etc), as well as move out the current functionality into new > passes, so then you can extend for SVE as a refactoring, not > move-and-extend in the same pass. So our highest priority is getting basic support for SVE into the codebase (types, codegen, as...