From: Arnd Bergmann <arnd@arndb.de>
To: Christoph Hellwig <hch@infradead.org>
Cc: Chris Metcalf <cmetcalf@tilera.com>,
linasvepstas@gmail.com, GLIBC Devel <libc-alpha@sourceware.org>,
linux-kernel@vger.kernel.org, libc-ports@sourceware.org
Subject: Re: asm-generic/unistd.h and glibc use of NR_ipc
Date: Wed, 29 Sep 2010 13:55:06 +0200 [thread overview]
Message-ID: <201009291355.06512.arnd@arndb.de> (raw)
In-Reply-To: <20100929051631.GA8116@infradead.org>
On Wednesday 29 September 2010, Christoph Hellwig wrote:
> On Tue, Sep 28, 2010 at 09:05:13AM -0400, Chris Metcalf wrote:
> > Another point where I'd appreciate guidance from libc-alpha is the sysctl()
> > and ustat() APIs. The corresponding system calls are missing from
> > <asm-generic/unistd.h>, since they are deprecated and their functionality
> > is better provided by other means (/proc/sys, fstat). So I've simply had
> > them return -1 with errno == ENOSYS. Is there any reason to think they
> > merit more substantial work? One could imagine baking in some horrible
> > mapping of "integer names" into path components for a sysctl()
> > implementation and reading /proc/sys to provide results, or walking all of
> > the mount points looking for a matching device number to pass a name to
> > fstat(), but I'm not sure it's worth the bloat to the library.
>
> fstat does not replace ustat. ustat is a statf-subsystem by dev_t and
> is not replaced by anything. xfsprogs for example uses it to check if
> a given dev_t is currently mounted. Please add it to the generic code.
>
I didn't put it into the generic list because the man page claims
"ustat() is deprecated and has only been provided for compatibility.
All new programs should use statfs(2) instead."
I suppose that means we should change the man page as well, right?
Arnd
next prev parent reply other threads:[~2010-09-29 11:55 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-27 23:26 asm-generic/unistd.h and glibc use of NR_ipc Linas Vepstas
2010-09-28 0:02 ` Mike Frysinger
2010-09-28 8:40 ` Arnd Bergmann
2010-09-28 13:05 ` Chris Metcalf
2010-09-28 15:52 ` Joseph S. Myers
2010-09-28 16:13 ` Arnd Bergmann
2010-09-28 16:41 ` Joseph S. Myers
2010-09-28 20:08 ` Arnd Bergmann
2010-09-28 16:50 ` Mike Frysinger
2010-09-28 16:42 ` Mike Frysinger
2010-09-28 16:52 ` Joseph S. Myers
2010-09-28 17:36 ` Linas Vepstas
2010-09-30 13:23 ` Chris Metcalf
2010-09-29 5:16 ` Christoph Hellwig
2010-09-29 11:55 ` Arnd Bergmann [this message]
2011-03-10 16:46 ` Linas Vepstas
2011-03-10 17:07 ` Chris Metcalf
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=201009291355.06512.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=cmetcalf@tilera.com \
--cc=hch@infradead.org \
--cc=libc-alpha@sourceware.org \
--cc=libc-ports@sourceware.org \
--cc=linasvepstas@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.