On Fri, Sep 26, 2008 at 12:49 PM, John Baldwin <[EMAIL PROTECTED]> wrote:
> On Friday 26 September 2008 03:23:22 pm Peter Wemm wrote:
>> peter 2008-09-26 19:23:22 UTC
>>
>> FreeBSD src repository
>>
>> Modified files:
>> include Makefile unistd.h
>> Log:
>> SVN rev 18
On Friday 26 September 2008 03:23:22 pm Peter Wemm wrote:
> peter 2008-09-26 19:23:22 UTC
>
> FreeBSD src repository
>
> Modified files:
> include Makefile unistd.h
> Log:
> SVN rev 183390 on 2008-09-26 19:23:22Z by peter
>
> Move getosreldate(3) prototype fro
peter 2008-09-26 19:23:22 UTC
FreeBSD src repository
Modified files:
include Makefile unistd.h
Log:
SVN rev 183390 on 2008-09-26 19:23:22Z by peter
Move getosreldate(3) prototype from the machine generated
to in the BSD section.
Suggested by: kib
peter 2008-09-26 05:50:08 UTC
FreeBSD src repository
Modified files:
include Makefile
Log:
SVN rev 183378 on 2008-09-26 05:50:08Z by peter
Re-add getosreldate(3) function prototype in the form that I've been using
for quite some time now. While I'm not sure
On Tue, Jun 17, 2008 at 06:26:29AM +, David Xu wrote:
> davidxu 2008-06-17 06:26:29 UTC
>
> FreeBSD src repository
>
> Modified files:
> include Makefile unistd.h
> lib/libc/gen Makefile.inc Symbol.map exec.3 exec.c
> Added files:
> include
On Wed, 18 Jun 2008, Peter Wemm wrote:
Apple's experience has been somewhat to the contrary -- while the
architecture varies some by OS release, one of the persisting performance
problems they were seeing was the cost of fork()+execve() from applications
with very large numbers of shared libra
On Wed, Jun 18, 2008 at 1:16 AM, Robert Watson <[EMAIL PROTECTED]> wrote:
> On Tue, 17 Jun 2008, David Schultz wrote:
>
>> On Tue, Jun 17, 2008, Maxim Sobolev wrote:
>>>
>>> Ed Schouten wrote:
* David Schultz <[EMAIL PROTECTED]> wrote:
>
> I have no objections to this, but doesn't
On Tue, 17 Jun 2008, David Schultz wrote:
On Tue, Jun 17, 2008, Maxim Sobolev wrote:
Ed Schouten wrote:
* David Schultz <[EMAIL PROTECTED]> wrote:
I have no objections to this, but doesn't it defeat the whole purpose to
implement posix_spawn() as a library function that just calls fork/exec?
David Xu wrote:
I just want to make some programs to work, since Linux and Solaris
both have it now. Doing it in kernel is OK, but I don't want to put
it into the kernel until it is necessary since kernel code can not
be swapped out. ;-)
Doing in kernel may have advantages, for example, you may
Maxim Sobolev wrote:
Ed Schouten wrote:
* David Schultz <[EMAIL PROTECTED]> wrote:
I have no objections to this, but doesn't it defeat the whole
purpose to implement posix_spawn() as a library function that just
calls fork/exec?
When (if?) applications start to use posix_spawn() we may decide
John Baldwin wrote:
On Tuesday 17 June 2008 11:15:20 am Maxim Sobolev wrote:
Ed Schouten wrote:
* David Schultz <[EMAIL PROTECTED]> wrote:
I have no objections to this, but doesn't it defeat the whole
purpose to implement posix_spawn() as a library function that just
calls fork/exec?
When (if
On Tue, Jun 17, 2008 at 11:22:40AM -0400, John Baldwin wrote:
> On Tuesday 17 June 2008 11:15:20 am Maxim Sobolev wrote:
> > Ed Schouten wrote:
> > > * David Schultz <[EMAIL PROTECTED]> wrote:
> > >> I have no objections to this, but doesn't it defeat the whole
> > >> purpose to implement posix_spa
On Tue, Jun 17, 2008 at 01:07:55PM -0400, David Schultz wrote:
> On Tue, Jun 17, 2008, Maxim Sobolev wrote:
> > Ed Schouten wrote:
> > >* David Schultz <[EMAIL PROTECTED]> wrote:
> > >>I have no objections to this, but doesn't it defeat the whole
> > >>purpose to implement posix_spawn() as a librar
On Tuesday 17 June 2008 11:15:20 am Maxim Sobolev wrote:
> Ed Schouten wrote:
> > * David Schultz <[EMAIL PROTECTED]> wrote:
> >> I have no objections to this, but doesn't it defeat the whole
> >> purpose to implement posix_spawn() as a library function that just
> >> calls fork/exec?
> >
> > When
On Tue, Jun 17, 2008, Maxim Sobolev wrote:
> Ed Schouten wrote:
> >* David Schultz <[EMAIL PROTECTED]> wrote:
> >>I have no objections to this, but doesn't it defeat the whole
> >>purpose to implement posix_spawn() as a library function that just
> >>calls fork/exec?
> >
> >When (if?) applications
* Maxim Sobolev <[EMAIL PROTECTED]> wrote:
> Are there any benefits of doing it in the kernel vs. doing it via fork+exec?
In theory there should be performance benefits, because there is no need
to fork an entire process. You would only need to handcraft a new one.
--
Ed Schouten <[EMAIL PROTEC
Ed Schouten wrote:
* David Schultz <[EMAIL PROTECTED]> wrote:
I have no objections to this, but doesn't it defeat the whole
purpose to implement posix_spawn() as a library function that just
calls fork/exec?
When (if?) applications start to use posix_spawn() we may decide to move
it into the k
On Tue, Jun 17, 2008 at 09:48:28AM -0400, David Schultz wrote:
> On Tue, Jun 17, 2008, David Xu wrote:
> > davidxu 2008-06-17 06:26:29 UTC
> >
> > FreeBSD src repository
> >
> > Modified files:
> > include Makefile unistd.h
> > lib/libc/gen Makefile.inc Symbo
* David Schultz <[EMAIL PROTECTED]> wrote:
> I have no objections to this, but doesn't it defeat the whole
> purpose to implement posix_spawn() as a library function that just
> calls fork/exec?
When (if?) applications start to use posix_spawn() we may decide to move
it into the kernel at any time
On Tue, Jun 17, 2008, David Xu wrote:
> davidxu 2008-06-17 06:26:29 UTC
>
> FreeBSD src repository
>
> Modified files:
> include Makefile unistd.h
> lib/libc/gen Makefile.inc Symbol.map exec.3 exec.c
> Added files:
> include spawn.h
>
davidxu 2008-06-17 06:26:29 UTC
FreeBSD src repository
Modified files:
include Makefile unistd.h
lib/libc/gen Makefile.inc Symbol.map exec.3 exec.c
Added files:
include spawn.h
lib/libc/gen posix_spawn.c
Log:
SVN rev 1798
ru 2007-10-01 18:07:29 UTC
FreeBSD src repository
Modified files:
include Makefile
Log:
Install the forgotten /usr/include/geom/multipath/ header.
Approved by:re (kensmith)
Revision ChangesPath
1.276 +4 -2 src/include/Makefile
_
pjd 2007-04-13 01:39:33 UTC
FreeBSD src repository
Modified files:
include Makefile
Log:
Install only types.h from sys/rpc/.
Requested by: ache
Explained how by: ru
Revision ChangesPath
1.270 +9 -1 src/include/Makefile
On Thu, Apr 12, 2007 at 06:34:35PM +0200, Pawel Jakub Dawidek wrote:
> On Thu, Apr 12, 2007 at 08:09:18AM +0400, Andrey Chernov wrote:
> > On Wed, Apr 11, 2007 at 10:11:22PM +0200, Pawel Jakub Dawidek wrote:
> > > sys/rpc/types.h is installed in /usr/include/rpc/. What's the problem
> > > exactly?
On Thu, Apr 12, 2007 at 08:09:18AM +0400, Andrey Chernov wrote:
> On Wed, Apr 11, 2007 at 10:11:22PM +0200, Pawel Jakub Dawidek wrote:
> > sys/rpc/types.h is installed in /usr/include/rpc/. What's the problem
> > exactly?
>
> At least one problem found: due to your change kernel-only
> rpcclnt.h
>
On Thu, Apr 12, 2007 at 12:24:04AM +0400, Andrey Chernov wrote:
> f.e. unistd.h and sys/unistd.h separated, but no problems with it for now.
On no, one problem found, see my prev reply.
--
http://ache.pp.ru/
pgp8bTNEtUgJn.pgp
Description: PGP signature
On Wed, Apr 11, 2007 at 10:11:22PM +0200, Pawel Jakub Dawidek wrote:
> sys/rpc/types.h is installed in /usr/include/rpc/. What's the problem
> exactly?
At least one problem found: due to your change kernel-only
rpcclnt.h
rpcm_subs.h
are now installed into userland /usr/include/rpc
Please fix it so
On Wed, Apr 11, 2007 at 10:11:22PM +0200, Pawel Jakub Dawidek wrote:
> sys/rpc/types.h is installed in /usr/include/rpc/. What's the problem
> exactly?
I realize. See my 2nd followup. In few words I prefer to separate them as
f.e. unistd.h and sys/unistd.h separated, but no problems with it for n
On Wed, Apr 11, 2007 at 09:45:28PM +0400, Andrey Chernov wrote:
> On Tue, Apr 10, 2007 at 10:10:17PM +, Pawel Jakub Dawidek wrote:
> > pjd 2007-04-10 22:10:16 UTC
> >
> > FreeBSD src repository
> >
> > Modified files:
> > include Makefile
> > include/rpc
On Wed, Apr 11, 2007 at 09:45:28PM +0400, Andrey Chernov wrote:
>
> Better way is to keep rpc/types.h and include sys/rpc/types.h in it.
Well I see it installed to /usr/include/rpc from /sys/rpc now.
Still better way I mention above, to separate possible userland addition
to /usr/include/rpc/typ
On Tue, Apr 10, 2007 at 10:10:17PM +, Pawel Jakub Dawidek wrote:
> pjd 2007-04-10 22:10:16 UTC
>
> FreeBSD src repository
>
> Modified files:
> include Makefile
> include/rpc Makefile
> sys/rpc types.h
> Removed files:
> incl
pjd 2007-04-10 22:10:16 UTC
FreeBSD src repository
Modified files:
include Makefile
include/rpc Makefile
sys/rpc types.h
Removed files:
include/rpc types.h
Log:
Move rpc/types.h under sys/, as this is used by ZFS ke
peter 2007-01-25 22:38:05 UTC
FreeBSD src repository
Modified files:
include Makefile
Log:
Oops, remove an objformat.h reference.
Revision ChangesPath
1.267 +1 -1 src/include/Makefile
___
cvs-all@free
trhodes 2006-11-11 16:26:58 UTC
FreeBSD src repository
Modified files:
include Makefile
sys Makefile
sys/compat/linux linux_misc.c
sys/conf files
sys/i386/ibcs2 ibcs2_proto.h ibcs2_xenix.h
sys/i386/linux
ru 2006-10-06 08:27:07 UTC
FreeBSD src repository
Modified files:
include Makefile
sbin/geom/class Makefile
sys/modules/geom Makefile
etc/mtreeBSD.include.dist
Added files:
sbin/geom/class/cache Makefile geom_cache.c
sy
On Sun, 2006-06-25 at 07:35 +, Poul-Henning Kamp wrote:
> phk 2006-06-25 07:35:51 UTC
>
> FreeBSD src repository
>
> Modified files:(Branch: RELENG_6)
> include Makefile
> lib/libc/stdio Makefile.inc vfprintf.c vfscanf.c
>
phk 2006-06-25 07:35:51 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_6)
include Makefile
lib/libc/stdio Makefile.inc vfprintf.c vfscanf.c
vfwprintf.c vfwscanf.c
Added files: (Branch: RELENG_6)
ume 2006-03-30 20:15:53 UTC
FreeBSD src repository
Modified files:
include Makefile
lib/libc/net Symbol.map res_mkupdate.c res_update.c
lib/libc/resolv Symbol.map res_data.c
Added files:
include res_update.h
Removed files:
jasone 2006-03-28 22:16:04 UTC
FreeBSD src repository
Modified files:
include Makefile
lib/libc/stdlib Makefile.inc Symbol.map malloc.3 malloc.c
Added files:
include malloc_np.h
Log:
Add malloc_usable_size(3).
Discussed with:
ru 2006-03-10 11:07:39 UTC
FreeBSD src repository
Modified files:
include Makefile
Log:
Hopefully fix all nearby style bugs that Bruce has mentioned.
Revision ChangesPath
1.256 +8 -8 src/include/Makefile
_
ru 2006-03-10 11:00:12 UTC
FreeBSD src repository
Modified files:
include Makefile
Log:
- Fix variable assignment to be portable.
- "Line up" continuations.
Submitted by: bde
Revision ChangesPath
1.255 +6 -6 src/include/Makefile
___
phk 2005-12-16 18:56:39 UTC
FreeBSD src repository
Modified files:
include Makefile
lib/libc/stdio Makefile.inc vfprintf.c
Added files:
include printf.h
lib/libc/stdio xprintf.c xprintf_float.c
xprint
ru 2005-12-01 21:46:01 UTC
FreeBSD src repository
Modified files:
include Makefile
Log:
Install the mqueue.h header.
Revision ChangesPath
1.252 +2 -1 src/include/Makefile
___
cvs-all@freebsd.org ma
rodrigc 2005-11-28 03:21:58 UTC
FreeBSD src repository
Modified files:
include Makefile
Log:
Remove commented out reference to posix4/mqueue.h. It hasn't been installed
for 3 years, and now we have another (working) implementation
of POSIX message queues elsewhe
ru 2005-11-16 10:50:12 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_6)
include Makefile
etc/mtreeBSD.include.dist
sys/modules Makefile
games/morse Makefile morse.c
share/man/man4 Makefile
delphij 2005-11-11 16:48:01 UTC
FreeBSD src repository
Modified files:
include Makefile
Log:
Since speaker.h now lives in sys/dev/speaker, reflect this fact here.
Revision ChangesPath
1.250 +1 -1 src/include/Makefile
_
46 matches
Mail list logo
