search for: ctx1

...ot; #include <string> #include <iostream> using namespace llvm; using namespace std; int main() { // vars string Message; raw_string_ostream Stream(Message); DiagnosticPrinterRawOStream DP(Stream); LLVMBool Result; // create blank modules and contexts LLVMContext *ctx1 = new LLVMContext; Module* module1 = new Module("module1", *ctx1); LLVMContext *ctx2 = new LLVMContext; Module* module2 = new Module("module2", *ctx2); LLVMContext *ctx3 = new LLVMContext; Module* module3 = new Module("module3", *ctx3); // fill module...

Hello openssh@ I thought about sftp's reget/reput commands. Several days ago, Damien Miller write to tech at openbsd.org (it was reply for my letter): > Herein lies a problem which is not easy to detect or solve. For > performance reasons, the sftp client does pipelined reads/writes when > transferring files. The protocol spec allows for a server to process > these requests out

...> > using namespace llvm; > using namespace std; > > int main() { > // vars > string Message; > raw_string_ostream Stream(Message); > DiagnosticPrinterRawOStream DP(Stream); > LLVMBool Result; > // create blank modules and contexts > LLVMContext *ctx1 = new LLVMContext; > Module* module1 = new Module("module1", *ctx1); > LLVMContext *ctx2 = new LLVMContext; > Module* module2 = new Module("module2", *ctx2); > LLVMContext *ctx3 = new LLVMContext; > Module* module3 = new Module("module3", *ctx3...

Hi, I came up with the following patch while trying to figure out a good solution for the situation described in Debian bug #871987[1]. In short, OpenSSL in Debian unstable has disabled TLSv1.0 and TLSv1.1 *by default*. That means that unless an application requests otherwise, only TLSv1.2 is supported. In the world of e-mail this is seemingly an issue, as there are still way too many old clients

Hi, few months ago I started a thread about running PWGL under wine. PWGL is a " free cross-platform visual language based on Common Lisp, CLOS and OpenGL, specialized in computer aided composition and sound synthesis. " http://www2.siba.fi/PWGL/index.html However, because I had to use winetricks to install Microsoft Visual C++ 2005 (it's needed by PWGL), and the many errors that I

...ntext &globa_context = llvm::getGlobalContext(); // codes using only globa_context (get Int32ty() or StructType::create or etc...) } Q2) What situation do I need to create multiple `LLVMContext`s? I don't know the situation used multiple `LLVMContext`s. For example, { { llvm::LLVMContext ctx1; // some code } { llvm::LLVMContext ctx2; // some code } { llvm::LLVMContext ctx3; // some code } } or { llvm::LLVMContext ctxs[] = {....} // some code } I'd like to know the appropriate usage of LLVMContext. Thak you very much for reading. Sincerely, Ryo -------------- next part -------...

...s since + * there's no use for it. + * + * For unknown reasons, NV04 implements surf3d binding in hardware as an + * exception. Also for unknown reasons, NV04 doesn't implement the clipping + * methods on the surf3d object, so we have to emulate them too. + */ + +static void +nv04_graph_set_ctx1(struct nouveau_channel *chan, uint32_t mask, uint32_t value) { struct drm_device *dev = chan->dev; uint32_t instance = (nv_rd32(dev, NV04_PGRAPH_CTX_SWITCH4) & 0xffff) << 4; @@ -542,77 +615,509 @@ nv04_graph_mthd_set_operation(struct nouveau_channel *chan, int grclass, uint32_t...

...vm.swapcontext({}* %thisCtx, {}* %prevCtx) call void @printCo2ThirdMessage() } define i32 @main() nounwind { entry: ; alloca space for the contexts. %ctxSize = call i64 @llvm.context.size() %p0 = alloca i8, i64 %ctxSize %mainCtx = bitcast i8* %p0 to {}* %p1 = alloca i8, i64 %ctxSize %ctx1 = bitcast i8* %p1 to {}* %p2 = alloca i8, i64 %ctxSize %ctx2 = bitcast i8* %p2 to {}* ; Stacks for the contexts %stack1 = alloca i8, i64 4096 %stack2 = alloca i8, i64 4096 ; Create contexts for co1 and co2. call void @llvm.makecontext({}* %ctx1, void({}*, {}*)* @co1, i8* %stack1, i...

...q_queue_reinit_work(); + return 0; +} + +/* + * Before hotadded cpu starts handling requests, new mappings must be + * established. Otherwise, these requests in hw queue might never be + * dispatched. + * + * For example, there is a single hw queue (hctx) and two CPU queues (ctx0 + * for CPU0, and ctx1 for CPU1). + * + * Now CPU1 is just onlined and a request is inserted into ctx1->rq_list + * and set bit0 in pending bitmap as ctx1->index_hw is still zero. + * + * And then while running hw queue, blk_mq_flush_busy_ctxs() finds bit0 is set + * in pending bitmap and tries to retrieve requests...

On 11/21/2017 07:39 PM, Jens Axboe wrote: > On 11/21/2017 11:27 AM, Jens Axboe wrote: >> On 11/21/2017 11:12 AM, Christian Borntraeger wrote: >>> >>> >>> On 11/21/2017 07:09 PM, Jens Axboe wrote: >>>> On 11/21/2017 10:27 AM, Jens Axboe wrote: >>>>> On 11/21/2017 03:14 AM, Christian Borntraeger wrote: >>>>>> Bisect

On 11/21/2017 07:39 PM, Jens Axboe wrote: > On 11/21/2017 11:27 AM, Jens Axboe wrote: >> On 11/21/2017 11:12 AM, Christian Borntraeger wrote: >>> >>> >>> On 11/21/2017 07:09 PM, Jens Axboe wrote: >>>> On 11/21/2017 10:27 AM, Jens Axboe wrote: >>>>> On 11/21/2017 03:14 AM, Christian Borntraeger wrote: >>>>>> Bisect

Signed-off-by: Marcin Ko?cielnicki <koriakin at 0x04.net> --- drivers/gpu/drm/nouveau/nv04_fbcon.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nv04_fbcon.c b/drivers/gpu/drm/nouveau/nv04_fbcon.c index 813b25c..7cf9287 100644 --- a/drivers/gpu/drm/nouveau/nv04_fbcon.c +++ b/drivers/gpu/drm/nouveau/nv04_fbcon.c @@ -236,7 +236,7 @@

...isCtx, {}* %prevCtx) call void @printCo2ThirdMessage() ret void } define i32 @main() nounwind { entry: ; alloca space for the context descriptors. %ctxSize = call i64 @llvm.context.size() %p0 = alloca i8, i64 %ctxSize %mainCtx = bitcast i8* %p0 to {}* %p1 = alloca i8, i64 %ctxSize %ctx1 = bitcast i8* %p1 to {}* %p2 = alloca i8, i64 %ctxSize %ctx2 = bitcast i8* %p2 to {}* ; Stacks for the contexts. If llvm.stackgrowsdown returns true, we need ; pointers to the highest addresses of the stack areas rather than the ; lowest addresses. %growsdown = call i1 @llvm.stackgrow...

...t; + > +/* > + * Before hotadded cpu starts handling requests, new mappings must be > + * established. Otherwise, these requests in hw queue might never be > + * dispatched. > + * > + * For example, there is a single hw queue (hctx) and two CPU queues (ctx0 > + * for CPU0, and ctx1 for CPU1). > + * > + * Now CPU1 is just onlined and a request is inserted into ctx1->rq_list > + * and set bit0 in pending bitmap as ctx1->index_hw is still zero. > + * > + * And then while running hw queue, blk_mq_flush_busy_ctxs() finds bit0 is set > + * in pending bitmap...

...t; + > +/* > + * Before hotadded cpu starts handling requests, new mappings must be > + * established. Otherwise, these requests in hw queue might never be > + * dispatched. > + * > + * For example, there is a single hw queue (hctx) and two CPU queues (ctx0 > + * for CPU0, and ctx1 for CPU1). > + * > + * Now CPU1 is just onlined and a request is inserted into ctx1->rq_list > + * and set bit0 in pending bitmap as ctx1->index_hw is still zero. > + * > + * And then while running hw queue, blk_mq_flush_busy_ctxs() finds bit0 is set > + * in pending bitmap...

We still have MD5 as our default password hash, even though known-hash attacks against MD5 are relatively easy these days. We've supported SHA256 and SHA512 for many years now, so how about making SHA512 the default instead of MD5, like on most Linux distributions? Index: etc/login.conf =================================================================== --- etc/login.conf (revision

Kenneth Uildriks <kennethuil at gmail.com> wrote: > As I see it, the context switching mechanism itself needs to know > where to point the stack register when switching.  The C routines take > an initial stack pointer when creating the context, and keep track of > it from there.  If we don't actually need to interoperate with > contexts created from the C routines, we have

From: Matt Fleming <matt.fleming at linux.intel.com> This series fixes some bugs and switches the elflink branch to be entirely ELF modules. It applies on top of, http://syslinux.zytor.com/archives/2011-April/016369.html The deletions in the diff stat below are mainly from deleting com32/elflink/modules (finally!). Now there should be no duplicate code because we don't need COM32 and