Displaying 18 results from an estimated 18 matches for "system_hive".
2017 Jul 31
0
[PATCH v11 09/10] daemon: Implement inspection of Windows.
...software_hive = sprintf "%s/system32/config/software" systemroot in
+ let software_hive = Realpath.case_sensitive_path software_hive in
+ let software_hive =
+ if Is.is_file software_hive then Some software_hive else None in
+ data.windows_software_hive <- software_hive;
+
+ let system_hive = sprintf "%s/system32/config/system" systemroot in
+ let system_hive = Realpath.case_sensitive_path system_hive in
+ let system_hive =
+ if Is.is_file system_hive then Some system_hive else None in
+ data.windows_system_hive <- system_hive;
+
+ match software_hive, system_hive...
2008 Jul 10
4
[LLVMdev] Including svn version number in --version output
It is very useful to have svn version number encoded in llvm-gcc's --
version output. Here is one approach.
Anyone has a better patch ?
-
Devang
Index: Makefile.in
===================================================================
--- Makefile.in (revision 53385)
+++ Makefile.in (working copy)
@@ -802,6 +802,9 @@
DEVPHASE_s := "\"$(if $(DEVPHASE_c),
2008 Jul 10
0
[LLVMdev] Including svn version number in --version output
Why not set the VERSUFFIX to be " (Based on Apple Inc. build 5555) (LLVM
rXXXX)"
Where you set the revision number?
We currently use LLVM_VERSION_INFO to set this sort of information and to
me it makes more sense to have the svn rev number there instead of just
saying LLVM build like it does now.
-Tanya
On Wed, 9 Jul 2008, Devang Patel wrote:
> It is very useful to have svn
2018 Dec 04
2
[PATCH FOR DISCUSSION ONLY 0/2] v2v: Copy static IP address information over for Windows guests (RHBZ#1626503).
This patch is just for discussion. There are still a couple of issues
that I'm trying to fix.
One is that all of the test guests I have, even ones with static IPs,
have multiple interfaces, some using DHCP, so the conditions for
adding the Powershell script don't kick in. This makes testing very
awkward.
However a bigger issue is that I think the premise is wrong. In some
registries
2018 Dec 11
2
[PATCH v2 2/2] v2v: Copy static IP address information over for Windows guests (RHBZ#1626503).
v1 was here with much discussion:
https://www.redhat.com/archives/libguestfs/2018-December/msg00048.html
v2:
- Fix the case where there are multiple interfaces. Note this does
not preserve order correctly (see patch for comment on why that
is a hard problem).
- Preserve name servers.
This patch is still for discussion only. I'd like to see what might
be done to get this upstream
2008 Jul 10
4
[LLVMdev] Including svn version number in --version output
On Jul 9, 2008, at 6:13 PM, Tanya M. Lattner wrote:
>
> Why not set the VERSUFFIX to be " (Based on Apple Inc. build 5555)
> (LLVM
> rXXXX)"
>
> Where you set the revision number?
I do not want to set the revision number in a source file every time I
do 'svn update' :)
> We currently use LLVM_VERSION_INFO to set this sort of information
> and to
2006 Jul 07
1
[LLVMdev] Problem Compiling llvm-gcc4 r12 and r13
A clean build of revisions 12 or 13 of llvm-gcc4 produces:
make[1]: *** No rule to make target `llvm-backend.c', needed by `llvm-backend.o'. Stop.
While the gcc/Makefile.in has:
llvm-backend.o : llvm-backend.cpp $(ALL_HEADERS) #line 2440
it also has:
# APPLE LOCAL begin LLVM #line 1018
ifneq ($(LLVMOBJDIR),)
OBJS-common += llvm-backend.o llvm-convert.o
2008 Jul 10
0
[LLVMdev] Including svn version number in --version output
On Jul 9, 2008, at 6:13 PM, Devang Patel wrote:
>
> On Jul 9, 2008, at 6:13 PM, Tanya M. Lattner wrote:
>
>>
>> Why not set the VERSUFFIX to be " (Based on Apple Inc. build 5555)
>> (LLVM
>> rXXXX)"
>>
>> Where you set the revision number?
>
> I do not want to set the revision number in a source file every time I
> do 'svn
2012 Aug 29
5
[PATCH 0/4] Add hivex APIs into the libguestfs API (RHBZ#852394)
This adds most of the hivex APIs directly to the libguestfs API, so
that you can read and write Windows Registry hive files from
libguestfs without needing to download and upload hive files from the
guest.
This is analogous to how Augeas APIs are exposed already
(guestfs_aug_*)
Also, inspection is now done using the new APIs, which fixes the
following bug:
2002 Jan 07
2
rsync-2.5.1 / popt patches
The following popt files need patches in order to compile using Compaq C
on OpenVMS. These patches should also be needed on a Tru64 or LINUX on
ALPHA using Compaq C. Except for the alloca issue, these should work on
any ANSI compliant compiler.
Operating System: OpenVMS ALPHA V7.3
Compiler: Compaq C T6.5
Compiler switches: /WARN=ENABLE=(LEVEL4, QUESTCODE)
SYSTEM.H is doing tests on
2017 Jul 31
16
[PATCH v11 00/10] Reimplement inspection in the daemon.
v10: https://www.redhat.com/archives/libguestfs/2017-July/msg00245.html
No actual change here, but I rebased and retested. Also this series
now does not depend on any other patch series since everything else
needed is upstream.
Rich.
2017 Jul 21
10
[PATCH v10 00/10] Reimplement inspection in the daemon.
v9 was here:
https://www.redhat.com/archives/libguestfs/2017-July/msg00139.html
This depends on these three series (the first two being single minor
patches):
https://www.redhat.com/archives/libguestfs/2017-July/msg00207.html
https://www.redhat.com/archives/libguestfs/2017-July/msg00209.html
https://www.redhat.com/archives/libguestfs/2017-July/msg00215.html
There is no substantive change. I
2017 Jul 17
12
[PATCH v9 00/11] Reimplement inspection in the daemon.
This depends on the patch series
"[PATCH 00/27] Reimplement many daemon APIs in OCaml."
(https://www.redhat.com/archives/libguestfs/2017-July/msg00098.html)
v8 was posted here:
https://www.redhat.com/archives/libguestfs/2017-June/msg00274.html
v9:
- I split up the mega-patch into a more reviewable series of
smaller, incremental patches.
There are some other changes vs v8, but
2017 Aug 09
16
[PATCH v12 00/11] Reimplement inspection in the daemon.
This fixes almost everything. Note that it adds an extra commit which
fixes the whole utf8/iconv business.
It's probably better to list what isn't fixed:
(1) I didn't leave the osinfo code around because I'm still haven't
looked too closely at virt-builder-repository. Can't we just fetch
this code from the git history when we need it?
(2) I didn't change the way
2017 Feb 18
11
[PATCH 0/8] Miscellaneous cleanups to Windows registry code.
A very miscellaneous set of cleanups to how we handle the Windows
registry in virt-v2v, firstboot, and inspection code. This should all
be straightforward non-controversial refactoring. Some highlights:
- Add a new mllib Registry module containing various utility
functions that are currently scattered all around.
- Only compute the software/system hive paths once during inspection,
and
2017 Jun 19
29
[PATCH v7 00/29] Reimplement inspection in the daemon.
v6 was posted here:
https://www.redhat.com/archives/libguestfs/2017-June/msg00103.html
and this requires the utilities refactoring posted here:
https://www.redhat.com/archives/libguestfs/2017-June/msg00169.html
Inspection is now complete[*], although not very well tested. I'm
intending to compare the output of many guests using old & new
virt-inspector to see if I can find any
2017 Jun 15
45
[PATCH v6 00/41] Refactor utilities, reimplement inspection in the daemon.
v5:
https://www.redhat.com/archives/libguestfs/2017-June/msg00065.html
Since v5, this now implements inspection almost completely for Linux
and Windows guests.
Rich.
2017 Jun 21
45
[PATCH v8 00/42] Refactor utilities and reimplement inspection.
v7 was:
https://www.redhat.com/archives/libguestfs/2017-June/msg00169.html
https://www.redhat.com/archives/libguestfs/2017-June/msg00184.html
I believe this addresses all comments received so far.
Also it now passes a test where I compared about 100 disk images
processed with old and new virt-inspector binaries. The output is
identical in all cases except one which is caused by a bug in blkid