search for: pluggability

Hello, How feasible would it be to have a ?pluggable? Dovecot setup that would permit arbitrary logic for fetching TLS/SNI certificates and key, rather than having to hard-code each domain?s resources in a configuration file? A couple scenarios that I envision such a framework being able to accommodate: 1) An internal TLS service that accepts queries via a UNIX socket by domain name and

On Monday 20 August 2007 15:58, David A. Greene wrote: > Here's a proposed patch for reworking register coalescing to allow > pluggable coalescers. No comments? Or is everyone taking vacation before the fall? :) -Dave

On Wed, May 09, 2018 at 10:00:19AM +0100, Daniel P. Berrangé wrote: > On Wed, May 09, 2018 at 11:50:33AM +0300, Anastasiya Ruzhanskaya wrote: > > Here https://libvirt.org/acl.html is stated that you designed this access > > control system as pluggable. Are there any options ( even with modifying > > libvirt code) to plug in any custom driver? > > I just need to take a

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Reading the archives I see messages from a long (years) time ago discussing pluggable mailstores. No recent news, though. Any progress?. Current status? Regards - -- Jes?s Cea Avi?n _/_/ _/_/_/ _/_/_/ jcea at jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ Twitter: @jcea

Here's a proposed patch for reworking register coalescing to allow pluggable coalescers. I think I've got the interfaces where I want them and am reasonably sure I've squashed most of the bugs. I'm still doing some testing and want to get through a whole regimen before committing. As a reminder, this patch has several goals: - Allow user-specified register coalescers, similar

When I add the --with-pam option in my configure command I get the following error: checking for pam_start in -lpam... no configure: error: Can't build with PAM support: libpam not found PAM is most certainly installed on the machine: ii libpam-modules 0.79-5 Pluggable Authentication Modules for PAM ii libpam-runtime 0.79-5 Runtime support

Here https://libvirt.org/acl.html is stated that you designed this access control system as pluggable. Are there any options ( even with modifying libvirt code) to plug in any custom driver? I just need to take a try and design something that will support remote access control. I am not sure if sVirt is the right thing I should look at. 2018-05-09 11:27 GMT+03:00 Daniel P. Berrangé

Hi all, Greetings. I'm a Ph.D. student in UIUC. Now I'm working on SAFECode, a research compiler based on LLVM which insert necessary runtime checks to guarantee memory-safety of programs. SAFECode needs to insert checks into the programs (say, please check this load instruction for me). Currently SAFECode inserts these checks as normal call instructions. It would be great that LLVM can

Hi David, On Mon, 2007-07-09 at 16:32 -0500, David Greene wrote: > Ok, I'm at a point now where I can implement plyggable register coalescers as > we originally wanted when I started the refactoring work. > > I'm in the midst of finishing up an implementation following the model of how > register allocators are selected. Thgere may be some more refactoring/code >

On Wednesday 11 July 2007 12:41, Tanya M. Lattner wrote: > I think the coalescer should be flexible enough to be run independent of > the register allocator. For example, you may want to expose the copies > induced by transforming out of SSA to the scheduler. If the scheduler is > run before register allocation, then you would want the coalescing to > happen before as well. I

On Mon, 2007-07-16 at 16:19 -0700, Evan Cheng wrote: > Property changes on: llvm/include/llvm/CodeGen/RegisterAllocator.h > ___________________________________________________________________ > Name: svn:eol-style > + LF > > What's this? Its a property change. In Subversion every file and directory can have properties associated with them. For example the svn:ignore

On Jul 17, 2007, at 9:28 AM, David Greene wrote: > > [...] > 00369 // If the intervals were swapped by Join, swap them back so > that the > register > 00370 // mapping (in the r2i map) is correct. > 00371 if (Swapped) SrcInt.swap(DstInt); > > Whoops! At this point repSrcReg is not consistent with SrcInt and the > same goes for repDstReg! > > 00372

On Monday 27 August 2007 19:02, Evan Cheng wrote: > > interfere() isn't sufficient because the allocation algorithm may > > place other > > constraints on coalescing. George and Appel's iterated register > > coalescing > > is a prime example. It wants to "freeze" copies that should not be > > coalesced > > because doing so might cause

On Aug 28, 2007, at 8:59 AM, David Greene wrote: > On Monday 27 August 2007 19:02, Evan Cheng wrote: > >>> interfere() isn't sufficient because the allocation algorithm may >>> place other >>> constraints on coalescing. George and Appel's iterated register >>> coalescing >>> is a prime example. It wants to "freeze" copies that

I incorporated Evan's suggested changes and testing seems to go well. Ok to commit? -Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: pluggable_coalescer.patch Type: text/x-diff Size: 14338 bytes Desc: not available URL:

On Jun 12, 2009, at 2:52 PM, Mai, Haohui wrote: > Greetings. I'm a Ph.D. student in UIUC. Now I'm working on SAFECode, a > research compiler based on LLVM which insert necessary runtime checks > to guarantee memory-safety of programs. SAFECode needs to insert > checks > into the programs (say, please check this load instruction for me). Hi. > Currently SAFECode

On Jul 17, 2007, at 12:21 PM, David Greene wrote: > >> Are you designing the coalescer so it always run before >> allocation? If so, >> please keep it simple. :-) > > Believe me, I'm trying to keep it as simple as possible. The > coalescer I'm > working on doesn't run "before" allocation. It runs in conjunction > with it. >

On Jul 16, 2007, at 9:12 AM, David Greene wrote: > On Friday 13 July 2007 13:32, David A. Greene wrote: >> On Wednesday 11 July 2007 15:07, Christopher Lamb wrote: >>> Could it be possible for there to be a harness type interface that >>> would allow coalescers that support both modes to be hooked into the >>> pass registration, and those that depend on the

On Aug 27, 2007, at 2:04 PM, David Greene wrote: > >> 3. >> >> + /// Allow the register allocator to communicate when it doesn't >> + /// want a copy coalesced. This may be due to assumptions >> made by >> + /// the allocator about various invariants and so this >> question is >> + /// a matter of legality, not performance.

Hi, > Cool! I think the most critical part of this is to get a good > interface for dependence analysis. There are lots of interesting > implementations that have various time/space tradeoffs. > > For example, it would be great if Omega was available as an option, > even if the compiler didn't use it by default. This argues for making > dependence analysis