Re: [PATCH 2/8] Drop STDINCFLAGS overrides
On Oct 13 18:36, Jon Turney wrote: > On 13/10/2020 13:10, Corinna Vinschen wrote: > > On Oct 12 20:29, Jon Turney wrote: > > > This used to turn off -nostdinc on a per-file basis, but has no effect > > > since 4c36016b. > > > > I'd prefer a longer SHA-1, at least 12 chars. Maybe we should > > With ~20K commits in the repository, the chance of a hash collision in the > first 32 bits (~~ 4*10^9) seems pretty small, but sure. > > > add a "Fixes: ..." along the lines of the Linux kernel from now on? > > This doesn't actually fix anything, just removes some cruft. Point. > > Ideally we'd get rid of ccwrap/c++wrap, too... > > Working on it :) \o/ Corinna
Re: [PATCH] format_proc_cpuinfo: add enqcmd cpuinfo flag
On Oct 13 09:11, Brian Inglis wrote: > Add linux-next 5.9 cpuinfo flag for Intel enqcmd/s instructions: > x86/cpufeatures: Enumerate ENQCMD and ENQCMDS instructions: > Work submission instruction comes in two flavors. ENQCMD can be called > both in ring 3 and ring 0 and always uses the contents of a PASID MSR > when shipping the command to the device. ENQCMDS allows a kernel driver > to submit commands on behalf of a user process. The driver supplies the > PASID value in ENQCMDS. There isn't any usage of ENQCMD in the kernel as > of now. > The CPU feature flag is shown as "enqcmd" in /proc/cpuinfo. > --- > winsup/cygwin/fhandler_proc.cc | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/winsup/cygwin/fhandler_proc.cc b/winsup/cygwin/fhandler_proc.cc > index 6f6e8291a0ca..13397150ff53 100644 > --- a/winsup/cygwin/fhandler_proc.cc > +++ b/winsup/cygwin/fhandler_proc.cc > @@ -1563,6 +1563,7 @@ format_proc_cpuinfo (void *, char *) > ftcprint (features1, 25, "cldemote"); /* cldemote instr */ > ftcprint (features1, 27, "movdiri"); /* movdiri instr */ > ftcprint (features1, 28, "movdir64b");/* movdir64b instr */ > + ftcprint (features1, 29, "enqcmd"); /* enqcmd/s > instructions*/ > } > >/* AMD MCA cpuid 0x8007 ebx */ > -- > 2.28.0 Pushed. Thanks, Corinna
Re: [PATCH 2/8] Drop STDINCFLAGS overrides
On 13/10/2020 13:10, Corinna Vinschen wrote: On Oct 12 20:29, Jon Turney wrote: This used to turn off -nostdinc on a per-file basis, but has no effect since 4c36016b. I'd prefer a longer SHA-1, at least 12 chars. Maybe we should With ~20K commits in the repository, the chance of a hash collision in the first 32 bits (~~ 4*10^9) seems pretty small, but sure. add a "Fixes: ..." along the lines of the Linux kernel from now on? This doesn't actually fix anything, just removes some cruft. Ideally we'd get rid of ccwrap/c++wrap, too... Working on it :)
Re: [PATCH v2 5/6] Cygwin: AF_UNIX: listen_pipe: check for STATUS_SUCCESS
On Oct 13 13:18, Ken Brown via Cygwin-patches wrote: > On 10/13/2020 7:28 AM, Corinna Vinschen wrote: > > On Oct 4 12:49, Ken Brown via Cygwin-patches wrote: > >> A successful connection can be indicated by STATUS_SUCCESS or > >> STATUS_PIPE_CONNECTED. > > > > THanks for catching but... huh? How does Windows generate two different > > status codes for the same result from the same function? > > I think (but I'd have to recheck) that if the pipe is already connected when > NtFsControlFile is called, then the latter returns STATUS_PIPE_CONNECTED. > But > if you first get STATUS_PENDING and then set status = io.Status after > completion, then the result is STATUS_SUCCESS. Ah, ok. I guess I just missed this scenario for some reason. Thanks, Corinna
[PATCH] format_proc_cpuinfo: add enqcmd cpuinfo flag
Add linux-next 5.9 cpuinfo flag for Intel enqcmd/s instructions: x86/cpufeatures: Enumerate ENQCMD and ENQCMDS instructions: Work submission instruction comes in two flavors. ENQCMD can be called both in ring 3 and ring 0 and always uses the contents of a PASID MSR when shipping the command to the device. ENQCMDS allows a kernel driver to submit commands on behalf of a user process. The driver supplies the PASID value in ENQCMDS. There isn't any usage of ENQCMD in the kernel as of now. The CPU feature flag is shown as "enqcmd" in /proc/cpuinfo. --- winsup/cygwin/fhandler_proc.cc | 1 + 1 file changed, 1 insertion(+) diff --git a/winsup/cygwin/fhandler_proc.cc b/winsup/cygwin/fhandler_proc.cc index 6f6e8291a0ca..13397150ff53 100644 --- a/winsup/cygwin/fhandler_proc.cc +++ b/winsup/cygwin/fhandler_proc.cc @@ -1563,6 +1563,7 @@ format_proc_cpuinfo (void *, char *) ftcprint (features1, 25, "cldemote"); /* cldemote instr */ ftcprint (features1, 27, "movdiri"); /* movdiri instr */ ftcprint (features1, 28, "movdir64b");/* movdir64b instr */ + ftcprint (features1, 29, "enqcmd"); /* enqcmd/s instructions*/ } /* AMD MCA cpuid 0x8007 ebx */ -- 2.28.0
Re: [PATCH v2 5/6] Cygwin: AF_UNIX: listen_pipe: check for STATUS_SUCCESS
On 10/13/2020 7:28 AM, Corinna Vinschen wrote: > On Oct 4 12:49, Ken Brown via Cygwin-patches wrote: >> A successful connection can be indicated by STATUS_SUCCESS or >> STATUS_PIPE_CONNECTED. > > THanks for catching but... huh? How does Windows generate two different > status codes for the same result from the same function? I think (but I'd have to recheck) that if the pipe is already connected when NtFsControlFile is called, then the latter returns STATUS_PIPE_CONNECTED. But if you first get STATUS_PENDING and then set status = io.Status after completion, then the result is STATUS_SUCCESS. I might not have that exactly right. All I remember for sure is that I was debugging a listen_pipe failure, and it turned out to be due to STATUS_SUCCESS being treated as an error condition. Ken
Re: [PATCH 2/8] Drop STDINCFLAGS overrides
On Oct 12 20:29, Jon Turney wrote: > This used to turn off -nostdinc on a per-file basis, but has no effect > since 4c36016b. I'd prefer a longer SHA-1, at least 12 chars. Maybe we should add a "Fixes: ..." along the lines of the Linux kernel from now on? Ideally we'd get rid of ccwrap/c++wrap, too... Corinna
Re: [PATCH] Cygwin: pty: Add workaround for ISO-2022 and ISCII in convert_mb_str().
On Sep 12 04:11, Takashi Yano via Cygwin-patches wrote: > On Fri, 11 Sep 2020 20:57:06 +0200 > Corinna Vinschen wrote: > > On Sep 12 03:37, Takashi Yano via Cygwin-patches wrote: > > > On Sat, 12 Sep 2020 02:38:43 +0900 > > > Takashi Yano via Cygwin-patches wrote: > > > > How about the patch attached? > > > > I think this is safer than previous patch. > > > > > > I have revised this patch to fit current git head, and submit > > > to cygwin-patches@cygwin.com. > > > > Thanks, but I didn't apply this one because it doesn't really make sense > > to go to the extra effort to support outdated and incompatible codepages > > we don't handle as Cygwin codeset at all. IMHO it's not worth to call > > another MBTWC just to check if a codepage supports the MB_ERR_INVALID_CHARS > > flag. > > I have checked which codepage does not support MB_ERR_INVALID_CHARS. > The result is as follows. > > 42 > 50220 > 50221 > 50222 > 50225 > 50227 > 50229 > 52936 > 57002 > 57003 > 57004 > 57005 > 57006 > 57007 > 57008 > 57009 > 57010 > 57011 > 65000 Yup, these are documented on MSDN: https://docs.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-widechartomultibyte > If all of these are not worth for everyone, I agree with you. I think we can skip those. Corinna
Re: [PATCH v2 5/6] Cygwin: AF_UNIX: listen_pipe: check for STATUS_SUCCESS
On Oct 4 12:49, Ken Brown via Cygwin-patches wrote: > A successful connection can be indicated by STATUS_SUCCESS or > STATUS_PIPE_CONNECTED. THanks for catching but... huh? How does Windows generate two different status codes for the same result from the same function? Corinna
Re: [PATCH v2 0/6] Some AF_UNIX fixes
On Oct 4 12:49, Ken Brown via Cygwin-patches wrote: > I'm about to push these. Corinna, please check them when you return. > The only difference between v2 and v1 is that there are a few more > fixes. > > I'm trying to help get the AF_UNIX development going again. I'm > mostly working on the topic/af_unix branch. But when I find bugs that > exist on master, I'll push those to master and then merge master to > topic/af_unix. > > So far what I have on that branch locally (to be pushed shortly) is an > implementation of fhandler_socket_unix::read, which I've tested by > running the srver/client programs from Section 57.2 of Kerrisk's book, > "The Linux Programming Interface". Oh boy, this is S great! Thanks for working on that! Corinna
Re: [PATCH] Cygwin: winlean.h: remove most of extended memory API
On Sep 24 15:04, Jon Turney wrote: > On 24/09/2020 00:52, Ken Brown via Cygwin-patches wrote: > > This was added as a temporary measure in commit e18f7f99 because it > > wasn't yet in the mingw-w64 headers. With one exception, it is now in > > the current release of the headers (version 8.0.0), so we don't need > > it in winlean.h. The exception is that VirtualAlloc2 is only declared > > conditionally in , so retain it in winlean.h. Add > > I assume it's conditional on the windows version targetted, but it might > help to mention that in a comment. > > > "WINAPI" to its declaration for consistency with the delaration in > > memoryapi.h. > > > > Also revert commit 3d136011, which was a related temporary workaround. > > Looks good to me. > > I think this isn't going work any more with older win32api, but we probably > don't care about that. It would perhaps be nice to explicitly complain > about that (checking __MINGW64_VERSION_MAJOR somehow), rather than exploding > incomprehensibly if the w32api is too old? > > > In particular, I'd like to know if my handling of the declaration of > > VirtualAlloc2 seems reasonable. Among other things, I'm puzzled by the > > apparent need to add WINAPI. If it's really needed, I don't know how > > the calls of that function could have worked before. Can anyone > > enlighten me? > > I believe that WINAPI only does something (stdcall) on x86, so it might well > be that it's never worked on Windows 10 =>1803 x86? VirtualAlloc2 is only called in x86_64 code, so the WINAPI was not required. x86 is a lost case in terms of memory allocation anyway. Corinna
