>
>
> On Mon, 8 Feb 1999, Alexander Viro wrote:
> >
> > Linus, we have quite a problem with converting NFS idea of rename() into
> > the new scheme. It actively tweaks dcache and IMHO it means that we'ld
> > better shift silly_rename logic into the VFS (for filesystems that do not
> > keep open unlinked files alive).
>
> Oh, don't do anything special for regular open files: only use the
> d_unhash/d_rehash/d_move thing for directories. Leave the NFS regular file
> code as-is..
OK. That solves the problem. BTW, s/regular file/non-directory/. Well,
right now I'm *really* low on caffeine, so I'm going down. I'll probably
finish the thing this evening/next night. I really think that separating
silly_rename() is the Right Thing, but it may wait till 2.3.
Another thing: what do you think about FIFO handling in struct inode?
union {
struct foo a;
struct bar {
int data[BIGGER_THAN_FOO_AND_UNUSED_IF_A_IS_USED];
...
} b;
struct baz {
struct foo fake;
...
} c;
struct quux {
struct foo fake;
...
} d;
struct fred {
struct foo fake;
...
} e;
...
}
doesn't look like correct C for me. And it's exactly what we have in union
within struct inode. foo==pipe_inode_info. Comments? I'ld allocate
pipe_inode_info separately and keep the pointer outside of struct inode.
I've sent a patch somewhere around 2.2.0-pre*... It's about 6K, mostly
removal of fake pipe_inode_info from places where it doesn't belong. It
works here since the end of December, so... BTW, it even doesn't break
binary compatibility - pointer is added to the end of struct inode and
size of pipe_inode_info is smaller than ext2_inode_info, thus the union
size didn't change. Up to you...
Cheers,
Al
-
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/