Date: Tue, 26 Dec 2000 19:05:06 +0200
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: tim DOT van DOT holder AT pandora DOT be
Message-Id: <2593-Tue26Dec2000190505+0200-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.6
CC: djgpp-workers AT delorie DOT com
In-reply-to: <NEBBIOJNGMKPNOBKHCGHAEBACAAA.tim.van.holder@pandora.be>
Subject: Re: Draft patch for opendir() extension
References:  <NEBBIOJNGMKPNOBKHCGHAEBACAAA DOT tim DOT van DOT holder AT pandora DOT be>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> 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.