Source-Changes-HG archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

[src/trunk]: src/sys/ntfs add more items, correct a few sentences



details:   https://anonhg.NetBSD.org/src/rev/f346fc605baa
branches:  trunk
changeset: 475936:f346fc605baa
user:      jdolecek <jdolecek%NetBSD.org@localhost>
date:      Mon Aug 30 11:33:41 1999 +0000

description:
add more items, correct a few sentences

diffstat:

 sys/ntfs/TODO |  16 ++++++++++------
 1 files changed, 10 insertions(+), 6 deletions(-)

diffs (39 lines):

diff -r 286fd1889ecb -r f346fc605baa sys/ntfs/TODO
--- a/sys/ntfs/TODO     Mon Aug 30 07:59:19 1999 +0000
+++ b/sys/ntfs/TODO     Mon Aug 30 11:33:41 1999 +0000
@@ -13,21 +13,20 @@
 - cleanup the mess with several *readattr*() functions if possible
 
 - avoid allocation temporary buffer to hold result of read()/data
-  to be written in ntfs_read() & ntfs_write(): it's very easy
-  to panic the kernel that way, with simple
-       read(open(...), NULL, some_very_big_number);
-  The data should be transfered directly to the user buffer
+  to be written in ntfs_read() & ntfs_write() - besides being
+  unefficient, the user is able to panic the kernel with simple
+  open()/lseek()/read() sequence.
        (from Chuq)
   * finishing testing, even gained about 3-5% performance improvement
     for simple cat file >/dev/null test
 
-- ntfs_ntvattrget() identify if it's worth the efford to use some hashing
+- ntfs_ntvattrget(): find out if it's worth the efford to use some hashing
   for the list of ntnodes, so that it's not all scanned each time; it would
   be fine to migrate the found ntnode towards the start of the list too;
   the list search code is duplicated on two places, eliminate the duplicity
   somehow
   
-- convert to code to do caching in buffer cache indexed by
+- convert the code to do caching in buffer cache indexed by
   file-vnode/file-offset so that NTFS would take advantage of UBC;
   it should also improve performance somewhat, because if it's necessary
   to find some offset in a file, it's possible to check if the data
@@ -36,3 +35,8 @@
 
 - working VOP_BALLOC()
        (from Chuq)
+
+- add pathconf(2) support
+       (from Klaus Klein)
+
+- make ntfs exportable, for the completeness sake



Home | Main Index | Thread Index | Old Index