Gerald Pfeifer <gerald(a)pfeifer.com> writes:
> So, I admit I don't really know this code, but looking at it (triggered
> by a warning issued by GCC development versions), I noticed that this
> variable passed by reference is not initialized here.
It's initialized when we return a type, and it doesn't need to be
initialized on NULL return. The code is correct, but you could probably
set the variable to NULL in the caller to silence the warning.
--
Alexandre Julliard
julliard(a)winehq.org
Looking at
RPC_STATUS WINAPI RpcBindingVectorFree( RPC_BINDING_VECTOR** BindingVector )
{
RPC_STATUS status;
ULONG c;
TRACE("(%p)\n", BindingVector);
for (c=0; c<(*BindingVector)->Count; c++) {
status = RpcBindingFree(&(*BindingVector)->BindingH[c]);
}
HeapFree(GetProcessHeap(), 0, *BindingVector);
*BindingVector = NULL;
return RPC_S_OK;
}
we currently always ignore the outcome of RpcBindingFree and return
RPC_S_OK.
However, there is one case where RpcBindingFree returns something
different (which is if *Binding is null when RPC_S_INVALID_BINDING
is returned).
What is the proper way of handling this? Just keeping the code as
is and removing the unused status variable? Breaking the loop once
RpcBindingFree returns something different from RPC_S_OK? Continuing
and returning the first / the last status different from RPC_S_OK?
Gerald
Here are some things I've learned about PCI-passthrough recently, which
would be one way (probably the best) to add "real hardware" to the
TestBot.
I don't want to give anyone false hopes though: this just went from
"this is a mysterious thing I need to learn about" to "I think I know
how to do it but have not tried it yet".
So graphics card PCI-passthrough is now relatively well documented on
the Internet and seems to have seen some use-cases that would indicate
it may even be reasonably usable.
* There are two machines intended to run real GPU tests for Wine:
cw1-hd6800 and cw2-gtx560. For now they are only used to run WineTest
daily on Windows 8.1, Windows 10 1507, 1709, 1809 and Linux. That's
quite a bunch but it would be much better if they were integrated with
the TestBot as that would allow developers to submit their own tests.
So I had a look at what it would imply to convert them to VM hosts
using QEmu + PCI-passthrough.
* First one needs a processor with hardware virtualisation support. For
Intel that's VT-d. Both machines have an Intel Core 2600 which
supports VT-d. Good.
* Second the motherboard too needs to support VT-d. Both machines have
an ASRock P67 Extreme4 motherboard. Unfortunately UEFI says
"unsupported" next to the "VT-d" setting for the motherboard :-( It
looks like there was some confusion as to whether the P67 chipset
supported VT-d initially. From what I gathered it's only Q67 that does
but this caused some manufacturers, among which ASRock, to initially
claim support and later retract it.
* Then one needs to add the intel_iommu=on option to the kernel command
line (resp. amd_iommu). This is should make all the PCI devices appear
in /sys/kernel/iommu_groups. But that folder remains empty which
confirms that full VT-d support is missing.
* Another important aspect is to have a graphics card which is
hot-restartable. In some cases when a VM's graphics card is crashed
the only way to reset it is to reboot the host. The TestBot is likely
to crash the graphics card, particularly if we do a hard-power off on
the VMs like we currently do, and it would relaly be annoying to have
to reboot the host everytime the graphics card goes belly up.
I don't know if the AMD HD6800 and Nvidia GTX560 are suitable but it's
quite possible they are not. All I know for now is that we should
avoid AMD's R9 line of graphics cards. I still need to find a couple
of suitable reasonably lower power graphics cards: one AMD and one
Nvidia.
* Then one needs to prevent the host from using the graphics card.
Usually that's done by having the host use the processor's IGP and
dedicating the discrete GPU to the VMs. Unfortunately the 2600's IGP
cannot be active when there's a discrete card so that route is denied
to us. Fortunately there's quite a bit of documentation on how to shut
down not just X but also the Linux virtual consoles to free the GPU
and hand it over to the VMs after boot.
Doing so means losing KVM access to the host which is a bit annoying
in case something goes wrong. So ideally we'd make sure this does not
happen in grub's "safe mode" boot option.
* Although I have not done any test yet I'm reasonably certain that
PCI-passthrough rules out live snapshots: QEmu would have no way to
restore the graphics card's internal state.
- For Windows VMs that's not an issue: if we provide a power off
snapshot the TestBot already knows how to power on the VM and wait
for it to boot (as long as the boot is shorter than the connection
timeout but it works out usually).
- For Linux VM's that's more of an issue: the TestBot will power on
the VM as usual. The problem is when it updates Wine: after
recompiling everything it deletes the old snapshot and creates a new
one from the current state of the VM, which means a live snapshot.
So the TestBot will need to be modified so it knows when and how to
power off the VM and take a powered off snapshot.
* Since the VM has full control of the graphics card QEmu has no access
to the content of the screen. That's not an issue for the normal
TestBot operation, just for the initial VM setup. Fortunately the
graphics card is connected to a KVM so the screen can be accessed
through that means. It does mean assigning the mouse and keyboard to
the VM too. Should that prove impractical there are a bunch of other
options too: VNC, LookingGlass, Synergy, etc. But the less needs to be
installed in the VMs the better.
* Also the TestBot uses QEmu to take the screenshots. But QEmu does not
have access to the content of the screen. The fix is to use a tool to
take the screenshots from within the VM and use TestAgent to retrieve
them. On Linux there are standard tools we can use. On Windows there's
code floating around we can use.
So the next steps would be:
* Maybe test on my box using the builtin IGP.
But that likely won't be very conclusive beyond confirming the
snapshot issues, screen access, etc.
* Find a suitable AMD or Nvidia graphics card and test that on my box.
That would allow me to fully test integration with the TestBot, check
for stability issues, etc.
* Then see what can be done with the existing cw1 and cw2 boxes.
--
Francois Gouget <fgouget(a)codeweavers.com>
Hello,
Again this year I am helping coordinate the talks and presentations! I hope that people find it helpful and useful! Last work worked out well enough that I am sticking to the same rough format. I think it worked for most other people as well!
If you would like to give a presentation! Please e-mail wineconf(a)winehq.org or me directly! I will keep the Wiki updated with presentations and scheduling as we get it worked out.
When you propose your talk if you have a preference toward a time slot and Saturday or Sunday please express that.
General Guidelines:
* Please provide an estimate of how long your talk will be. We are shooting for approximate 40 minute slots with between 15-20 minutes of talk and with likely an equal amount of question and discussion time afterward. Generally shorter talks are not an issue, however longer talks will need to be discussed and will be considered based on the rest of the schedule.
* Topics should obviously be of interest to the other attendees, i.e., the broader Wine community, but note that that doesn't imply the talk has to be about Wine itself
* If you have a preferred time and date for your talk please indicate that to me when you submit your talk. We will try to make it work as best we can.
Here are the rough proposed slots, They will be changed and modified as required by the addenda as it gets fleshed out. Understand that even with this shift toward a scheduled day we will not disrupt productive conversation to fit to the schedule. The schedule will warp and flow as required to facilitate the talk, not force the talks to conform to it. This does mean if you are planing to try to attend a given talk you will likely want to arrive a bit early and understand if when you arrive the schedule is either behind or ahead of plan.
Daily Slots:
09:00 - 09:40 slot 1
09:45 - 10:25 slot 2
10:30 - 11:00 break
11:00 - 11:40 slot 3
12:00 - 13:00 lunch break
13:00 - 13:40 slot 4
13:45 - 14:25 slot 5
14:30 - 15:00 break
15:00 - 15:40 slot 6
15:45 - 16:25 slot 7
16:25 - 17:00 Overflow time / small group discussion / short presentations
We will track proposed presentations on the WineConf Wiki: https://wiki.winehq.org/WineConf2019
Likely we will have open time at the conference which we will propose presentations and fill at the time. We have never had a problem finding things we all want to talk about.
thanks!
-aric
This adds support for checking the case-insensitive attribute on ext4 with
newer kernels so that Wine can rely on it for performance.
It has some conditional processing for perf reasons. Checking for the
EXT4_CASEFOLD_FL attribute involves an ioctl, which operates on file
descriptors, while all the former checks operated directly on the dir pathname
(e.g. statfs).
Obviously, it's best to avoid looking up the directory multiple times (also
for correctness, so it refers to the same dir). So in the case that we *do*
have a file descriptor, then use it everywhere, with e.g. fstatfs.
However, to avoid a perf regression or downgrade on systems that don't
support the EXT2_IOC_GETFLAGS ioctl (e.g. MacOS, FreeBSD), we continue
using statfs and the like directly, this shaves off two syscalls (open/close).
But in the case the EXT4_CASEFOLD_FL is not supported on Linux (i.e. on
current kernels) or the directory doesn't have it, this will unfortunately
involve a bit more syscalls now, because it has to open() and close() the fd,
but it shouldn't be too much of a problem. (the fstatfs and fstatat make it
less impactful somewhat, so they won't have to lookup the directory again,
hopefully mitigating some of it)
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=47099
Signed-off-by: Gabriel Ivăncescu <gabrielopcode(a)gmail.com>
---
v3: Clean up the code and don't have unused parameters in any case.
GET_DIR_CASE_SENSITIVITY_USE_FD is used so it can be as generic as possible
for fast tweaking and future expansion on other platforms, if they get
something similar.
As it is now, on Linux, we always set the EXT4_CASEFOLD_FL flag
ourselves. Thus, I can of course remove the .ciopfs old code and keep just
the fstatat() call by assuming we always use fd on Linux, if you prefer it
that way, to keep the code smaller. I didn't remove it because I didn't
want to "hardcode" this assumption, so please let me know if that should
be done or not.
dlls/ntdll/directory.c | 73 +++++++++++++++++++++++++++++++++++++-----
1 file changed, 65 insertions(+), 8 deletions(-)
diff --git a/dlls/ntdll/directory.c b/dlls/ntdll/directory.c
index bbdbbe9..354c00f 100644
--- a/dlls/ntdll/directory.c
+++ b/dlls/ntdll/directory.c
@@ -115,6 +115,8 @@ WINE_DEFAULT_DEBUG_CHANNEL(file);
/* just in case... */
#undef VFAT_IOCTL_READDIR_BOTH
+#undef EXT2_IOC_GETFLAGS
+#undef EXT4_CASEFOLD_FL
#ifdef linux
@@ -130,12 +132,25 @@ typedef struct
/* Define the VFAT ioctl to get both short and long file names */
#define VFAT_IOCTL_READDIR_BOTH _IOR('r', 1, KERNEL_DIRENT [2] )
+/* Define the ext2 ioctl for handling extra attributes */
+#define EXT2_IOC_GETFLAGS _IOR('f', 1, long)
+
+/* Case-insensitivity attribute */
+#define EXT4_CASEFOLD_FL 0x40000000
+
#ifndef O_DIRECTORY
# define O_DIRECTORY 0200000 /* must be directory */
#endif
#endif /* linux */
+/* Use a file descriptor for the case-sensitivity check if we have to */
+#if defined(EXT2_IOC_GETFLAGS) && defined(EXT4_CASEFOLD_FL)
+#define GET_DIR_CASE_SENSITIVITY_USE_FD 1
+#else
+#define GET_DIR_CASE_SENSITIVITY_USE_FD 0
+#endif
+
#define IS_OPTION_TRUE(ch) ((ch) == 'y' || (ch) == 'Y' || (ch) == 't' || (ch) == 'T' || (ch) == '1')
#define IS_SEPARATOR(ch) ((ch) == '\\' || (ch) == '/')
@@ -1109,18 +1124,35 @@ static int get_dir_case_sensitivity_attr( const char *dir )
}
#endif
+/***********************************************************************
+ * get_dir_case_sensitivity_ioctl
+ *
+ * Checks if the specified directory is case sensitive or not. Uses ioctl(2).
+ */
+static int get_dir_case_sensitivity_ioctl(int fd)
+{
+#if defined(EXT2_IOC_GETFLAGS) && defined(EXT4_CASEFOLD_FL)
+ int flags;
+ if (ioctl(fd, EXT2_IOC_GETFLAGS, &flags) != -1 && (flags & EXT4_CASEFOLD_FL))
+ return FALSE;
+#endif
+ return -1;
+}
+
/***********************************************************************
* get_dir_case_sensitivity_stat
*
* Checks if the volume containing the specified directory is case
- * sensitive or not. Uses statfs(2) or statvfs(2).
+ * sensitive or not. Uses (f)statfs(2), (f)statvfs(2), or fstatat(2).
*/
-static BOOLEAN get_dir_case_sensitivity_stat( const char *dir )
+static BOOLEAN get_dir_case_sensitivity_stat( const char *dir, int fd )
{
#if defined(__APPLE__) || defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
struct statfs stfs;
- if (statfs( dir, &stfs ) == -1) return FALSE;
+ if (fd != -1 && fstatfs( fd, &stfs ) == -1) return FALSE;
+ if (fd == -1 && statfs( dir, &stfs ) == -1) return FALSE;
+
/* Assume these file systems are always case insensitive on Mac OS.
* For FreeBSD, only assume CIOPFS is case insensitive (AFAIK, Mac OS
* is the only UNIX that supports case-insensitive lookup).
@@ -1157,7 +1189,9 @@ static BOOLEAN get_dir_case_sensitivity_stat( const char *dir )
#elif defined(__NetBSD__)
struct statvfs stfs;
- if (statvfs( dir, &stfs ) == -1) return FALSE;
+ if (fd != -1 && fstatvfs( fd, &stfs ) == -1) return FALSE;
+ if (fd == -1 && statvfs( dir, &stfs ) == -1) return FALSE;
+
/* Only assume CIOPFS is case insensitive. */
if (strcmp( stfs.f_fstypename, "fusefs" ) ||
strncmp( stfs.f_mntfromname, "ciopfs", 5 ))
@@ -1170,7 +1204,9 @@ static BOOLEAN get_dir_case_sensitivity_stat( const char *dir )
char *cifile;
/* Only assume CIOPFS is case insensitive. */
- if (statfs( dir, &stfs ) == -1) return FALSE;
+ if (fd != -1 && fstatfs( fd, &stfs ) == -1) return FALSE;
+ if (fd == -1 && statfs( dir, &stfs ) == -1) return FALSE;
+
if (stfs.f_type != 0x65735546 /* FUSE_SUPER_MAGIC */)
return TRUE;
/* Normally, we'd have to parse the mtab to find out exactly what
@@ -1180,6 +1216,13 @@ static BOOLEAN get_dir_case_sensitivity_stat( const char *dir )
* This will break if somebody puts a file named ".ciopfs" in a non-
* CIOPFS directory.
*/
+ if (fd != -1)
+ {
+ if (fstatat( fd, ".ciopfs", &st, AT_NO_AUTOMOUNT ) == 0)
+ return FALSE;
+ return TRUE;
+ }
+
cifile = RtlAllocateHeap( GetProcessHeap(), 0, strlen( dir )+sizeof("/.ciopfs") );
if (!cifile) return TRUE;
strcpy( cifile, dir );
@@ -1201,16 +1244,30 @@ static BOOLEAN get_dir_case_sensitivity_stat( const char *dir )
* get_dir_case_sensitivity
*
* Checks if the volume containing the specified directory is case
- * sensitive or not. Uses statfs(2) or statvfs(2).
+ * sensitive or not. Uses multiple methods, depending on platform.
*/
static BOOLEAN get_dir_case_sensitivity( const char *dir )
{
+ int case_sensitive, fd = -1;
+
#if defined(HAVE_GETATTRLIST) && defined(ATTR_VOL_CAPABILITIES) && \
defined(VOL_CAPABILITIES_FORMAT) && defined(VOL_CAP_FMT_CASE_SENSITIVE)
- int case_sensitive = get_dir_case_sensitivity_attr( dir );
+ case_sensitive = get_dir_case_sensitivity_attr( dir );
if (case_sensitive != -1) return case_sensitive;
#endif
- return get_dir_case_sensitivity_stat( dir );
+
+ if (GET_DIR_CASE_SENSITIVITY_USE_FD)
+ {
+ if ((fd = open(dir, O_RDONLY | O_NONBLOCK | O_LARGEFILE)) == -1)
+ return TRUE;
+ if ((case_sensitive = get_dir_case_sensitivity_ioctl(fd)) != -1)
+ goto end;
+ }
+ case_sensitive = get_dir_case_sensitivity_stat(dir, fd);
+
+end:
+ if (fd != -1) close(fd);
+ return case_sensitive;
}
--
2.21.0
Hi all,
[I'm addressing it to both mingw-w64-public and wine-devel]
As most of you know, Wine and mingw-w64 have a lot in common and
cooperate to some extend for quite a while. There have been talks about
tightening this relationship for years. Recent Wine move to using PE
files for its builds led us to revisit those ideas. My feeling so far is
that there is an agreement among people I heard from that it's a good
direction for both projects to have mingw-w64 under an umbrella of the
Wine project.
It would be great to move forward with this. Let me discuss a few
aspects of the idea.
- Infrastructure
mingw-w64 currently mostly depends heavily on SourceForge. While I'm
thankful to SF for years of free support, it's doesn't feel like an
optimal choice those days. Wine has its own infrastructure that
mingw-w64 could use right away. Moving things like mailing list, bug
tracker, etc. is straightforward to do, except for one thing... how
should it be called? Which brings us to the next item.
- mingw-w64 name
There have been talks about rebranding mingw-w64 for a long time (longer
than I am in joined the project). While it's a good name for a branch,
an established project that is no longer related to mingw.org could have
a better branding. Kai mentioned that ironcrate was considered as some
point, but to my knowledge no action was taken at that time. Alexandre
offered lately that Wine brand could be used for mingw-w64 as well. I
personally like the idea. Wine is already well recognised brand and
brings roughly right associations. So... how about WineSDK?
- Source code sharing
Technically, we could share much more code than we currently do.
Duplicating efforts is quite suboptimal for everyone. Right now
mingw-w64 imports a number of platform headers and widl tool from Wine
via wine-import.sh script. Wine has a few headers imported from
mingw-w64 as well. It works to some extend, but the fact is that we
still duplicate more than we share. I'm not yet sure how to fix that
entirely, but I'd like us to have a workflow that would limit the
duplication.
- Testing
Wine has a TestBot and a number of test cases, which is a great tool for
developers to make sure their patches are right. mingw-w64 does not have
such thing and mostly depends on developers doing their own testing and
regression reports after the patch is committed. We could integrate
mingw-w64 testing with Wine TestBot to make sure that we don't break
things (well, at least limit that possibility). I believe that it would
nicely accelerate mingw-w64 development workflow as well as ensure that
mingw-w64+Wine don't regress.
- WineConf
The annual Wine conference is a nice chance to meet other contributors
in person:
https://wiki.winehq.org/WineConf
It would be great mingw-w64 developers there as well.
Any ideas, comments and thoughts on this topics are welcomed.
Thanks,
Jacek