Re: Squashfs without ./..

[Adam J. Richter]

Jan Engelhardt wrote:
>[...] . and .. do not need to show up (even they have been the 
>"leaders" of ls -l ;-), Midnight Commander (`mc`) for example synthesizes ".." 
>nevertheless.
>
>So - what about removing . and .. in readdir for all "standard harddisk 
>filesystems" (ext*,reiser*, [jx]fs)? I mean, one party always has to loose...~v

	Eliminating the "." and ".." emulation in many individual
file systems would probably eliminate a moderate amount of code
from libfs/fs.c, a number of other virtual file systems and probably
every physical file system that does not actually store "." and "..".
It is very appealing to me.

	Unfortunately, the description of readdir() in the Single Unix
Specification version 3 says:

| [...] If entries for dot or dot-dot exist, one entry shall be returned
| for dot and one entry shall be returned for dot-dot; otherwise, they
| shall not be returned.

	Unless attempts to access "." and ".." would really return -ENOENT,
then at least the C library's readdir() function has to return them.  
At least that's how I read it.

	Although I do not believe that absolute compliance to SUSPv3
is a requirement demanded by those who make the "official" kernel
releases, I think that complying closely to SUSPv3 and many other
standards is considered to be worth a lot (in terms of technical
trade-offs) so that software that complies to these standards
is more likely to run properly on systems running the Linux kernel.
So, I would expect that patches changing squashfs and other file systems
whose readdir functions currently fail to return "." and ".." would 
be likely to be integrated (if they meet all the other usual quality
standards), at least for now.

	That said, I can think of at least two approaches by which
we could eliminate the "." and ".." emulation littering most Linux
file system drivers.

	The first way would be to change the kernel so that the
underlying readdir system call does not return "." or "..", but
have the C library do the emulation.  The C library can maintain
the state information for this purpose easily because opendir()
returns a pointer to an opaque structure that the C library
allocates.

	Alternatively, we could preserve the opendir system call's
behavior, but pick apart a few of the routines in fs/libfs.c to come
up with some more general utiity routines to implement the common case
where the first readdir returns ".", the second returns "..", a seek
pointer of 0 means before the ".", a seek pointer of 1 means before
the "..", and a seek pointer of 1 means immediately after the "..".
The actual implementation would be pretty short, but having an
interface that the client file systems could easily accomodate might
take some care (for example, accomodating their locking schemes while
keeping the interface simple enough so that the client file system
drivers are still made smaller by using it).

                    __     ______________ 
Adam J. Richter        \ /
adam@xxxxxxxxxxxxx      | g g d r a s i l
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/