mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@osdl.org>
To: Ulrich Drepper <drepper@redhat.com>
Cc: Jakub Jelinek <jakub@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Add getdents32t syscall
Date: Thu, 26 Feb 2004 15:00:25 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.58.0402261438470.7830@ppc970.osdl.org> (raw)
In-Reply-To: <403E7348.60503@redhat.com>



On Thu, 26 Feb 2004, Ulrich Drepper wrote:
> Linus Torvalds wrote:
> 
> >  - pre-fill the dirent area with 0xff or something
> 
> fill whole temporary buffer allocated by opendir() for every call to
> getdents(2)?

No no.

You only need to do this _once_. Once you know that the kernel is ok, you 
never ever need to do it again.

It's not even "once per file descriptor" or anything like that. It's 
literally _once_. 

And you don't need to fill the whole buffer even that first time. You 
only need to fill enough to guarantee that the _first_ entry is filled 
up.

In fact, if you're willing to have an algorithm that always works, but
might under some circumstances be a bit conservative, you can avoid
filling entirely, and just have a static flag that says "newformat", you
can do the following:

 - assume old format
 - if you ever see a reclen that is "too big" for the name length, you 
   know you have a new-format case (this will happen with any name that is 
   of length 1 modulo 4 on a 32-bit architecture).

For old-format stuff, you return DT_UNKNOWN, or you do your old existing 
song and dance. For new-format stuff you do the trivial thing.

And guess what? The entry "." will give you the information abotu whether 
it is old-format or not. On an old-format thing, "." will look like this:

	offset
	 0:	32-bit d_ino
	 4:	32-bit d_offset = 12
	 8:     16-bit d_namelen = 1
	10:	string ".\0"

	12:	32-bit d_ino for the next entry
	...

while with a new-format readdir you will get

	offset
	 0:	32-bit d_ino
	 4:	32-bit d_offset = 16
	 8:	16-bit d_namelen = 1
	10:	string ".\0"
	12-14:	three bytes of garbage
	15:	8-bit d_type

	16:	32-bit d_ino for the next entry..
	...

Notice? You are guaranteed to find out really quickly whether it's old- or 
new-format unless the user is doing something really really strange, and 
even if the user is doing something strange, returning D_UNKNOWN is always 
"correct".

So not only is my solution simple in kernel space, it allows you to 
simplify glibc too, if you are willing to make the old case go slower.

			Linus

  reply	other threads:[~2004-02-26 23:19 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-26 19:38 Jakub Jelinek
2004-02-26 22:03 ` Randy.Dunlap
2004-02-26 22:15 ` Linus Torvalds
2004-02-26 22:25   ` Linus Torvalds
2004-02-26 22:29     ` Ulrich Drepper
2004-02-26 23:00       ` Linus Torvalds [this message]
2004-02-26 22:32     ` Jakub Jelinek
2004-02-26 23:15       ` Linus Torvalds
2004-02-27  1:33         ` Ulrich Drepper
2004-02-27  6:16           ` Linus Torvalds
2004-02-27  7:05             ` Ulrich Drepper
2004-02-28 23:21           ` Jamie Lokier
2004-02-27  1:46         ` Andreas Dilger
2004-02-27  3:36       ` Theodore Ts'o
2004-02-29  0:25   ` Jamie Lokier
2004-02-27 19:28 ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.58.0402261438470.7830@ppc970.osdl.org \
    --to=torvalds@osdl.org \
    --cc=drepper@redhat.com \
    --cc=jakub@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®