search for: pluggable

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 quer...

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 try and design something that will support remote > > access control. > > I am not sure if sVirt is the right thing I should look at. > > It is plugg...

-----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...

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 for the PAM library ii libpam0g 0.79-5 Pluggable Authentication Modules library Dovecot from package worked just fine with PAM. Also this file already exists: cat /etc/pam...

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é <berrange@re...

...the program. Based on my observation, there are a number of research tools might have the same requirement above. For instance, Automatic Pool Allocation(PLDI'05), KLEE(OSDI'08) and SoftBound(PLDI'09) all insert special intrinsics into programs to perform domain-specific tasks. Having pluggable, first-class intrinsics would simplify the tasks a lot. I'm glad to dig in and implement it if you guys are interested. It seems to me that simply making llvm::CallInst inheritable would be enough. Comments and suggestions are highly appreciated. Thanks. Haohui

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: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070905/acc1cfea/attachment.patch>

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.

.... 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 implementations pluggable like alias analyses. Yes, I also thought about it that way. I think we may look at the dependence analysis in LLVM at three levels (from the lowest to the highest one): 1) Testing for dependence given two sequences of GEP indices assuming that base pointers are the same. The indices could have a...