John Polstra wrote:
>
> If/when you change the size of jmp_buf, please remember to increment
> __FreeBSD_version in "src/sys/sys/param.h". This is likely to break
> the Modula-3 threads support (CVSup), and I'll need a way to deal with
> that.
Good one. jmp_buf has indeed changed. Consider it d
If/when you change the size of jmp_buf, please remember to increment
__FreeBSD_version in "src/sys/sys/param.h". This is likely to break
the Modula-3 threads support (CVSup), and I'll need a way to deal with
that.
No, I can't just use sizeof. The Modula-3 threads package is written
in (duh) Mod
> It's true that this would (currently) slow down uthreads. However, I
> suspect that uthreads may want to do its own signal-mask handling
> anyway (even though it currently doesn't). On the other hand, if we
> made jmp_buf and struct sigcontext compatible, it could clean up the
> thread schedul
> This is a particularly safe implementation typedef,
> since I don't anticipate uint64_t ever being used in a future specification
> as a different data type.
> I don't know about ANSI.
It's in C9x.
But not in . The n869 draft has it in and
only.
Bruce
To Unsubscribe: send mail to [EMAIL
On Mon, 6 Sep 1999, Garrett Wollman wrote:
> <
>said:
>
> > Wouldn't you hose uthread performance? I thought that one of the major
> > benefits it that a context switch in uthreads did not require kernel
> > intervention and a syscall.
>
> It's true that this would (currently) slow down uthre
> Anything that knows about sigset_t will already be using the POSIX
> macros for it, since sigset_t was a POSIX invention. The old
> `sigmask'-style functions don't have such an API, so they need to be
> left as-is. (Such programs would not know about high-numbered signals
> anyway, so this is
<
said:
> Wouldn't you hose uthread performance? I thought that one of the major
> benefits it that a context switch in uthreads did not require kernel
> intervention and a syscall.
It's true that this would (currently) slow down uthreads. However, I
suspect that uthreads may want to do its o
< It's true that this would (currently) slow down uthreads.
Actually, uthreads uses the signal-preserving versions (setjmp and
longjmp), so it's already entering the kernel on every context switch.
-GAWollman
--
Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same
[EM
Garrett Wollman wrote:
>
> < said:
>
> > Known problems:
> > Building world fails because the freshly built cpp segfaults. A setjmp call
> > that may be involved matches the problem of a return address being 0. gdb
> > does not display a complete backtrace...
>
> The {,sig}setjmp buffer contain
Garrett Wollman wrote:
>
> < said:
>
> > kernel/userland - http://www.FreeBSD.org/~marcel/signal.diff
>
> There appear to be some fairly gratuitous name changes in here.
Elaborate, please.
> Also, my own feeling is that it would be better to continue to use
> integral types for signal
Garrett Wollman wrote:
> Peter D. and I have been discussing this topic over the past few days,
> and I was about to sit down and do the implementation when I saw your
> message. I'd appreciate it if you can hold off on yours for a bit.
Yes, but why?
--
Marcel Moolenaar
< said:
> kernel/userland - http://www.FreeBSD.org/~marcel/signal.diff
There appear to be some fairly gratuitous name changes in here.
Also, my own feeling is that it would be better to continue to use
integral types for signal sets inside the kernel. This makes the code
much easier to
< said:
> Known problems:
> Building world fails because the freshly built cpp segfaults. A setjmp call
> that may be involved matches the problem of a return address being 0. gdb
> does not display a complete backtrace...
The {,sig}setjmp buffer contains a sigset_t. The size of a JMP_BUF
needs
< said:
> You first need to get rid of any code that assumes that siget_t is an
> (unsigned) integer. Use macros to abstract the access to the new sigset_t
> so that you don't replace one assumption with the other...
Anything that knows about sigset_t will already be using the POSIX
macros for i
< said:
> /* Now just insert the macros to make this work...
> */
I'd be inclined to make sigemptyset() and sigfillset(), at a minimum,
functions only (not macros).
I'd define sigaddset something like this (function version):
int
sigaddset(sigset_t *ss, int sig)
{
int index, bit;
< said:
> This is a particularly safe implementation typedef,
> since I don't anticipate uint64_t ever being used in a future specification
> as a different data type.
> I don't know about ANSI.
It's in C9x.
-GAWollman
--
Garrett A. Wollman | O Siem / We are all family / O Siem / We're all
Not
> #ifdef _SIGNAL_HEADER
But
> #if _SIGNAL_HEADER == 1
of course.
Peter
--
Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control,
HD Associates, Inc. Safety critical systems, Agency approval
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscrib
> Peter Dufault wrote:
>
> > 1. Immediately do roughly what you displayed only without increasing
> > the number of signals but instead using two sixteen bit ints, and
> > commit after testing.
> [snip]
> > 2. Switch to the higher number of signals using the approach I
> > suggested making the hi
Peter Dufault wrote:
>
> > Peter Dufault wrote:
> >
> > > Firstly, you should get rid of any explicit 32, 31, etc and anything
> > > else tied to the assumed number of bits in an int.
> >
> > You first need to get rid of any code that assumes that siget_t is an
> > (unsigned) integer. Use macros
> > typedef struct {
> > unsigned int n;
> > uint64_t v;
> > } sigset_t;
>
> You can't use any BSD or FreeBSD specific types (such as u_int32)t) in
> publicly visible types (such as sigset_t). It breaks programs because it's
> not ANSI and/or Posix.
You can use internal names lik
> Peter Dufault wrote:
>
> > Firstly, you should get rid of any explicit 32, 31, etc and anything
> > else tied to the assumed number of bits in an int.
>
> You first need to get rid of any code that assumes that siget_t is an
> (unsigned) integer. Use macros to abstract the access to the new si
Peter Dufault wrote:
> 1. Immediately do roughly what you displayed only without increasing
> the number of signals but instead using two sixteen bit ints, and
> commit after testing.
[snip]
> 2. Switch to the higher number of signals using the approach I
> suggested making the high 16 bits of th
Peter Dufault wrote:
> Firstly, you should get rid of any explicit 32, 31, etc and anything
> else tied to the assumed number of bits in an int.
You first need to get rid of any code that assumes that siget_t is an
(unsigned) integer. Use macros to abstract the access to the new sigset_t
so that
> Description:
> When we want to support Linux binaries in the future and possibly also want
> real-time signals, then we need to support more than 32 signals...
I thought about this a bit more and thought of a good two-step process:
1. Immediately do roughly what you displayed only without in
> Description:
> When we want to support Linux binaries in the future and possibly also want
> real-time signals, then we need to support more than 32 signals.
>
> Current status:
> The diffs result in a working backwards compatible GENERIC kernel. The
> linuxulator also doesn't seem to be brok
Disclaimer:
This is still work in progress.
Description:
When we want to support Linux binaries in the future and possibly also want
real-time signals, then we need to support more than 32 signals.
Current status:
The diffs result in a working backwards compatible GENERIC kernel. The
linuxul
26 matches
Mail list logo
