FreeLists / openbeosstorage / [openbeosstorage] Re: BNode:set_fd and other things

[Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>]

On Sat, 13 Apr 2002, Tyler Dauwalder wrote:

> > I wonder, if BDirectory::fDir/fDirFd will be needed at all. At least until
> > now I see no reason, why the file descriptor used by BDirectory should be
> > a different one than that of BNode. Perhaps I'm missing something, but
> > I will see as soon as the test suite is done and the class is implemented.
> > However, friend classes will use get_fd() anyway.
> 
> Yes, I know what you mean. I haven't done any tests to figure out
> whether or not it's necessary.

That leads to the general question of integration tests. Some tests of
this kind are already included in the unit tests, but e.g. in the case of
BFile or BDirectory I don't test any inherited functionality. Perhaps some
of the base class (BNode, BEntryList,...) tests can be made reusable for
derived classes? E.g. providing a function that takes a pointer to a base
class instance and performs tests on it.

> I say try to implement it using BNode::get_fd(). Make sure none of the
> public BNode functions (i.e. reading an attribute value with
> BNode::ReadAttr() or something like that) disrupt the internal directory
> pointer or anything else BDirectory would use that would be associated
> with the file descriptor. If everything looks okay, we'll just go with
> that. If you find something that doesn't work right, we can just switch
> back to using BDirectory::fDirFd. 

Yep, I'll do that.

> > Just to be sure: StorageKit::FileDescriptor will be the (only) type we'll
> > use in the SK classes. Correct?
> 
> Maybe :-). See my "Kernel Interface Typedefs" message. I'm not sure I
> see what we gain by getting rid of the other typedefs. It's admittedly
> an option now, though, since we can use FileDescriptors everywhere.

Err, well, I don't think, that that was, what I meant here.
But I have to admit, that I don't know any longer, what I meant ;-)
I guess, it was only the observation, that the only StorageKit:: type
appearing in header files would be StorageKit::FileDescriptor.
Sounds quite insignificant, huh? ;-)

> > And StorageKit::Dir will disappear and directory file descriptors will be
> > treated as any other file descriptor. Also correct?
> 
> Yes. I'm working on making that happen (sorry it's taking so long).

No problem.
I've implemented most of the tests for BDirectory and will certainly
finish the missing ones today. While doing the BDirectory implementation I
will modify all things that are needed to make it compile (and, to a
certain extend, run) properly...

CU, Ingo