search for: retrofit

I am seeking advice. In your estimation, how difficult would it be to retrofit LLVM 3.2 with this body of improvements to instruction scheduling (and optionally, the loop vectorization as well). Would you have any suggestions for how best this might be achieved, i.e. the scope of the code required? Has anyone attempted this kind of retrofit? Thanks, Rick ---------...

Previously I had asked how to write then read back IR to/from a file. The write code looked like: LLVMContext ctx; SMDiagnostic diag; Module *m = ParseIRFile( "my_file", diag, ctx ); However, the code I'm trying to retrofit LLVM IR into passes me just a std::ostream&. How can I read IR from a std::ostream? I figured out how to use raw_os_ostream to adapt a std::ostream to a raw_ostream for writing a module, but there's no obvious way to adapt the code for reading, e.g., no MemoryBuffer that adapts a std::ost...

Hey all - does RHES4/CentOS4 beta contain a recent integration of Subversion? I've been holding off trying to retro-fit CentOS 3.x on our CVS server, hoping that the official channels aready had it in store for the future. Not that you *can't* retrofit, I was just uncomfortable upgrading so many stock packages. Anyone have it installed, can take a look for me? thx, -te -- Troy Engel | Systems Engineer Fluid, Inc | http://www.fluid.com

Hi, we are experiencing significant performance degradation after live migration of hvm domains in Xen 4.0 (SLES11 SP1): after live migration the performance is dropping to less than 90%. I did a backport of cs 23420-23423 and the performance is okay now. I would like to request to include these changesets in 4.0 and 4.1. The backport is quite trivial, I can send patches if you are willing to

On Wed, 2017-06-07 at 11:23 -0500, Johnny Hughes wrote: > If you want to create a CentOS-7 variant that does not use systemd, > then start a Special Interest Group and create modified packages > to use something else instead ......., much like the this group did > with Debian: > > https://devuan.org/ > > In the case of CentOS-7 .. you don't need to create a whole new

So when puppetd crashes/whatever, and a pid file is left behind, SMF in Solaris will try restarting puppet, but fail. And then it sits there restarting it forever. I''m not sure if I can adjust the flap detection in SMF.. it isn''t disabling the service for "restarting too quickly" because it takes so long to start. Probably because I''m NFS-mounting ruby. The

...S Project controlled >> resources to build packages (and get them rolled into our mirrors, >> etc.) to use something other than systemd. > Excellent idea. I'll gladly sign any such petition:-) but will you contribute to building the non-systemd packages, and working out how to retrofit old sysV init back into everything via patches, etc ? every RPM that interacts with systemd will need to be 'fixed' to do it the old way, with init.d scripts. repositories like postgres, EPEL, etc won't work, either, as their C7 packaged daemons are all configured to use systemd....

I just downloaded and installed the source to 2.0.5a, and it worked perfectly. I really like the fact that everything by default goes under /usr/local/samba (I just did the ./configure; make; make install). The one thing I don't see is the start/stop/restart commands like I used to have in my Red Hat rpm installation: /etc/rc.d/init.d/smb restart It was a shellscript to read the .pid files,

...t; resources to build packages (and get them rolled into our mirrors, >>> etc.) to use something other than systemd. >> Excellent idea. I'll gladly sign any such petition:-) > > > but will you contribute to building the non-systemd packages, and > working out how to retrofit old sysV init back into everything via > patches, etc ? every RPM that interacts with systemd will need to be > 'fixed' to do it the old way, with init.d scripts. repositories like > postgres, EPEL, etc won't work, either, as their C7 packaged daemons are > all configured...

...his whole discussion about using virtregs until emit or having growable physregs is hard to argue without actually having experience trying to go either way. Problems when using virtregs throughout the backend until emit time: - The MC layer is using MCPhysReg (which is an uint16_t) and would need retrofitting to support virtregs - VirtRegs are assumed to have a definition, physregs can appear "out of thin air" in some situations like function parameters, or exception objects appearing in a register when going to a landingpad. - VirtRegs are assumed to be interchangeable, replaceing vreg5 w...

