search for: reworks

On Tuesday 08 December 2009 16:01, Dan Gohman wrote: > > I don't see how a register MachineOperand is obviously a vector unless > > there's type information somewhere that I'm missing. > > It has a register which has a register class. It's true that LLVM > currently uses one register class for both scalar and vector uses > of XMM registers on x86, but you

On Dec 9, 2009, at 8:20 AM, David Greene wrote: > On Tuesday 08 December 2009 16:01, Dan Gohman wrote: > >>> I don't see how a register MachineOperand is obviously a vector unless >>> there's type information somewhere that I'm missing. >> >> It has a register which has a register class. It's true that LLVM >> currently uses one register

Key types are getting longer and the current implementation of visual host key breaks with ED25519, resulting in (note the missing bracket): +--[ED25519 256--+ This reworks the calculation of visual host key upper border. Please be aware that this may change the output for other key types as well. --- key.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/key.c b/key.c index 9142338..430f290 100644 --- a/key.c +++ b/key.c @@ -530,13 +5...

On Friday 04 December 2009 16:44, David Greene wrote: > Here's a reworked patch to mark instructions and operands as vector or > scalar. It uses TableGen to infer the flags from types, allowing the user > to override with a "let isVector = 0" clause. > > I decided to forego classifying MachineMemOperands for now in the interests > of getting this piece in. I still

Here's a reworked patch to mark instructions and operands as vector or scalar. It uses TableGen to infer the flags from types, allowing the user to override with a "let isVector = 0" clause. I decided to forego classifying MachineMemOperands for now in the interests of getting this piece in. I still think we should add type information to MachineMemOperands. Why throw away

On 2019/9/5 ??9:59, Jason Gunthorpe wrote: > On Thu, Sep 05, 2019 at 08:27:34PM +0800, Jason Wang wrote: >> Hi: >> >> Per request from Michael and Jason, the metadata accelreation is >> reverted in this version and rework in next version. >> >> Please review. >> >> Thanks >> >> Jason Wang (2): >> Revert "vhost: access vq

On 2019/9/5 ??9:59, Jason Gunthorpe wrote: > On Thu, Sep 05, 2019 at 08:27:34PM +0800, Jason Wang wrote: >> Hi: >> >> Per request from Michael and Jason, the metadata accelreation is >> reverted in this version and rework in next version. >> >> Please review. >> >> Thanks >> >> Jason Wang (2): >> Revert "vhost: access vq

Key types are getting longer and the current implementation of visual host key breaks with ED25519, resulting in (note the missing bracket): +--[ED25519 256--+ This reworks the calculation of visual host key upper border. Please be aware that this slightly modifies the output for other key types as well: +--[ DSA 1024]----+ +---[DSA 1024]----+ +--[ RSA 2048]----+ +---[RSA 2048]----+ +--[ECDSA 256]---+ +---[ECDSA 256]---+ +--[ED25519 256--+ +--[ED25519 256]--+ --...

Hello Michael S. Tsirkin, The patch 6c8e5f3c41c8: "virtio_net: rework mergeable buffer handling" from Mar 6, 2017, leads to the following static checker warning: drivers/net/virtio_net.c:1042 virtnet_receive() error: uninitialized symbol 'ctx'. drivers/net/virtio_net.c 1030 static int virtnet_receive(struct receive_queue *rq, int budget) 1031 { 1032 struct

Hello Michael S. Tsirkin, The patch 6c8e5f3c41c8: "virtio_net: rework mergeable buffer handling" from Mar 6, 2017, leads to the following static checker warning: drivers/net/virtio_net.c:1042 virtnet_receive() error: uninitialized symbol 'ctx'. drivers/net/virtio_net.c 1030 static int virtnet_receive(struct receive_queue *rq, int budget) 1031 { 1032 struct

Hello Ben Skeggs, The patch 97e5268d57bb: "drm/nouveau/fb/gf100-: rework ram detection" from Mar 2, 2017, leads to the following static checker warning: drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c:592 gf100_ram_ctor() warn: should 'size << 20' be a 64 bit type? drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c 572 gf100_ram_ctor(const struct nvkm_ram_func

On Thu, Sep 05, 2019 at 08:27:34PM +0800, Jason Wang wrote: > Hi: > > Per request from Michael and Jason, the metadata accelreation is > reverted in this version and rework in next version. > > Please review. > > Thanks > > Jason Wang (2): > Revert "vhost: access vq metadata through kernel virtual address" > vhost: re-introducing metadata

On Fri, Sep 06, 2019 at 06:02:35PM +0800, Jason Wang wrote: > > On 2019/9/5 ??9:59, Jason Gunthorpe wrote: > > On Thu, Sep 05, 2019 at 08:27:34PM +0800, Jason Wang wrote: > > > Hi: > > > > > > Per request from Michael and Jason, the metadata accelreation is > > > reverted in this version and rework in next version. > > > > > >

Good morning, I wonder could somebody help me bridge the gap? I want to try and simulate a "factory" type environment with an object moving between stages of production with errors and re-work. The intent of this is to demonstrate the effect of error rates and re-work at various stages in the 'factory' on the total volumes of work at each stage of the factory - in order to

Hi everyone, I'm new in the upsdev team, nice to meet you ! I'm currently doing an internship at MGE UPS, working with Arnaud Quette for the NUT project. I'll work for 2 months on the reworking of the configuration files for NUT and creation of libupsconfig and upsconfig libraries. (task 280 and 281 of the NUT project) My planning is as follow : Week 27 : Become used with the

...les. When I share the map on a windows server (or windows os) eveything works. When I share it on a samba server it doesn't. When I open the file, it asks to enable macro's (I need them so say yes) - everything fine - After that It asks if I want to rework/check the links (don't know if reworks is the good word). If I say no, everything ok, when I say yes, exel hangs on reworking the links. With Open Office, I don't have this problem. I'm using samba 2.2.5 (with acl) on a 2.2.18 kernel ps the files are copied from he old NT4 server to the samba server. Did a chmod -R 777 on the...

1/2 is just small code motion. 2/2 reworks the tmpdir and appliance cache directory code. See the commit comment for the full details. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn mac...

Hi, patch inlined for reowkr -> rework conversion in 0.5.3 NEWS entry. cheers, riccardo diff --git a/NEWS b/NEWS index 10b69f7..245c336 100644 --- a/NEWS +++ b/NEWS @@ -5,7 +5,7 @@ Lots of new built-in objects and code cleanup are the highlights of yet another Swfdec release. And a little less condensed: - rework of what APIs call into the script engine. This greatly simplifies using

...t down and fix the regressions as quickly as possible, so please report any issues to this list and/or the freedesktop bugzilla. There's two areas that didn't get "properly" ported over, that is PM-related things and modesetting. I'll be handling the modesetting and clk/volt reworks starting from nowish (in between fixing regressions), and I suspect Martin will handle the rest of the PM bits (therm and fanctrl) since he knows the design he's going for there. One thing to note is that some kernel module options have changed now, the more important ones are: nouveau.vbios=...

Hi all, I would like to announce the first release of the chan_capi channel driver on sourceforge.net The package is available for download with name chan_capi-cm-0.5 and is the current CVS HEAD. It is derived from the chan_capi-0.4.0PRE1 of kapejod. The main changes are: - complete rework - fix race-conditions - fix call state handling - rework of debug/verbose messages - added capiFax