Here are some of the points about Martin's implementation of BFS.
I would like to defend my implementation vs Martin's:
1. hardcoded constants for things like BFS_DIRENT_SIZE/BFS_NAME_LEN
2. further away from being fully read-write than my version.
3. implements readpage. why? a trivial getblk does suffice at present.
4. implements mmap whilst the native UW7 BFS is not able to do mmap.
Being better is usually good but not when it means being incompatible.
Applications have the right to expect that mmap(2) on a BFS file will
fail.
5. uses old style d_alloc_root(). My simple patch removing the second
argument went into 2.3.x ages ago. Similar point applies to having bmap()
instead of new style getblk in inode_operations.
6. statfs(2) doesn't calculate free blocks correctly. Neither does it
calculate free inodes. Mine does both.
7. read_inode() doesn't validate ino being in range.
8. read_super() calls d_alloc_root(iget()..) which has a leak. Should check for
both iget() and d_alloc_root() to fail. (if iget() succeeds but d_alloc()
fails we leaked inode)
9. bfs_lookup() should check the max namelen, having bfs_find_entry()
return 0 is not good enough, we need ERR_PTR(-ENAMETOOLONG) from lookup()
level.
10. Needs porting from 2.3.2 to 2.3.21. (well, it is the same point
as 5. really)
On the good side - it pointed to me that I forgot CONFIG_EXPERIMENTAL around
the CONFIG_BFS_FS in Config.in so I put it in my patch and made a next release:
http://www.avnet.co.uk/~ely/bfs-2.3.21b.patch.gz
(sorry - no access to ocston.org from home - so I put it on my wife's wwww).
No doubt there are lots of useful things I can borrow both from Andries' and
Martin's implementations - I will study both in greater detail (and
possibly start stealing their code (joke!)) tomorrow.
Yours faithfully,
Tigran.
PS. Of course, both Andries and Martin deserve much more credit than me -
for they have done their work based only on their incredible hacker's
talents, while I always had access to the source code.
PPS. On a related note, my code contains no proprietary source of SCO or
anyone else so (Linus), please do include it (if it finds favour in your
eyes) in Linux under the standard (GPL v2) copyright. (My superiors at
work do not object to my contributions to Linux (in spare time)).
-
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/