search for: majorization

It is generally used together with BaseOS (which contains a restricted set of packages), so add it to the preconfigured repositories by default. --- builder/templates/make-template.ml | 27 +++++++++++++++++---------- 1 file changed, 17 insertions(+), 10 deletions(-) diff --git a/builder/templates/make-template.ml b/builder/templates/make-template.ml index 8d26177bf..a4e2f37fb 100755 ---

Use the version struct in inspect_fs to hold the version of a filesystem, adapting the inspection code to that. Also, move the parts of the version parsing to helper functions of the version struct, so common bits like parsing "X.Y" or "X" version strings is done only once. --- v2 changes: - adapt to v2 changes in patch #1 src/guestfs-internal.h | 8 +-

On Tue, Jun 21, 2016 at 7:56 AM Chris Lattner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Jun 19, 2016, at 10:21 AM, Adve, Vikram Sadanand via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >>> Let me clarify. What I’m trying to say is that: > >> > >>> a) LLVM has a time-based release cycle, not a schedule-based one. As >

> On Jun 19, 2016, at 4:25 AM, via llvm-dev <llvm-dev at lists.llvm.org> wrote: <snip> > >>>> Given that our releases are time-based rather than feature-based, >>>> I >>>> don't see a distinct major / minor version being anything other >>>> than >>>> arbitrary, so I'd suggest we take 4.0 as our next release, 4.1

Rusty, currently virtio_blk uses one major number per device. While this works quite well on most systems it is wasteful and will exhaust major numbers on larger installations. This patch allocates a major number on init and will use 16 minor numbers for each disk. That will allow ~64k virtio_blk disks. Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> ---

Rusty, currently virtio_blk uses one major number per device. While this works quite well on most systems it is wasteful and will exhaust major numbers on larger installations. This patch allocates a major number on init and will use 16 minor numbers for each disk. That will allow ~64k virtio_blk disks. Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> ---

There's a standardized libosinfo namespace for libvirt domain metadata. For now it supports the id of the OS only. However that is still a very helpful feature that is already supported in gnome-boxes and virt-manager (at least). The discussion happened here: https://www.redhat.com/archives/libosinfo/2018-September/msg00003.html So let's add the support to local and libvirt outputs.

CentOS 8 is represented with a simpler osinfo ID without a minor version. --- v2v/create_libvirt_xml.ml | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/v2v/create_libvirt_xml.ml b/v2v/create_libvirt_xml.ml index dbc24315..002ce2b8 100644 --- a/v2v/create_libvirt_xml.ml +++ b/v2v/create_libvirt_xml.ml @@ -43,9 +43,14 @@ let get_osinfo_id = function i_major_version

Hi, this adds an helper version struct, and uses it in the backends (for the libvirt and qemu versions) and inspection code. This also moves common code to that, so it is not repeated in many places. This should help with the small refactoring proposed with https://www.redhat.com/archives/libguestfs/2016-May/msg00070.html Thanks, Pino Toscano (2): src: start unifying version handling

Hi, this adds an helper version struct, and uses it in the backends (for the libvirt and qemu versions) and inspection code. This also moves common code to that, so it is not repeated in many places. This should help with the small refactoring proposed with https://www.redhat.com/archives/libguestfs/2016-May/msg00070.html Thanks, Pino Toscano (2): src: start unifying version handling

Hey Sean, So the processor does in-memory computing, it reads instructions and operands from the memory array, performs the majority operations within the memory array itself. It does instructions using resistive majority which is AB'+B'C+AC Like it does AND operation as 1: 0, 1, @C; //C=0 2: 0, 1, @Binv; //Binv=0 3: 1, @B, @Binv; //Binv=B 4: @A, @Binv, @C; //C=A.B where each operation is

On Wednesday, 9 August 2017 19:23:43 CEST Richard W.M. Jones wrote: > +let parse_version_from_major_minor str data = > + if verbose () then > + eprintf "parse_version_from_major_minor: parsing '%s'\n%!" str; > + > + if PCRE.matches re_major_minor str || > + PCRE.matches re_major_no_minor str then ( > + let major = > + try Some

Hello everyone, I was trying to create an LLVM backend for a processor with a very simple architecture and that does all instructions like load, store, arithmetic and logical instructions using a bunch of majority functions. The processor has only one instruction(majority function) in its ISA and breaks down all other instructions into a number of majority instructions depending on what

There's a standardized libosinfo namespace for libvirt domain metadata. For now it supports the id of the OS only. However that is still a very helpful feature that is already supported in gnome-boxes and virt-manager (at least). The discussion happened here: https://www.redhat.com/archives/libosinfo/2018-September/msg00003.html So let's add the support to local and libvirt outputs.

Breaking this out into a separate thread since it's kind of a separate issue, and to make sure people see it. If you have opinions on this, please chime in. I'd like to collect as many arguments here as possible to make a good decision. The main contestants are 4.0 and 3.10, and I've seen folks being equally surprised by both. Brain-dump so far: - After LLVM 1.9 came 2.0, and after

# HG changeset patch # User john.levon@sun.com # Date 1161090130 25200 # Node ID afeef751f9dafa771726bcfb00b29a10b0baeabd # Parent 7147e57f18552bbb8d25155cc1c635315283ee31 On Solaris, GCC is configured to use Sun''s LD. Fix the build to use the correct flags, and link against libsocket where necessary. Signed-off-by: John Levon <john.levon@sun.com> diff --git a/config/Linux.mk

On Mon, Jun 13, 2016 at 4:54 PM, Hans Wennborg <hans at chromium.org> wrote: > Breaking this out into a separate thread since it's kind of a separate > issue, and to make sure people see it. > > If you have opinions on this, please chime in. I'd like to collect as > many arguments here as possible to make a good decision. The main > contestants are 4.0 and 3.10, and

On Sun, Jun 26, 2016 at 10:01 AM Xinliang David Li via cfe-dev < cfe-dev at lists.llvm.org> wrote: > I also believe this is the simplest versioning scheme*. It eliminates all > future debates on this topic (e.g, when to bump major version etc) and > solves the problem once and for all -- which is another plus :) > Except that we'll have to keep dealing with people who are

I also support Chris's position of 4.0, 4.1 etc. I don't think "majorness" is that important, and we can sort out the bit code compatibility story some other way. Sent from phone On Jun 24, 2016 4:42 PM, "Hans Wennborg via llvm-dev" < llvm-dev at lists.llvm.org> wrote: > On Mon, Jun 13, 2016 at 4:54 PM, Hans Wennborg <hans at chromium.org> wrote: >

Hello everyone, I was trying to create an LLVM backend for a processor with a very simple architecture and that does all instructions like load, store, arithmetic and logical instructions using a bunch of majority functions. The processor has only one instruction(majority function) in its ISA and breaks down all other instructions into a number of majority instructions depending on what