> > It would be nice if you'ld show how _exactly_ you are going to use
> > get_empty_filp(). There are several reasons to split inuse_filp into
> > several lists (for superblock; for tty; for protocol family). That would
> > simplify dquot.c and some nasty stuff in tty_io.c. Right now I'm
> > experimenting with such patch and if everything will go OK I'm going to
> > submit it to Linus in a day or two. We got waaay too many leaks/dangling
> > pointers/etc. in the code that deals with struct file's. I'm trying to go
> > through this stuff and massage it into something more coherent. And IMHO
> > get_empty_filp() belongs to guts of that stuff.
>
> First, do you have any objections against the export of the
> get_unused_fd() call?
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.
> Regarding the get_empty_filp(), I'm simply using it for allocating a
> struct file. The struct file gets filled in, and fd_install (this
> symbol is exported, wow) is then used to put things where they should
> be.
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...
HTH. HAND,
Al
-- "You're one of those condescending Unix computer users!" "Here's a nickel, kid. Get yourself a better computer" - Dilbert.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/