[349] in arla-drinkers
Re: get_unused_fd()
daemon@ATHENA.MIT.EDU (Magnus Ahltorp)
Sat Oct 24 08:57:26 1998
From owner-arla-drinkers@stacken.kth.se Sat Oct 24 12:57:25 1998
Return-Path: <owner-arla-drinkers@stacken.kth.se>
Delivered-To: arla-drinkers-mtg@bloom-picayune.mit.edu
Received: (qmail 4100 invoked from network); 24 Oct 1998 12:57:24 -0000
Received: from unknown (HELO sundance.stacken.kth.se) (130.237.234.41)
by bloom-picayune.mit.edu with SMTP; 24 Oct 1998 12:57:24 -0000
Received: (from majordom@localhost)
by sundance.stacken.kth.se (8.8.8/8.8.8) id OAA00127
for arla-drinkers-list; Sat, 24 Oct 1998 14:52:23 +0200 (MET DST)
Received: from scup.pdc.kth.se (scup.pdc.kth.se [130.237.221.66])
by sundance.stacken.kth.se (8.8.8/8.8.8) with ESMTP id OAA00123
for <arla-drinkers@stacken.kth.se>; Sat, 24 Oct 1998 14:52:18 +0200 (MET DST)
Received: (from d95-mah@localhost)
by scup.pdc.kth.se (8.8.7/8.8.7) id OAA06127;
Sat, 24 Oct 1998 14:52:13 +0200 (MET DST)
To: Alexander Viro <viro@math.psu.edu>
Cc: Linus Torvalds <torvalds@transmeta.com>, linux-kernel@vger.rutgers.edu,
arla-drinkers@stacken.kth.se
Subject: Re: get_unused_fd()
References: <Pine.SOL.3.95.981022021110.2309A-100000@albert.math.psu.edu>
From: Magnus Ahltorp <map@stacken.kth.se>
Date: 24 Oct 1998 13:52:12 +0100
In-Reply-To: Alexander Viro's message of Thu, 22 Oct 1998 02:34:15 -0400 (EDT)
Message-ID: <ixd3e8e5dhf.fsf@scup.pdc.kth.se>
Lines: 31
X-Mailer: Gnus v5.3/Emacs 19.34
Sender: owner-arla-drinkers@stacken.kth.se
Precedence: bulk
> Umm... Say it, I'ld like to see reasons for that and they'ld
> better be very serious. Anyway, it's up to Linus to make any decisions on
> that stuff. Exporting something makes it much more permanent. If symbol is
> available only from the kernel - well, one has to consider kernel alone
> when/if he'll want to change it. If it is exported... any change may break
> 3rd-party modules. Any additional exported symbol to == potential boat
> anchor.
The policy seems to be "if we have a module in the _mainstream_ kernel
that uses a symbol, let's export it", and not "if there is a need for
a symbol, let's export it".
> Wait a bit. If you have dentry and want to fit a struct file atop
> of it - you don't need either get_unused_fd() or get_empty_filp(). There
> is open_dentry() (fs/exec.c; exported). It looks like cleaner solution.
> OTOH you didn't describe your problem, so...
I looked at that function, and it solves the _current_ problem I have,
yes. But what is the real problem of modules allocating space in the
file descriptor table? And, how am I to know that it is boat anchorish
to use a plain simple space allocation function, and it is not
anchorish to use a function that only exists to serve different
binfmts?
Would open_dentry() be exported if binfmts didn't exist as modules? I
doubt so. There isn't even a comment above open_dentry that says "use
this function if...", and that _really_ leads to boat anchorish
behaviour. Documentation, not restriction, is needed.
/Magnus
map@stacken.kth.se
