On Fri, Dec 20, 2002 at 06:21:47AM +0100, Szakacsits Szabolcs wrote:
> > * it should be possible for users of libntfs to pass their own IO
> > abstraction (rather than using the kernel's or file system's)
>
> Just curious, why do you need it? For me it would be very useful for
> testing/debugging purposes.
It's a rather contentious issue:
"Should volume management tools be independent of their
hosting operating system?"
Should it be possible for a (userland) volume management system to
manipulate software RAID + partition table + LVM + file system, without
any help from the kernel (other than physical HD IO)?
If the answer is yes, then you definitely need user-defined I/O
abstractions.
I'm not really sure what the answer is, but since it's easy enough
to implement, you may as well...
> > * error handling doesn't look to good :/
>
> Yes, more info where errors happen (both DEBUG and release version),
> debug levels (also both DEBUG and release version) and not mixing
> stderr/stdout in DEBUG would be really nice(/important).
Also, you want to be able to ask users how to resolve problems.
> > * all the functionality of userland tools should be in libntfs, or
> > perhaps libntfs-mkfs, etc. (This is already on your TODO :)
>
> I'm already doing this for the resizer along with the cluster
> relocation support, as time allows. But I don't plan to do for
> other things.
It's just a time problem? ("for other things")
> > I think reiser4's (as opposed to reiser3's!) userland implementation
> > is fantastic... take a look!
> > www.namesys.com/snapshots/2002.12.04
>
> Thanks, I will. I'm interested getting an ntfs resizer into parted
> [it's one of the items in ntfsresize faq] .
BTW, it comes with a libaal ("abstract application layer"). I
think everything this library provides is useful for libntfs, and
I think libntfs should use it. That said, you might not like the
interface / implementation, but conflict between different users of
a library is how you get reusable code ;)
Cheers,
Andrew
|