On Monday 16 July 2007 02:25:37 pm Julian Elischer wrote:
> Peter Jeremy wrote:
> > On 2007-Jul-15 16:51:38 -0700, Julian Elischer <[EMAIL PROTECTED]>
wrote:
> >>> void
> >>> closefrom(int lowfd)
> >>> {
> >>> fcntl(lowfd, F_CLOSEM, NULL);
> >>> }
> >> what on earth would that achieve?
> >> (as
Peter Jeremy wrote:
On 2007-Jul-15 16:51:38 -0700, Julian Elischer <[EMAIL PROTECTED]> wrote:
void
closefrom(int lowfd)
{
fcntl(lowfd, F_CLOSEM, NULL);
}
what on earth would that achieve?
(as opposed to just a simple syscall)
The only benefit I can think of is minimising the number of
On 2007-Jul-15 16:51:38 -0700, Julian Elischer <[EMAIL PROTECTED]> wrote:
>> void
>> closefrom(int lowfd)
>> {
>> fcntl(lowfd, F_CLOSEM, NULL);
>> }
>
>what on earth would that achieve?
>(as opposed to just a simple syscall)
The only benefit I can think of is minimising the number of syscalls
* Julian Elischer <[EMAIL PROTECTED]> wrote:
> Ed Schouten wrote:
>> Woops! Sorry for responding this late, but it looks like I didn't
>> explain myself good enough. Sorry. :) To rephrase myself:
>> Wouldn't it be better to just implement fcntl(..., F_CLOSEM, ...) in the
>> kernel and make closefro
Ed Schouten wrote:
* Julian Elischer <[EMAIL PROTECTED]> wrote:
Ed Schouten wrote:
Wouldn't it be better to just implement it through fcntl() and implement
closefrom() in libc?
that's a possibility but I personally thing the huge difference in
efficiency
makes it worth putting it in the kerne
* Julian Elischer <[EMAIL PROTECTED]> wrote:
> Ed Schouten wrote:
>> Wouldn't it be better to just implement it through fcntl() and implement
>> closefrom() in libc?
>
> that's a possibility but I personally thing the huge difference in
> efficiency
> makes it worth putting it in the kernel.
> Qui
On Tue, Jul 10, 2007 at 10:53:02AM -0700, Julian Elischer wrote:
> Joerg Sonnenberger wrote:
> >On Mon, Jul 09, 2007 at 11:46:14PM -0400, Ighighi wrote:
> >>Calling F_MAXFD everytime we close a file descriptor would be heavy
> >>having too much fd's.
> >>On the other hand, it wouldn't make much a
Matthew Dillon wrote:
We added it basically because doing all the junk described in
previous postings in this thread in userland is a ridiculously huge
eyesore that doesn't scale and doesn't make sense when 5 minutes of
programming nets you a shiny new system call which does it al
We added it basically because doing all the junk described in
previous postings in this thread in userland is a ridiculously huge
eyesore that doesn't scale and doesn't make sense when 5 minutes of
programming nets you a shiny new system call which does it all for you.
If you a
On Fri, 6 Jul 2007, LI Xin wrote:
To RW: I have not found a suitable audit event for this, should I create a
new event?
BTW, I can add an AUE_CLOSEFROM event to OpenBSM. This may require a little
work by event consumers who will now need to know about an additional source
of implicit clos
Joerg Sonnenberger wrote:
On Mon, Jul 09, 2007 at 11:46:14PM -0400, Ighighi wrote:
Calling F_MAXFD everytime we close a file descriptor would be heavy
having too much fd's.
On the other hand, it wouldn't make much a difference to just start from
getdtablesize() - 1.
I fully agree. That is the
On Mon, Jul 09, 2007 at 11:46:14PM -0400, Ighighi wrote:
> Calling F_MAXFD everytime we close a file descriptor would be heavy
> having too much fd's.
> On the other hand, it wouldn't make much a difference to just start from
> getdtablesize() - 1.
I fully agree. That is the second version of cl
>Date: Mon, 09 Jul 2007 15:00:21 +0800
>From: LI Xin <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
>Subject: Re: add closefrom() call
>To: Robert Watson <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
>Cc: FreeBSD Hackers <mailto:freebsd-hackers@freeb
Robert Watson wrote:
> The Solaris implementation appears to implement two strategies:
>
> (1) If procfs is mounted, list the fd directory to get a list of open fds,
> then close those by number.
>
> (2) If procfs is not mounted, query the number of open fds using the
> resource
> limit i
On Jul 6, 2007, at 9:57 AM, Julian Elischer wrote:
Robert Watson wrote:
On Fri, 6 Jul 2007, Julian Elischer wrote:
Ed Schouten wrote:
* LI Xin <[EMAIL PROTECTED]> wrote:
Here is my implementation for FreeBSD. Some difference between
my and DragonFly's implementation:
- closefrom(-1) wo
Robert Watson wrote:
On Fri, 6 Jul 2007, Julian Elischer wrote:
Ed Schouten wrote:
* LI Xin <[EMAIL PROTECTED]> wrote:
Here is my implementation for FreeBSD. Some difference between my
and DragonFly's implementation:
- closefrom(-1) would be no-op on DragonFly, my version would close
al
On Fri, 6 Jul 2007, Julian Elischer wrote:
Ed Schouten wrote:
* LI Xin <[EMAIL PROTECTED]> wrote:
Here is my implementation for FreeBSD. Some difference between my and
DragonFly's implementation:
- closefrom(-1) would be no-op on DragonFly, my version would close all
open files (From my
Ed Schouten wrote:
* LI Xin <[EMAIL PROTECTED]> wrote:
Here is my implementation for FreeBSD. Some difference between my and
DragonFly's implementation:
- closefrom(-1) would be no-op on DragonFly, my version would close all
open files (From my understanding of OpenSolaris's userland
implemen
On Wed, Jul 04, 2007 at 08:27:49PM -0400, Ighighi Ighighi wrote:
> It is implemented with the F_CLOSEM fcntl() available since version 2.0.
I don't like the fcntl(2) approach as it applies actions to more than
the passed in fd. That feels like an interface abuse.
Joerg
___
On Fri, Jul 06, 2007 at 06:18:14PM +0800, LI Xin wrote:
> - closefrom(-1) would be no-op on DragonFly, my version would close all
> open files (From my understanding of OpenSolaris's userland
> implementation, this is Solaris's behavior).
I think this is a bad idea as -1 is generally an invalid f
On Fri, Jul 06, 2007 at 12:50:17PM +0100, Robert Watson wrote:
> Solaris side-steps this issue by simply auditing the individual close()
> system calls. My preference would be that we implement this in user space
> also, which would likewise generate a series of audit events, one for each
> sys
LI Xin wrote:
Here is my implementation for FreeBSD. Some difference between my and
DragonFly's implementation:
- closefrom(-1) would be no-op on DragonFly, my version would close all
open files (From my understanding of OpenSolaris's userland
implementation, this is Solaris's behavior).
- my
On Fri, 6 Jul 2007, LI Xin wrote:
Joerg Sonnenberger wrote:
On Wed, Jul 04, 2007 at 08:27:49PM -0400, Ighighi Ighighi wrote:
The closefrom() call, available in Solaris, is present in NetBSD since
version 3.0. It is implemented with the F_CLOSEM fcntl() available since
version 2.0.
You co
* LI Xin <[EMAIL PROTECTED]> wrote:
> Here is my implementation for FreeBSD. Some difference between my and
> DragonFly's implementation:
>
> - closefrom(-1) would be no-op on DragonFly, my version would close all
> open files (From my understanding of OpenSolaris's userland
> implementation, th
Hi,
Joerg Sonnenberger wrote:
> On Wed, Jul 04, 2007 at 08:27:49PM -0400, Ighighi Ighighi wrote:
>> The closefrom() call, available in Solaris, is present in NetBSD since
>> version 3.0.
>> It is implemented with the F_CLOSEM fcntl() available since version 2.0.
>
> You could also add a system ca
On Wed, Jul 04, 2007 at 08:27:49PM -0400, Ighighi Ighighi wrote:
> The closefrom() call, available in Solaris, is present in NetBSD since
> version 3.0.
> It is implemented with the F_CLOSEM fcntl() available since version 2.0.
You could also add a system call like it was done in DragonFly. That
m
Ighighi Ighighi wrote:
> The closefrom() call, available in Solaris, is present in NetBSD since
> version 3.0.
> It is implemented with the F_CLOSEM fcntl() available since version 2.0.
I think it might worth an effort (sendmail and perhaps some part of JDK
uses it IIRC), but I do not want to rush
27 matches
Mail list logo
