[PATCH] format_proc_cpuinfo: add v_spec_ctrl, bus_lock_detect
Linux 5.12 Frozen Wasteland added features and changes: add AMD 0x800a EDX:20 v_spec_ctrl virtual speculation control support add Intel 0x0007 ECX:24 bus_lock_detect bus lock detect debug exception --- winsup/cygwin/fhandler_proc.cc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/winsup/cygwin/fhandler_proc.cc b/winsup/cygwin/fhandler_proc.cc index 501c157daae5..7cd0b3af02a2 100644 --- a/winsup/cygwin/fhandler_proc.cc +++ b/winsup/cygwin/fhandler_proc.cc @@ -1519,6 +1519,7 @@ format_proc_cpuinfo (void *, char *&destbuf) ftcprint (features1, 13, "avic"); /* virt int control */ ftcprint (features1, 15, "v_vmsave_vmload"); /* virt vmsave vmload */ ftcprint (features1, 16, "vgif"); /* virt glb int flag */ + ftcprint (features1, 20, "v_spec_ctrl"); /* virt spec ctrl support */ /* ftcprint (features1, 28, "svme_addr_chk"); *//* secure vmexit addr check */ } @@ -1542,6 +1543,7 @@ format_proc_cpuinfo (void *, char *&destbuf) ftcprint (features1, 14, "avx512_vpopcntdq"); /* vec popcnt dw/qw */ ftcprint (features1, 16, "la57"); /* 5 level paging */ ftcprint (features1, 22, "rdpid");/* rdpid instruction */ + ftcprint (features1, 24, "bus_lock_detect"); /* bus lock detect dbg excptn */ ftcprint (features1, 25, "cldemote"); /* cldemote instr */ ftcprint (features1, 27, "movdiri"); /* movdiri instr */ ftcprint (features1, 28, "movdir64b");/* movdir64b instr */
Re: [PATCH] Use automake (v5)
On 27/04/2021 18:00, Ken Brown wrote:
On 4/27/2021 12:52 PM, Ken Brown wrote:
On 4/27/2021 11:50 AM, Jon Turney wrote:
On 20/04/2021 21:13, Jon Turney wrote:
For ease of reviewing, this patch doesn't contain changes to generated
files which would be made by running ./autogen.sh.
I pushed this patch.
If you have an existing build directory, while you might get away
with invoking 'make' at the top-level, I would recommend blowing it
away and configuring again.
I'm confused about how the generated files are going to get
regenerated when necessary. I see calls to autogen (which I guess is
/usr/bin/autogen.exe from the autogen package) in the Makefiles, but I
That's some cygnus top-level weirdness I don't understand.
don't see any calls to autogen.sh. Is the latter no longer needed?
There is (still) an autogen.sh in winsup/ ...
Oh, never mind. The Makefiles just call autoconf, etc., as needed.
... but you should now never need to explicitly use it, as
('maintainer-mode') rules now exist in the Makefile to do what's needed.
If you do need to make changes in the autofoolery which are going to be
pushed, then specific versions of the autotools still need to be used
(to avoid these generated files thrashing between forms generated by
different versions)
Re: [PATCH] Use automake (v5)
On 4/27/2021 12:52 PM, Ken Brown wrote: On 4/27/2021 11:50 AM, Jon Turney wrote: On 20/04/2021 21:13, Jon Turney wrote: For ease of reviewing, this patch doesn't contain changes to generated files which would be made by running ./autogen.sh. I pushed this patch. If you have an existing build directory, while you might get away with invoking 'make' at the top-level, I would recommend blowing it away and configuring again. I'm confused about how the generated files are going to get regenerated when necessary. I see calls to autogen (which I guess is /usr/bin/autogen.exe from the autogen package) in the Makefiles, but I don't see any calls to autogen.sh. Is the latter no longer needed? Oh, never mind. The Makefiles just call autoconf, etc., as needed. Ken
Re: [PATCH] Use automake (v5)
On 4/27/2021 11:50 AM, Jon Turney wrote: On 20/04/2021 21:13, Jon Turney wrote: For ease of reviewing, this patch doesn't contain changes to generated files which would be made by running ./autogen.sh. I pushed this patch. If you have an existing build directory, while you might get away with invoking 'make' at the top-level, I would recommend blowing it away and configuring again. I'm confused about how the generated files are going to get regenerated when necessary. I see calls to autogen (which I guess is /usr/bin/autogen.exe from the autogen package) in the Makefiles, but I don't see any calls to autogen.sh. Is the latter no longer needed? Ken
Re: [PATCH] Use automake (v5)
On 26/04/2021 16:03, Corinna Vinschen wrote: On Apr 22 13:57, Corinna Vinschen wrote: On Apr 21 18:40, Corinna Vinschen wrote: On Apr 20 21:15, Jon Turney wrote: On 20/04/2021 21:13, Jon Turney wrote: * some object files are in a unexpected places in the build file hierarchy (compared to naive expectations and/or the non-automake build) This is the only minor qualm I have with this patch. It would be nice to have the mingw sources and .o files in the mingw subdir. It would simply be a bit cleaner. The files shared between cygwin and mingw (that's only path.cc, I think) could be handled by an include, i. e. utils/ path.cc (full implementation) utils/mingw/ path.cc: #include "../path.cc" I wonder if it wouldn't make sense to split out the mingw-only parts of path.cc entirely. I had a quick view into the file and it turns out that of the almost 1000 lines in this file, only about 100 lines are used by mount. All the rest is only used by mingw code, i. e., cygcheck and strace. That's obviously not part of this patch, but something we should keep in mind for a later cleanup. I tried this as a POC and it's not much of a problem. See the below patch. Cleaning up the includes is still to do. Thanks, this seems workable. I'll take a look.
Re: [PATCH] Use automake (v5)
On 20/04/2021 21:13, Jon Turney wrote: For ease of reviewing, this patch doesn't contain changes to generated files which would be made by running ./autogen.sh. I pushed this patch. If you have an existing build directory, while you might get away with invoking 'make' at the top-level, I would recommend blowing it away and configuring again.
Re: [PATCH] Cygwin: connect: implement resetting a connected DGRAM socket
On 4/27/2021 9:19 AM, Corinna Vinschen wrote: On Apr 26 15:37, Ken Brown wrote: Following POSIX and Linux, allow a connected DGRAM socket's connection to be reset (so that the socket becomes unconnected). This is done by calling connect and specifing an address whose family is AF_UNSPEC. --- winsup/cygwin/fhandler_socket_inet.cc | 21 -- winsup/cygwin/fhandler_socket_local.cc | 30 +- winsup/cygwin/fhandler_socket_unix.cc | 7 ++ winsup/cygwin/release/3.2.1| 3 +++ winsup/doc/new-features.xml| 6 ++ 5 files changed, 60 insertions(+), 7 deletions(-) LGTM. --- a/winsup/cygwin/release/3.2.1 +++ b/winsup/cygwin/release/3.2.1 @@ -1,6 +1,9 @@ What's new: --- +- A connected datagram socket can now have its connection reset. As + specified by POSIX and Linux, this is done by calling connect(2) + with an address structure whose family is AF_UNSPEC. Isn't that just a bug, in theory? I was thinking of it as a feature that hadn't been implemented yet. But on second thought, I agree with you. I'll change that. Ken
Re: [PATCH] Cygwin: connect: implement resetting a connected DGRAM socket
On Apr 26 15:37, Ken Brown wrote: > Following POSIX and Linux, allow a connected DGRAM socket's connection > to be reset (so that the socket becomes unconnected). This is done by > calling connect and specifing an address whose family is AF_UNSPEC. > --- > winsup/cygwin/fhandler_socket_inet.cc | 21 -- > winsup/cygwin/fhandler_socket_local.cc | 30 +- > winsup/cygwin/fhandler_socket_unix.cc | 7 ++ > winsup/cygwin/release/3.2.1| 3 +++ > winsup/doc/new-features.xml| 6 ++ > 5 files changed, 60 insertions(+), 7 deletions(-) LGTM. > --- a/winsup/cygwin/release/3.2.1 > +++ b/winsup/cygwin/release/3.2.1 > @@ -1,6 +1,9 @@ > What's new: > --- > > +- A connected datagram socket can now have its connection reset. As > + specified by POSIX and Linux, this is done by calling connect(2) > + with an address structure whose family is AF_UNSPEC. Isn't that just a bug, in theory? Thanks, Corinna
