Re: remove dsp bits from libossaudio
On Fri, Apr 17, 2015 at 3:34 AM, Alexandre Ratchov wrote: > No code uses the SNDCLT_DSP_* "ioctls" anymore (the last port using > them was removed few months ago), so they could be removed now. As > there's no ABI change, no shlib_version crank is necessary. > > The motivation of removing these "ioctls" is to ease > simplifications and development of the audio(4) driver. > > OK? Perhaps delete the #defines in soundcard.h too? Arguably, this should go with a bump to the major version as calls that worked before no longer work, but since no public symbols were removed and nothing apparently uses the removed values I think it's fine. ok guenther@
Re: remove oss support from linux compat (i386 only)
On Fri, Apr 17, 2015 at 3:25 AM, Alexandre Ratchov wrote: > This was "discussed" and nobody steps up to save it: > > http://comments.gmane.org/gmane.os.openbsd.misc/217005 > > removing oss emulation, will remove dependency on obscure audio(4) > features we don't use since ~2009, and in turn will ease audio(4) > driver cleanup without breaking the build. > > Tested on i386. > > OK? ok guenther@
Re: [PATCH] Support If-Modified-Since header on requests in httpd
Sorry for the spam, I submitted the patch during the maintenance period. Any
advice on this patch is appreciated.
Kyle Thompson
> On Apr 18, 2015, at 12:19 PM, jmp wrote:
>
> If-Modified-Since is sent by http clients to be notified if a file has
> been changed. This patch adds a function server_file_modified_since
> that checks the time of the file from stat with the time sent from the
> client. The separate function will help implement proper Range support.
>
> I found 'timeoff' to be useful for converting to a time_t that is in
> GMT; however, did not find documentation on this in the man pages. It
> seems to be a function dating back to at least the NetBSD fork. If
> there is a better time function I should be using please let me know.
>
> The logic is separated out so we can reuse this in the future. I was
> thinking this should be in http.c instead of server_file.c, but for
> right now it is only useful for file operations. If-Modified-Since on
> autoindex will not work due to how the index would be checked by this
> code.
>
> There is room for the 'If-Unmodified-Since' header, but it is not
> really useful for file operations without Range support.
>
>
> Index: usr.sbin/httpd/server_file.c
> ===
> RCS file: /cvs/src/usr.sbin/httpd/server_file.c,v
> retrieving revision 1.51
> diff -u -p -r1.51 server_file.c
> --- usr.sbin/httpd/server_file.c12 Feb 2015 10:05:29 -1.51
> +++ usr.sbin/httpd/server_file.c18 Apr 2015 16:41:55 -
> @@ -42,6 +42,7 @@ int server_file_request(struct httpd *,
>struct stat *);
> int server_file_index(struct httpd *, struct client *, struct stat *);
> int server_file_method(struct client *);
> +int server_file_modified_since(struct http_descriptor *, struct stat *);
>
> int
> server_file_access(struct httpd *env, struct client *clt,
> @@ -123,6 +124,10 @@ server_file_access(struct httpd *env, st
>goto fail;
>}
>
> +if ((ret = server_file_modified_since(desc, &st)) != -1) {
> +return ret;
> +}
> +
>return (server_file_request(env, clt, path, &st));
>
> fail:
> @@ -466,4 +471,24 @@ server_file_error(struct bufferevent *be
>}
>server_close(clt, "unknown event error");
>return;
> +}
> +
> +int
> +server_file_modified_since(struct http_descriptor * desc, struct stat * st)
> +{
> +struct kv key, *since;
> +struct tm tm;
> +
> +memset(&tm, 0, sizeof(struct tm));
> +
> +key.kv_key = "If-Modified-Since";
> +if ((since = kv_find(&desc->http_headers, &key)) != NULL &&
> +since->kv_value != NULL) {
> +if (strptime(since->kv_value, "%a, %d %h %Y %T %Z", &tm) != NULL &&
> +timeoff(&tm, 0L) >= st->st_mtim.tv_sec) {
> +return 304;
> +}
> +}
> +
> +return (-1);
> }
>
Re: remove oss support from linux compat (i386 only)
On Fri, Apr 17, 2015 at 12:25:13PM +0200, Alexandre Ratchov wrote: > This was "discussed" and nobody steps up to save it: > > http://comments.gmane.org/gmane.os.openbsd.misc/217005 > > removing oss emulation, will remove dependency on obscure audio(4) > features we don't use since ~2009, and in turn will ease audio(4) > driver cleanup without breaking the build. > > Tested on i386. > > OK? > ok armani@
Re: sys/ucontext.h - dead code walking?
On Sun, Apr 19, 2015, at 12:23 AM, Philip Guenther wrote: > On Sat, Apr 18, 2015 at 2:56 PM, Adam Wolk wrote: > > On Sat, Apr 18, 2015, at 11:44 PM, Mark Kettenis wrote: > >> > From: Adam Wolk > >> > Date: Sat, 18 Apr 2015 23:23:40 +0200 > ... > >> > Which lead me to a hunt on how other parts of base/ports handle this. > >> > I grepped /usr/src and found something interesting. > >> > > >> > /gnu/gcc/gcc/config/pa/hpux-unwind.h > >> > >> This is HP-UX specific code. > > > > Yes, but there are also other code paths like: > > ./gnu/gcc/gcc/config/i386/linux-unwind.h:#include > > > > It's in the base system, even if it's correct for other platforms then I > > don't see a reason > > for code that will never compile on OpenBSD to be included in OpenBSD base > > - unless > > removing it from the build system is more effort than maintaining it's > > presence. > > There's always a question with 3rd party code, such as everything > under gnu/, of whether local changes should be minimized or expansive. > Once the changes become too expansive, it'll effectively be a fork > which requires more local resources to be spent on it going forward: > look how much effort has gone into libressl. > > It seems in this case that the benefits of removing that code are > insubstantial compared to the time that would be required (would need > to verify that all the archs still build unchanged). Properly done, > there would be *no* effect on the binaries, and would have only > limited improvements on code comprehensibility: this isn't like other > programs where we can delete piles of #ifdefs that cluster the main > code, and really there's very little development being done in the gcc > code itself...so why bother? > > > Philip Guenther Understood. Thank you for the explanation. Regards, Adam
Re: sys/ucontext.h - dead code walking?
On Sat, Apr 18, 2015 at 2:56 PM, Adam Wolk wrote: > On Sat, Apr 18, 2015, at 11:44 PM, Mark Kettenis wrote: >> > From: Adam Wolk >> > Date: Sat, 18 Apr 2015 23:23:40 +0200 ... >> > Which lead me to a hunt on how other parts of base/ports handle this. >> > I grepped /usr/src and found something interesting. >> > >> > /gnu/gcc/gcc/config/pa/hpux-unwind.h >> >> This is HP-UX specific code. > > Yes, but there are also other code paths like: > ./gnu/gcc/gcc/config/i386/linux-unwind.h:#include > > It's in the base system, even if it's correct for other platforms then I > don't see a reason > for code that will never compile on OpenBSD to be included in OpenBSD base - > unless > removing it from the build system is more effort than maintaining it's > presence. There's always a question with 3rd party code, such as everything under gnu/, of whether local changes should be minimized or expansive. Once the changes become too expansive, it'll effectively be a fork which requires more local resources to be spent on it going forward: look how much effort has gone into libressl. It seems in this case that the benefits of removing that code are insubstantial compared to the time that would be required (would need to verify that all the archs still build unchanged). Properly done, there would be *no* effect on the binaries, and would have only limited improvements on code comprehensibility: this isn't like other programs where we can delete piles of #ifdefs that cluster the main code, and really there's very little development being done in the gcc code itself...so why bother? Philip Guenther
Re: remove dsp bits from libossaudio
On Fri, Apr 17, 2015 at 12:34:00PM +0200, Alexandre Ratchov wrote: > No code uses the SNDCLT_DSP_* "ioctls" anymore (the last port using > them was removed few months ago), so they could be removed now. As > there's no ABI change, no shlib_version crank is necessary. > > The motivation of removing these "ioctls" is to ease > simplifications and development of the audio(4) driver. > > OK? > ok armani@
[PATCH] Support If-Modified-Since header on requests in httpd
If-Modified-Since is sent by http clients to be notified if a file has
been changed. This patch adds a function server_file_modified_since
that checks the time of the file from stat with the time sent from the
client. The separate function will help implement proper Range support.
I found 'timeoff' to be useful for converting to a time_t that is in
GMT; however, did not find documentation on this in the man pages. It
seems to be a function dating back to at least the NetBSD fork. If
there is a better time function I should be using please let me know.
The logic is separated out so we can reuse this in the future. I was
thinking this should be in http.c instead of server_file.c, but for
right now it is only useful for file operations. If-Modified-Since on
autoindex will not work due to how the index would be checked by this
code.
There is room for the 'If-Unmodified-Since' header, but it is not
really useful for file operations without Range support.
Index: usr.sbin/httpd/server_file.c
===
RCS file: /cvs/src/usr.sbin/httpd/server_file.c,v
retrieving revision 1.51
diff -u -p -r1.51 server_file.c
--- usr.sbin/httpd/server_file.c12 Feb 2015 10:05:29 - 1.51
+++ usr.sbin/httpd/server_file.c18 Apr 2015 16:41:55 -
@@ -42,6 +42,7 @@ intserver_file_request(struct httpd *,
struct stat *);
int server_file_index(struct httpd *, struct client *, struct stat *);
int server_file_method(struct client *);
+int server_file_modified_since(struct http_descriptor *, struct stat *);
int
server_file_access(struct httpd *env, struct client *clt,
@@ -123,6 +124,10 @@ server_file_access(struct httpd *env, st
goto fail;
}
+ if ((ret = server_file_modified_since(desc, &st)) != -1) {
+ return ret;
+ }
+
return (server_file_request(env, clt, path, &st));
fail:
@@ -466,4 +471,24 @@ server_file_error(struct bufferevent *be
}
server_close(clt, "unknown event error");
return;
+}
+
+int
+server_file_modified_since(struct http_descriptor * desc, struct stat * st)
+{
+ struct kvkey, *since;
+ struct tmtm;
+
+ memset(&tm, 0, sizeof(struct tm));
+
+ key.kv_key = "If-Modified-Since";
+ if ((since = kv_find(&desc->http_headers, &key)) != NULL &&
+ since->kv_value != NULL) {
+ if (strptime(since->kv_value, "%a, %d %h %Y %T %Z", &tm) !=
NULL &&
+ timeoff(&tm, 0L) >= st->st_mtim.tv_sec) {
+ return 304;
+ }
+ }
+
+ return (-1);
}
Re: man, man.conf and /usr/ports/infrastructure/man
> === > RCS file: /cvs/src/etc/examples/man.conf,v > retrieving revision 1.2 > diff -u -r1.2 man.conf > --- etc/examples/man.conf 27 Mar 2015 21:17:16 - 1.2 > +++ etc/examples/man.conf 18 Apr 2015 14:44:00 - > @@ -1,12 +1,15 @@ > #$OpenBSD: man.conf,v 1.2 2015/03/27 21:17:16 schwarze Exp $ > # man(1)/apropos(1)/makewhatis(8) configuration, see man.conf(5). > # This sample file shows the default settings. > +# Commented lines are suggestions that are not enabled by default. > > # Default search path for manual pages. > # Copy these three lines, then add, delete, or reorder as desired. > +# For example, to work on ports(7), uncomment and add the fourth line. > manpath /usr/share/man > manpath /usr/X11R6/man > manpath /usr/local/man > +#manpath /usr/ports/infrastructure/man If the ports infrastructure manual pages were simply part of a package that is neccessary for building ports, then the manuals could show up in /usr/local/man, removing the need for any configuration.
Re: man, man.conf and /usr/ports/infrastructure/man
On Sat, 18 Apr 2015 16:47:20 +0200 Ingo Schwarze wrote: > Hi, > > dan mclaughlin wrote on Mon, Apr 13, 2015 at 01:13:16AM -0400: > > > i think i found the perfect places for this in both ports(7) > > and the FAQ. i'm sure the wording can be improved, but diffs below. > > I'd prefer the following way. > > The FAQ is a separate matter. > > OK? > Ingo > > > Index: etc/examples/man.conf > === > RCS file: /cvs/src/etc/examples/man.conf,v > retrieving revision 1.2 > diff -u -r1.2 man.conf > --- etc/examples/man.conf 27 Mar 2015 21:17:16 - 1.2 > +++ etc/examples/man.conf 18 Apr 2015 14:44:00 - > @@ -1,12 +1,15 @@ > #$OpenBSD: man.conf,v 1.2 2015/03/27 21:17:16 schwarze Exp $ > # man(1)/apropos(1)/makewhatis(8) configuration, see man.conf(5). > # This sample file shows the default settings. > +# Commented lines are suggestions that are not enabled by default. > > # Default search path for manual pages. > # Copy these three lines, then add, delete, or reorder as desired. > +# For example, to work on ports(7), uncomment and add the fourth line. > manpath /usr/share/man > manpath /usr/X11R6/man > manpath /usr/local/man > +#manpath /usr/ports/infrastructure/man > > # Options for terminal output. > output width 78 overall makes sense, but the original 'these three lines' reference seems a little out of place now. > Index: share/man/man7/ports.7 > === > RCS file: /cvs/src/share/man/man7/ports.7,v > retrieving revision 1.101 > diff -u -r1.101 ports.7 > --- share/man/man7/ports.717 Feb 2015 16:29:16 - 1.101 > +++ share/man/man7/ports.718 Apr 2015 14:44:00 - > @@ -740,6 +740,15 @@ > .Xr mirroring-ports 7 , > .Xr packages 7 > .Pp > +To get access to additional maintenance tools for the ports tree, add > +.Pa /usr/ports/infrastructure/bin > +to the > +.Ev PATH > +environment variable and add the line > +.Dq Ic manpath Pa /usr/ports/infrastructure/man > +to > +.Xr man.conf 5 . > +.Pp > The > .Ox > Ports System: that's a good spot, an obvious place to look (i often hit 'G' to get to the end looking for such references.)
Re: sys/ucontext.h - dead code walking?
On Sat, Apr 18, 2015, at 11:44 PM, Mark Kettenis wrote: > > From: Adam Wolk > > Date: Sat, 18 Apr 2015 23:23:40 +0200 > > > > Hi tech@, > > > > I'm working on a port for lang/dart and got stuck on ucontext.h compile > > errors. > > The first one was quite easy, changing sys/ucontext.h to signal.h since > > ucontext_t is > > defined there > > > > sys/signal.h: > > typedef struct sigcontext ucontext_t; > > It is questionable whether ucontext_t should be defined there. The > header has been removed from POSIX, but POSIX still > refers to ucontext_t in its signal handler description. > > In the end the reason has been removed from POSIX is > because it is impossible to use its functionality in a portable > fashion. It is inherently architecture dependent, and effectively OS > dependent as well. > > > This allowed me to move forward and stop on the next bit: > > In file included from runtime/vm/thread_interrupter.h:9:0, > > from runtime/vm/profiler.h:13, > > from runtime/vm/dart.ca c:22: > > runtime/vm/signal_handler.h:49:44: error: 'mcontext_t' does not name a > > type > >static uintptr_t GetProgramCounter(const mcontext_t& mcontext); > > ^ > > runtime/vm/signal_handler.h:50:42: error: 'mcontext_t' does not name a > > type > > If this bit of code is indeed essential,you'll have to write an > OpenBSD-specific version of it. My advise would be to stick to using > "struct sigcontext". Change GetProgramCounter to take "const struct > sigcontext& sc" as an argument, and make it return sc.sc_pc; That > would make it work on alpha/i386/sparc/sparc64/vax and we can add the > appropriate define on other architectures. For amd64 that would be > > #define sc_pc sc_rip > > If you need more help, please post the relevant code or provide an url > with (preferabley browsable) source code. > The browsable code can be seen on github: - https://github.com/dart-lang/bleeding_edge/blob/master/dart/runtime/vm/signal_handler.h It seems that the android path defines: typedef struct sigcontext mcontext_t; which matches your recommendation and has a high chance of the whole port going forward. I'll try adding it in the OpenBSD build path for the port. Thank you for the hint, you probably unblocked my progress on the port > > Which lead me to a hunt on how other parts of base/ports handle this. > > I grepped /usr/src and found something interesting. > > > > /gnu/gcc/gcc/config/pa/hpux-unwind.h > > This is HP-UX specific code. Yes, but there are also other code paths like: ./gnu/gcc/gcc/config/i386/linux-unwind.h:#include It's in the base system, even if it's correct for other platforms then I don't see a reason for code that will never compile on OpenBSD to be included in OpenBSD base - unless removing it from the build system is more effort than maintaining it's presence. I'm not saying it's bad - just wanted to point out that I stumbled upon it. Regards, Adam
Re: man, man.conf and /usr/ports/infrastructure/man
Hi, dan mclaughlin wrote on Mon, Apr 13, 2015 at 01:13:16AM -0400: > i think i found the perfect places for this in both ports(7) > and the FAQ. i'm sure the wording can be improved, but diffs below. I'd prefer the following way. The FAQ is a separate matter. OK? Ingo Index: etc/examples/man.conf === RCS file: /cvs/src/etc/examples/man.conf,v retrieving revision 1.2 diff -u -r1.2 man.conf --- etc/examples/man.conf 27 Mar 2015 21:17:16 - 1.2 +++ etc/examples/man.conf 18 Apr 2015 14:44:00 - @@ -1,12 +1,15 @@ # $OpenBSD: man.conf,v 1.2 2015/03/27 21:17:16 schwarze Exp $ # man(1)/apropos(1)/makewhatis(8) configuration, see man.conf(5). # This sample file shows the default settings. +# Commented lines are suggestions that are not enabled by default. # Default search path for manual pages. # Copy these three lines, then add, delete, or reorder as desired. +# For example, to work on ports(7), uncomment and add the fourth line. manpath /usr/share/man manpath /usr/X11R6/man manpath /usr/local/man +#manpath /usr/ports/infrastructure/man # Options for terminal output. output width 78 Index: share/man/man7/ports.7 === RCS file: /cvs/src/share/man/man7/ports.7,v retrieving revision 1.101 diff -u -r1.101 ports.7 --- share/man/man7/ports.7 17 Feb 2015 16:29:16 - 1.101 +++ share/man/man7/ports.7 18 Apr 2015 14:44:00 - @@ -740,6 +740,15 @@ .Xr mirroring-ports 7 , .Xr packages 7 .Pp +To get access to additional maintenance tools for the ports tree, add +.Pa /usr/ports/infrastructure/bin +to the +.Ev PATH +environment variable and add the line +.Dq Ic manpath Pa /usr/ports/infrastructure/man +to +.Xr man.conf 5 . +.Pp The .Ox Ports System:
Re: sys/ucontext.h - dead code walking?
> From: Adam Wolk > Date: Sat, 18 Apr 2015 23:23:40 +0200 > > Hi tech@, > > I'm working on a port for lang/dart and got stuck on ucontext.h compile > errors. > The first one was quite easy, changing sys/ucontext.h to signal.h since > ucontext_t is > defined there > > sys/signal.h: > typedef struct sigcontext ucontext_t; It is questionable whether ucontext_t should be defined there. The header has been removed from POSIX, but POSIX still refers to ucontext_t in its signal handler description. In the end the reason has been removed from POSIX is because it is impossible to use its functionality in a portable fashion. It is inherently architecture dependent, and effectively OS dependent as well. > This allowed me to move forward and stop on the next bit: > In file included from runtime/vm/thread_interrupter.h:9:0, > from runtime/vm/profiler.h:13, > from runtime/vm/dart.ca c:22: > runtime/vm/signal_handler.h:49:44: error: 'mcontext_t' does not name a > type >static uintptr_t GetProgramCounter(const mcontext_t& mcontext); > ^ > runtime/vm/signal_handler.h:50:42: error: 'mcontext_t' does not name a > type If this bit of code is indeed essential,you'll have to write an OpenBSD-specific version of it. My advise would be to stick to using "struct sigcontext". Change GetProgramCounter to take "const struct sigcontext& sc" as an argument, and make it return sc.sc_pc; That would make it work on alpha/i386/sparc/sparc64/vax and we can add the appropriate define on other architectures. For amd64 that would be #define sc_pc sc_rip If you need more help, please post the relevant code or provide an url with (preferabley browsable) source code. > Which lead me to a hunt on how other parts of base/ports handle this. > I grepped /usr/src and found something interesting. > > /gnu/gcc/gcc/config/pa/hpux-unwind.h This is HP-UX specific code.
[PATCH] If-Modified-Since support in httpd
If-Modified-Since is already sent by most web browsers to httpd. This
patch adds a check to server_file_access before we send the file back.
This does not do any checks for autoindex directories as the size and
last modification dates of files would not get updated properly.
I separated the logic for checking the header values as it can be
reused for different side effects of other headers like Range.
Index: usr.sbin/httpd/server_file.c
===
RCS file: /cvs/src/usr.sbin/httpd/server_file.c,v
retrieving revision 1.51
diff -u -p -r1.51 server_file.c
--- usr.sbin/httpd/server_file.c12 Feb 2015 10:05:29 - 1.51
+++ usr.sbin/httpd/server_file.c18 Apr 2015 16:41:55 -
@@ -42,6 +42,7 @@ intserver_file_request(struct httpd *,
struct stat *);
int server_file_index(struct httpd *, struct client *, struct stat *);
int server_file_method(struct client *);
+int server_file_modified_since(struct http_descriptor *, struct stat *);
int
server_file_access(struct httpd *env, struct client *clt,
@@ -123,6 +124,10 @@ server_file_access(struct httpd *env, st
goto fail;
}
+ if ((ret = server_file_modified_since(desc, &st)) != -1) {
+ return ret;
+ }
+
return (server_file_request(env, clt, path, &st));
fail:
@@ -466,4 +471,24 @@ server_file_error(struct bufferevent *be
}
server_close(clt, "unknown event error");
return;
+}
+
+int
+server_file_modified_since(struct http_descriptor * desc, struct stat * st)
+{
+ struct kvkey, *since;
+ struct tmtm;
+
+ memset(&tm, 0, sizeof(struct tm));
+
+ key.kv_key = "If-Modified-Since";
+ if ((since = kv_find(&desc->http_headers, &key)) != NULL &&
+ since->kv_value != NULL) {
+ if (strptime(since->kv_value, "%a, %d %h %Y %T %Z", &tm) !=
NULL &&
+ timeoff(&tm, 0L) >= st->st_mtim.tv_sec) {
+ return 304;
+ }
+ }
+
+ return (-1);
}
sys/ucontext.h - dead code walking?
Hi tech@,
I'm working on a port for lang/dart and got stuck on ucontext.h compile
errors.
The first one was quite easy, changing sys/ucontext.h to signal.h since
ucontext_t is
defined there
sys/signal.h:
typedef struct sigcontext ucontext_t;
This allowed me to move forward and stop on the next bit:
In file included from runtime/vm/thread_interrupter.h:9:0,
from runtime/vm/profiler.h:13,
from runtime/vm/dart.ca c:22:
runtime/vm/signal_handler.h:49:44: error: 'mcontext_t' does not name a
type
static uintptr_t GetProgramCounter(const mcontext_t& mcontext);
^
runtime/vm/signal_handler.h:50:42: error: 'mcontext_t' does not name a
type
Which lead me to a hunt on how other parts of base/ports handle this.
I grepped /usr/src and found something interesting.
/gnu/gcc/gcc/config/pa/hpux-unwind.h
which contains a:
#include
Now taking this example C program:
$ cat dead.c
#include
int
main(int argc, char *argv[])
{
return 0;
}
$
and trying to compile it:
$ make dead
cc -O2 -pipe-o dead dead.c
dead.c:1:26: error: sys/ucontext.h: No such file or directory
*** Error 1 in /home/mulander/code/c (:85 'dead')
We can see that sys/ucontext.h is not present. Hence the hpux-unwind.h
header file must be dead code.
Grepping src I found some more occurrences, all in base gcc (minus some
changelog/comment entries).
Should header files including sys/ucontext.h be removed along with their
paired .c files?
./gnu/gcc/fixincludes/ChangeLog:* tests/base/sys/ucontext.h: New
file.
./gnu/gcc/fixincludes/fixincl.x: "|sys/ucontext.h|";
./gnu/gcc/fixincludes/inclhack.def:/* The /usr/include/sys/ucontext.h on
ia64-*linux-gnu systems defines
./gnu/gcc/fixincludes/inclhack.def:files = "sys/ucontext.h";
./gnu/gcc/fixincludes/tests/base/sys/ucontext.h:
"fixinc/tests/inc/sys/ucontext.h"
./gnu/gcc/gcc/config/alpha/linux-unwind.h:#include
./gnu/gcc/gcc/config/i386/linux-unwind.h:#include
./gnu/gcc/gcc/config/i386/linux-unwind.h:/* There's no sys/ucontext.h
for glibc 2.0, so no
./gnu/gcc/gcc/config/i386/linux-unwind.h:#include
./gnu/gcc/gcc/config/ia64/linux-unwind.h:#include
./gnu/gcc/gcc/config/mips/linux-unwind.h: * struct ucontext from
sys/ucontext.h so this private copy is used. */
./gnu/gcc/gcc/config/pa/hpux-unwind.h:#include
./gnu/gcc/gcc/config/pa/linux-unwind.h:#include
./gnu/gcc/gcc/config/rs6000/host-darwin.c:#include
./gnu/gcc/gcc/config/sh/linux-unwind.h:#include
./gnu/usr.bin/binutils/gdb/s390-nat.c:#include
./gnu/usr.bin/binutils/gdb/sparc-nat.c: fp_status' in
, which is automatically included by
./gnu/usr.bin/binutils/gdb/user-regs.c:includes
includes , which
./gnu/usr.bin/binutils/gdb/osf-share/cma_tcb_defs.h:# include
./gnu/usr.bin/gcc/gcc/ChangeLog:sys/ucontext.h inclusion in
ifndef USE_GNULIBC_1.
./gnu/usr.bin/gcc/gcc/ChangeLog.7: including signal.h and
sys/ucontext.h, not needed.
./gnu/usr.bin/gcc/gcc/ChangeLog.7: to avoid clash with Irix header
file sys/ucontext.h. Rename gp_regs
./gnu/usr.bin/gcc/gcc/config/alpha/linux.h:#include
./gnu/usr.bin/gcc/gcc/config/i386/linux.h:/* There's no sys/ucontext.h
for some (all?) libc1, so no
./gnu/usr.bin/gcc/gcc/config/i386/linux.h:#include
./gnu/usr.bin/gcc/gcc/config/i386/linux64.h:#include
./gnu/usr.bin/gcc/gcc/config/ia64/linux.h:#include
PS.
I would greatly appreciate If anyone pointed me at a file that still
defines
mcontext_t or an acceptable workaround :)
Regards,
--
Adam Wolk
adam.w...@koparo.com
TLS_READ_AGAIN and TLS_WRITE_AGAIN
The tls_init(3) man page states: The tls_close(), tls_read() and tls_write() functions, along with the tls_accept() and tls_connect() function families, have two special return values: TLS_READ_AGAIN A read operation is necessary to continue. TLS_WRITE_AGAIN A write operation is necessary to continue. The caller should call the appropriate function or, in the case of the tls_close() and the tls_accept() and tls_connect() function families, repeat the call. I find the reference to "appropriate function" unclear. Perhaps there is some deeper meaning that I'm missing, but since in each case the required action is to repeat the call it is clearer to state that directly. I've also included a note about the non-blocking case. Index: tls_init.3 === RCS file: /cvs/src/lib/libtls/tls_init.3,v retrieving revision 1.23 diff -u -p -r1.23 tls_init.3 --- tls_init.3 3 Apr 2015 22:33:43 - 1.23 +++ tls_init.3 18 Apr 2015 07:38:38 - @@ -424,13 +424,14 @@ A read operation is necessary to continu A write operation is necessary to continue. .El .Pp -The caller should call the appropriate function or, in the case of the -.Fn tls_close -and the -.Fn tls_accept -and -.Fn tls_connect -function families, repeat the call. +In response to these return values the original call must be repeated +with the same arguments. +If the underlying socket is non-blocking the caller should first +confirm that the socket is ready to support the required operation, +such as by using +.Xr poll 2 +or +.Xr select 2 . .Sh ERRORS The .Fn tls_error