On Tuesday, September 03, 2013 07:52:08 PM Richard W.M. Jones wrote: > Even better, there is a repo: https://github.com/mdbooth/guestconv Excellent. Thanks for the pointer. > Matt - can you push your latest commits, or is there a more canonical > repo that Mike can look at? The last changes in the repo seem to be from back in June. Is guestconv expected to completely replace virt-v2v

On Wed, Jan 25, 2017 at 08:42:34PM -0600, Eric Blake wrote: > +eg. NULL or -1. If the call to C<nbdkit_set_error> is omitted, then > +the value of C<errno> will be used instead. [...] > +/* Grab the appropriate error value. > + */ > +static int > +_get_error (void) > +{ > + int err = errno; > + int ret = tls_get_error (); > + > + if (!ret) > +

...converter with one of those solutions and we can discuss it further after it's posted. > You also mentioned the logging. Yes, logging is sparse in virt-v2v; it > will be better in guestconv. It's lame in virt-v2v because we didn't > consider it important early, and didn't retrofit it later. However, you > have to consider what the logging is for. If it's just for debugging, > nothing is likely to beat LIBGUESTFS_TRACE. LIBGUESTFS_TRACE is more than enough to monitor the conversion itself. I was specifically thinking a little higher level anyway. > I would ke...

On Wed, Nov 8, 2017 at 9:33 AM, Rafael Avila de Espindola < rafael.espindola at gmail.com> wrote: > Rui Ueyama <ruiu at google.com> writes: > > >> If you are creating an executable and if your executable is not > >> > position-independent, you're using Initial Exec model by default > which is > >> > as fast as variables accessed through

...gt; and an environment pointer. It is easy enough to call its entry point > and pass the environment pointer as an extra argument (rather like the > pointer to this or self in object-oriented code). It's no problem. The > trampoline intrinsic is a neat way of packaging this so as to retrofit > into C's one-address-only function pointer, but that's not necessary in > a language where procedures are all known to have this behaviour. > > The problem is with the go to statement. Again, local go to's, that go > somewhere within the same function are no particula...

...of the development release becomes sufficient then we will enter the Beta/Release Candidate Phase for the next even-numbered major release. I feel that this model will provide more stability for users who "just want it to work" while at the same time freeing me from having to quickly retrofit bug fixes (like the temporary file/directory vulnerability fix) into a release that is still getting the bugs worked out of new major functionality (like the iptables-save/iptables-restore integration). Comments? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shor...

On 2020-11-12, Alexander Yermolovich wrote: >Thanks for feedback. > >I agree with patch and numbers this will be a more concrete discussion, but I wanted to judge overall receptiveness to this approach and see maybe there was a better way. > >"Whilst the majority of objects will only have a single CU in them, there will be exceptions (LTO-generated objects, -r merged objects

...nking for DWARF you could encode the 64-bit/32-bit state in there, possibly the section variant (info/rnglists/line etc) and the DWARF version too), on the understanding that consumers like the linker wouldn't combine sections in a potentially broken way. This has the advantage that it could be retrofitted to the existing standard versions, but as has been pointed out, this won't help those with linker scripts - that could only be solved with a new DWARF standard and separate names for 64/32 bit sections, at least if we wanted to avoid the linker needing to do anything beyond reading the secti...

Hi all, I have an interesting one - Solaris uses a lot of commands to configure specific items. A simple example is coreadm. In this example: # coreadm -p "/var/core/core_%n_%f_%u_%g_%t_%p" will set the directory and filename to dump core files (with some expansion). The question is - how to get this to run only if the config has changed. I have come up with 2 options, neither of

...nking for DWARF you could encode the 64-bit/32-bit state in there, possibly the section variant (info/rnglists/line etc) and the DWARF version too), on the understanding that consumers like the linker wouldn't combine sections in a potentially broken way. This has the advantage that it could be retrofitted to the existing standard versions, but as has been pointed out, this won't help those with linker scripts - that could only be solved with a new DWARF standard and separate names for 64/32 bit sections, at least if we wanted to avoid the linker needing to do anything beyond reading the secti...