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
next prev parent 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®