|
From: Yury U. <um...@na...> - 2003-02-24 16:57:55
|
Hello Anton, As you probably know from Andrew Clausen reiser4progs project contains package called libaal (not very clear and will be renamed soon) which contains device abstraction layer code. It was introduced from the libreiserfs used in GNU Parted. In two words, it allows any filesystem library access device in an enviromnent independant maner. Consider possible libntfs appliactions and you will understand, that it is needed to access ntfs partition: (1) from the DOS (some dos utilities like TestDisk) (2) from the "alone" mode (some bootloaders might be use libntfs for providing ntfs support, for instance GRUB, MILO) (3) from the usual UNIX enviromnent by means of using device name like /dev/hd* or uuid/label, etc. All these device access patterns should be implemennted in not the same way. One of them will use DOS interrupts for accessing sectors, another one will use usual read() and write() and so on. Device abstraction layer is supposed to solve all these differences in implementation by means of using installable device operations. Andrew's idea is to move libaal into separate library, add libblkid functionality to it (Andreas Dilger's library for identifying devices by their uuid and label) and make it available for any filesystem tools and libraries. If you're intersted in, please take a look at http://thebsh.namesys.com/snapshots/2003.02.13/reiser4progs-20030224.tar.gz And files you should look at them are the following: include/aal/device.h libaal/device.c include/aal/file.h libaal/file.c What do you think about that? |
|
From: Anton A. <ai...@ca...> - 2003-02-24 18:58:24
|
Hi, On Mon, 24 Feb 2003, Yury Umanets wrote: > As you probably know from Andrew Clausen reiser4progs project contains > package called libaal (not very clear and will be renamed soon) which > contains device abstraction layer code. It was introduced from the > libreiserfs used in GNU Parted. > > In two words, it allows any filesystem library access device in an > enviromnent independant maner. Consider possible libntfs appliactions > and you will understand, that it is needed to access ntfs partition: > > (1) from the DOS (some dos utilities like TestDisk) > (2) from the "alone" mode (some bootloaders might be use libntfs for > providing ntfs support, for instance GRUB, MILO) > (3) from the usual UNIX enviromnent by means of using device name like > /dev/hd* or uuid/label, etc. > > All these device access patterns should be implemennted in not the same > way. One of them will use DOS interrupts for accessing sectors, another > one will use usual read() and write() and so on. Device abstraction > layer is supposed to solve all these differences in implementation by > means of using installable device operations. > > Andrew's idea is to move libaal into separate library, add libblkid > functionality to it (Andreas Dilger's library for identifying devices by > their uuid and label) and make it available for any filesystem tools and > libraries. > > If you're intersted in, please take a look at > http://thebsh.namesys.com/snapshots/2003.02.13/reiser4progs-20030224.tar.gz > > And files you should look at them are the following: > > include/aal/device.h > libaal/device.c > include/aal/file.h > libaal/file.c > > What do you think about that? I had that in mind when I wrote libntfs. The only file in libntfs that does any kind of direct low-level I/O is disk_io.c. Everything else uses logical functions exported by disk_io.c. The only functions affected in disk_io.c are: ntfs_pread() and ntfs_pwrite(), as well as ntfs_device_size_get(), and ntfs_device_offset_valid() which is only used by ntfs_device_size_get(). All other disk_io.c functions build upon those, so are again completely device independent. The only other place device dependent functions are used is in volume.c in ntfs_mount() and ntfs_umount() where we open() and close() the device/file. It has always been my intention to abstract the low level access from the library with the same reasons as you describe. It's just that it never needed to happen / it is low priority which is why I didn't go any further than I have already. As you can see doing the abstraction for libntfs is a completely trivial undertaking... Edit the above functions and you are done pretty much... So if someone really creates a stand alone library which is GPLor LGPL, efficient and easy to use then yes, sure, we may well switch to using it for libntfs. Alternatively we will eventually have our own way of virtualising the low level device access. In either case it is very low priority for me so you won't be seeing me doing anything along those lines in the near future. I am happy to accept patches of course. (-: Best regards, Anton -- Anton Altaparmakov <aia21 at cantab.net> (replace at with @) Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/ |
|
From: Yury U. <um...@na...> - 2003-02-24 19:40:08
|
Anton Altaparmakov wrote: >Hi, > >On Mon, 24 Feb 2003, Yury Umanets wrote: > > >>As you probably know from Andrew Clausen reiser4progs project contains >>package called libaal (not very clear and will be renamed soon) which >>contains device abstraction layer code. It was introduced from the >>libreiserfs used in GNU Parted. >> >>In two words, it allows any filesystem library access device in an >>enviromnent independant maner. Consider possible libntfs appliactions >>and you will understand, that it is needed to access ntfs partition: >> >>(1) from the DOS (some dos utilities like TestDisk) >>(2) from the "alone" mode (some bootloaders might be use libntfs for >>providing ntfs support, for instance GRUB, MILO) >>(3) from the usual UNIX enviromnent by means of using device name like >>/dev/hd* or uuid/label, etc. >> >>All these device access patterns should be implemennted in not the same >>way. One of them will use DOS interrupts for accessing sectors, another >>one will use usual read() and write() and so on. Device abstraction >>layer is supposed to solve all these differences in implementation by >>means of using installable device operations. >> >>Andrew's idea is to move libaal into separate library, add libblkid >>functionality to it (Andreas Dilger's library for identifying devices by >>their uuid and label) and make it available for any filesystem tools and >>libraries. >> >>If you're intersted in, please take a look at >>http://thebsh.namesys.com/snapshots/2003.02.13/reiser4progs-20030224.tar.gz >> >>And files you should look at them are the following: >> >>include/aal/device.h >>libaal/device.c >>include/aal/file.h >>libaal/file.c >> >>What do you think about that? >> >> > >I had that in mind when I wrote libntfs. The only file in libntfs that >does any kind of direct low-level I/O is disk_io.c. Everything else uses >logical functions exported by disk_io.c. The only functions affected in >disk_io.c are: > ntfs_pread() and ntfs_pwrite(), as well as > ntfs_device_size_get(), and ntfs_device_offset_valid() which is > only used by ntfs_device_size_get(). >All other disk_io.c functions build upon those, so are again completely >device independent. The only other place device dependent functions are >used is in volume.c in ntfs_mount() and ntfs_umount() where we open() and >close() the device/file. > > >It has always been my intention to abstract the low level access from the >library with the same reasons as you describe. It's just that it never >needed to happen / it is low priority which is why I didn't go any further >than I have already. > > >As you can see doing the abstraction for libntfs is a completely trivial >undertaking... Edit the above functions and you are done pretty much... > > >So if someone really creates a stand alone library which is GPLor >LGPL, > Yes it GPL or LGPL I should ask Hans for exact licence (reiser4progs is under GPL). And yes again, it will be standalone library. > efficient and easy to use then yes, sure, we may well switch to >using it for libntfs. > This is the main answer I expected to see :) >Alternatively we will eventually have our own way of >virtualising the low level device access. In either case it is very low >priority for me so you won't be seeing me doing anything along those >lines in the near future. I am happy to accept patches of course. (-: > Okay, thanks for answer :) > >Best regards, > > Anton > > |
