|
|
 Up |
|
|
  |
Author: Tobias WeingartnerTobias Weingartner
Date: May 4, 2008 22:29
On Sunday, May 4, "Ted Unangst" wrote:
> On 5/3/08, Philip Guenther gmail.com> wrote:>> Change "long p_thrslpid;" in struct proc to "void *p_thrslparg;" to
>> eliminate pointer->long punning in sys_thrsleep() and sys_thrwakeup(). (Thi
> s
>> is required for the next patch (#5) too.)
>
> Why is it necessary? It's an int to make it clear that the kernel
> does not and will not interpret the pointer. That the userland
> interface uses a pointer was done only as a convenience, but in the
> kernel I'd prefer to retain the conversion.
If that's the case, please use a long. Otherwise I32LP64 machines will
loose 1/2 that pointer.
--Toby.
|
| |
|
| |
no comments
|
|
|
Author: hlwhywhlwhyw
Date: May 4, 2008 20:03
I mean that I reserve the original BSD licence.
Except that I append a GPL licence at the end of
BSD licence in source code.
It looks like that:
/*
Copyright 1994-2008 The FreeBSD Project. All
rights reserved.
Redistribution and use in source and binary forms,
with or without modification, are permitted
provided that the following conditions are met:
1. Redistributions of source code must retain
the above copyright notice, this list of
conditions and the following disclaimer.
2. Redistributions in binary form must
reproduce the above copyright notice, this list of
conditions and the following disclaimer in the
documentation and/or other materials provided with
the distribution.
|
| Show full article (2.40Kb) |
|
| |
no comments
|
|
|
Author: Theo de RaadtTheo de Raadt
Date: May 4, 2008 19:51
>Can I port 4.4BSD-Lite's TCP/IP protocol stack
>soure code to my own OS kernel which is GPL
>Licence?
Yes, you can port it.
>I know that 4.4BSD-Lite is BSD Licenced. Is it
>legal to port BSD Licenced code and change it to
>GPL licence?
No. You may never "change" the licence text that another author put
on their work. If it were legal and right to do so, don't you think
some people would immediately delete the GPL from other pieces of
software?
|
| |
|
no comments
|
|
|
Author: hlwhywhlwhyw
Date: May 4, 2008 19:36
Hi, all
Can I port 4.4BSD-Lite's TCP/IP protocol stack
soure code to my own OS kernel which is GPL
Licence?
I know that 4.4BSD-Lite is BSD Licenced. Is it
legal to port BSD Licenced code and change it to
GPL licence?
Kevin Wu
|
| |
|
no comments
|
|
|
Author: Philip GuentherPhilip Guenther
Date: May 4, 2008 18:05
On Sun, May 4, 2008 at 3:19 AM, Mark Kettenis wrote:
>> Date: Sat, 3 May 2008 20:02:10 -0600
>> From: Philip Guenther gmail.com>
>> Redirect kill(getpid(), sig) to the current thread. Make
>> pthread_suspend_np(main_thread) work.>
> I think this isn't quite right. POSIX says for kill(2) that:
>
> "If the value of pid causes sig to be generated for the sending
> process, and if sig is not blocked for the calling thread and if no
> other thread has sig unblocked or is waiting in a sigwait()
> function for sig, either sig or at least one pending unblocked
> signal shall be delivered to the sending thread before kill()
> returns."
Hmm, how does it fail to meet that requirement?
|
| Show full article (2.65Kb) |
|
no comments
|
|
|
Author: Philip GuentherPhilip Guenther
Date: May 4, 2008 15:19
On Sun, May 4, 2008 at 12:03 PM, Ted Unangst gmail.com> wrote:> On 5/3/08, Philip Guenther gmail.com> wrote:>> Change "long p_thrslpid;" in struct proc to "void *p_thrslparg;" to
>> eliminate pointer->long punning in sys_thrsleep() and sys_thrwakeup(). (This
>> is required for the next patch (#5) too.)
>
> Why is it necessary? It's an int to make it clear that the kernel
> does not and will not interpret the pointer. That the userland
> interface uses a pointer was done only as a convenience, but in the
> kernel I'd prefer to retain the conversion.
I changed it so that I could use it as a kernel-space pointer in my
changes to sys_thrsigdivert: I use it to point to the siginfo
structure that will be returned by thrsigdivert (which I morphed into
sigtimedwait()). Thus the reference to patch #5.
Given that the siginfo support in the kernel is effectively only
stubs, providing a sigtimedwait call is probably premature; leaving it
as a long and returning just the signal number via it would be
sufficient for sigwait(). Perhaps I should redo patch #5 to just make
sigwait() work instead of jumping to sigtimedwait()?
|
| Show full article (1.18Kb) |
|
no comments
|
|
|
Author: Philip GuentherPhilip Guenther
Date: May 4, 2008 15:08
On Sun, May 4, 2008 at 11:55 AM, Ted Unangst gmail.com> wrote:> On 5/4/08, Mark Kettenis wrote:
...
>> Do you have any idea on how to fix this properly? I'd like to have
>> some idea about where we're going here, to make sure your diffs don't
>> move us further towards a dead end.
>
> I think we should introduce a new mask field and place it in struct process.
Yeah, that's the start. I got sidelined from doing that while looking
at what it'll take to support correct siginfo values.
Philip Guenther
|
| |
|
no comments
|
|
|
Author: Ted UnangstTed Unangst
Date: May 4, 2008 11:14
On 5/3/08, Philip Guenther gmail.com> wrote:> Change "long p_thrslpid;" in struct proc to "void *p_thrslparg;" to
> eliminate pointer->long punning in sys_thrsleep() and sys_thrwakeup(). (This
> is required for the next patch (#5) too.)
Why is it necessary? It's an int to make it clear that the kernel
does not and will not interpret the pointer. That the userland
interface uses a pointer was done only as a convenience, but in the
kernel I'd prefer to retain the conversion.
|
| |
|
no comments
|
|
|
Author: Ted UnangstTed Unangst
Date: May 4, 2008 11:05
On 5/4/08, Mark Kettenis wrote:
>> (This is not a complete solution, as there's no way to tell the difference
>> between a signal pending for the process and a signal pending for the main
>> thread, so sigwait() in other threads will either handle both or neither
>> of those. The current implementation handles neither, my sigwait() patch
>> changes it to handle them both.)
>
> Do you have any idea on how to fix this properly? I'd like to have
> some idea about where we're going here, to make sure your diffs don't
> move us further towards a dead end.
I think we should introduce a new mask field and place it in struct process.
|
| |
|
no comments
|
|
|
|
|
|
Author: Mark KettenisMark Kettenis
Date: May 4, 2008 02:46
> Date: Sat, 3 May 2008 19:34:57 -0600
> From: Philip Guenther gmail.com>
>
> Move the functionality of psignal() to a new function ptsignal()
> that takes an additional argument "thread" that indicates whether
> the signal is
> 0) for the process as a whole (and can be diverted via sigwait())
> 1) for a particular thread, but should be propagated (e.g., to kill
> the entire process) if not handled by that thread, or
> -1) for a particular thread and must not be propagated
>
> The handling of signals that stop or resume the process is changed to use
> the last of those when propagating the signal to the other threads in the
> process, so that they don't try to propagated it back in an infinite loop.
> Ditto when the process is exiting and the remaining threads need to...
|
| Show full article (1.65Kb) |
|
no comments
|
|
|
|
|
|
|
