Mail Archives: djgpp-workers/2000/12/26/12:11:35
> From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
> Date: Tue, 26 Dec 2000 11:39:30 +0100
>
> > - How would an application register and deregister entries in
> > practice? In what directory (or directories) will those entries be
> > visible, and what API does an application need to control this?
> An fsext_open hook would call register (name, fd). An fsext_close hook
> would then deregister an entry by fd. No API should be required outside
> of this.
The above just passes the name of the file, not the directory where it
``lives''.
Also, alld /dev/* devices supported now don't have an associated
fsext. So not only an fsext will need this.
> > - Can fake entries be registered before an opendir call for their
> > parent directory? Can they be deregistered before closedir is
> > called?
> Yes, but that would not have an effect - the list of fake entries is
> added to the DIR structure during opendir and is not changed.
Again, this doesn't go along with the current ``emulation'' of
/dev/null and other devices: they are always present.
What about the /dev/ directory itself? It doesn't really exist, so
some means are required to make opendir think it does.
> > Anyway, I'm not sure what is the bug you are trying to solve. Can you
> > give an example of a series of calls to opendir, readdir, telldir, and
> > seekdir where the current implementation fails?
> D = opendir ("/"); // has entries: foo, bar, hello, world and xyzzy
> readdir (D); // '.'
> readdir (D); // '..'
> readdir (D); // 'foo'
> readdir (D); // 'bar'
> readdir (D); // 'hello'
> readdir (D); // 'world'
> pos = telldir(D); // pos gets 4, as that's the number of real entries read
> seekdir (D, pos); // rewinds, calles readdir pos times
This could be solved by replacing this code:
rewinddir(dir);
for (i=0; i<loc; i++)
readdir(dir);
with this:
rewinddir(dir);
while (dir->num_read <= loc)
readdir(dir);
[For some reason, I thought seekdir already did that, that's why I
didn't understand what problem you were talking about.]
> > I also don't understand why do you need both fsext_entries and
> > fsext_entry, since they both are used to index into the same array.
> > Isn't num_read enough for that?
> Actually, fsext_entries is an array of strings, fsext_entry is used
> to index into it. Using num_read only would require also keeping the
> number of strings in the fsext_entries array and then computing where
> we were in the list.
Isn't the list in fsext_entries[] NULL-terminated? If so, you don't
need to know how many entries are there, you just go on until you hit
NULL.
- Raw text -