similar to: Encoding SSH RSA public key

On Jan 2, 2008 3:34 PM, Arjen de Korte <adkorte-guest at alioth.debian.org> wrote: > Author: adkorte-guest > Date: Wed Jan 2 20:34:26 2008 > New Revision: 1210 > > Log: > Parsing continues if the HID path for a report ends in 0x00000000 (these will not be made available). Commonly used as placeholders. > > It looks like (but correct me if I'm wrong) that reports

--- hivex/hivexsh.pod | 9 ++++++++- 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/hivex/hivexsh.pod b/hivex/hivexsh.pod index 277e3ae..9336798 100644 --- a/hivex/hivexsh.pod +++ b/hivex/hivexsh.pod @@ -100,7 +100,14 @@ or even: Path elements (node names) are matched case insensitively, and characters like space, C<*>, and C<?> have I<no> special

# HG changeset patch # User Olaf Hering <olaf@aepfle.de> # Date 1338572607 -7200 # Node ID 3da83ff08d6b6431c104a431d6617ccb5977643b # Parent fde8ad0252ee6ddb8d71dda869db3b20b3d9ca62 xl.cfg: document the cpuid= option Signed-off-by: Olaf Hering <olaf@aepfle.de> diff -r fde8ad0252ee -r 3da83ff08d6b docs/man/xl.cfg.pod.5 --- a/docs/man/xl.cfg.pod.5 +++ b/docs/man/xl.cfg.pod.5 @@ -969,9

On Wed, Sep 26, 2018 at 9:32 AM Sanjay Patel <spatel at rotateright.com> wrote: > > > On Tue, Sep 25, 2018 at 7:47 PM Cameron McInally <cameron.mcinally at nyu.edu> > wrote: > >> >> This is the first time I'm looking at foldShuffledBinop(...), so maybe a >> naive question, but why not do similar shuffle canonicalizations on unary >> (or

> From: Hin-Tak Leung > > Izmirlian, Grant (NIH/NCI) wrote: > <snipped> > > The only interesting feature is that the tree structure has been > > implemented in C. Its a neater way to carry stuff around and I am > > guessing would make future implementation easier. > > > > Because of its inherent redundancy from the users standpoint, it > >

make features string more readable, add space every 8bit. example: 00101010 01110000 00000000 00001100 Signed-off-by: weiping zhang <zhangweiping at didichuxing.com> --- drivers/virtio/virtio.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c index 59e36ef..d7d2db1 100644 --- a/drivers/virtio/virtio.c +++

Hello all, I have a matrix of bit values. I compute certain values based on the bits in each row. There may be *duplicate* entries in the matrix, ie several rows may be identical. These rows change over time, and identical entries may not be next to each other. Computing these values is time consuming, so I would like a way to store a value once it's computed. That way I would be able to

From: Rusty Russell <rusty at rustcorp.com.au> It seemed like a good idea, but it's actually a pain when we get more than 32 feature bits. Just change it to a u32 for now. Cc: Brian Swetland <swetland at google.com> Cc: Christian Borntraeger <borntraeger at de.ibm.com> Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> Signed-off-by: Cornelia Huck

From: Rusty Russell <rusty at rustcorp.com.au> It seemed like a good idea, but it's actually a pain when we get more than 32 feature bits. Just change it to a u32 for now. Cc: Brian Swetland <swetland at google.com> Cc: Christian Borntraeger <borntraeger at de.ibm.com> Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> Signed-off-by: Cornelia Huck

> From: Rusty Russell <rusty at rustcorp.com.au> > > It seemed like a good idea, but it's actually a pain when we get more > than 32 feature bits. Just change it to a u32 for now. > > Cc: Brian Swetland <swetland at google.com> > Cc: Christian Borntraeger <borntraeger at de.ibm.com> > Signed-off-by: Rusty Russell <rusty at rustcorp.com.au>

> From: Rusty Russell <rusty at rustcorp.com.au> > > It seemed like a good idea, but it's actually a pain when we get more > than 32 feature bits. Just change it to a u32 for now. > > Cc: Brian Swetland <swetland at google.com> > Cc: Christian Borntraeger <borntraeger at de.ibm.com> > Signed-off-by: Rusty Russell <rusty at rustcorp.com.au>

Do we really want to have fneg be the only instruction with guaranteed no side effects? That just sounds like a gotcha waiting to happen. Or it could result in horrible code depending on the architecture. I’m still leaning towards having both an intrinsic and an instruction, and if they happen to have the same behavior then that’s fine. If fneg is to be a special instruction with extra promises

On Thu, Nov 27, 2014 at 05:15:42PM +0100, David Hildenbrand wrote: > > From: Rusty Russell <rusty at rustcorp.com.au> > > > > It seemed like a good idea, but it's actually a pain when we get more > > than 32 feature bits. Just change it to a u32 for now. > > > > Cc: Brian Swetland <swetland at google.com> > > Cc: Christian Borntraeger

On Thu, Nov 27, 2014 at 05:15:42PM +0100, David Hildenbrand wrote: > > From: Rusty Russell <rusty at rustcorp.com.au> > > > > It seemed like a good idea, but it's actually a pain when we get more > > than 32 feature bits. Just change it to a u32 for now. > > > > Cc: Brian Swetland <swetland at google.com> > > Cc: Christian Borntraeger

Aiming these for coming merge window. Nothing should change, but get ready for a non-guest-endian config transports, and > 32 features bits. Final one is just an overdue consolidation. Cheers, Rusty. Rusty Russell (7): virtio_config: introduce size-based accessors. virtio: use size-based config accessors. virtio_config: helpers for non-converting accessors. virtio_config: make

Aiming these for coming merge window. Nothing should change, but get ready for a non-guest-endian config transports, and > 32 features bits. Final one is just an overdue consolidation. Cheers, Rusty. Rusty Russell (7): virtio_config: introduce size-based accessors. virtio: use size-based config accessors. virtio_config: helpers for non-converting accessors. virtio_config: make

This patchset tries to go towards implementing both virtio-1 compliant and transitional virtio drivers in Linux. Branch available at git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux virtio-1 This is based on some old patches by Rusty to handle extended feature bits and endianness conversions. Thomas implemented the new virtio-ccw transport revision command, and I hacked up some

This patchset tries to go towards implementing both virtio-1 compliant and transitional virtio drivers in Linux. Branch available at git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux virtio-1 This is based on some old patches by Rusty to handle extended feature bits and endianness conversions. Thomas implemented the new virtio-ccw transport revision command, and I hacked up some

From: Rusty Russell <rusty at rustcorp.com.au> It seemed like a good idea, but it's actually a pain when we get more than 32 feature bits. Just change it to a u32 for now. Cc: Brian Swetland <swetland at google.com> Cc: Christian Borntraeger <borntraeger at de.ibm.com> Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> Signed-off-by: Cornelia Huck

From: Rusty Russell <rusty at rustcorp.com.au> It seemed like a good idea, but it's actually a pain when we get more than 32 feature bits. Just change it to a u32 for now. Cc: Brian Swetland <swetland at google.com> Cc: Christian Borntraeger <borntraeger at de.ibm.com> Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> Signed-off-by: Cornelia Huck