From: Robert Love <rml@novell.com>
To: Paul Jackson <pj@sgi.com>
Cc: ttb@tentacle.dhs.org, linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: [patch] inotify: make user visible types portable
Date: Fri, 01 Oct 2004 03:39:59 -0400 [thread overview]
Message-ID: <1096616399.4803.26.camel@localhost> (raw)
In-Reply-To: <20040930234436.097e6dfe.pj@sgi.com>
On Thu, 2004-09-30 at 23:44 -0700, Paul Jackson wrote:
> I've no doubt you're right here. But I'm a little confused.
>
> Are you saying to use __u32 so user code can compile with these kernel
> headers and see your new inotify symbols w/o polluting their name space
> with the non-underscored typedef symbols?
I am saying I have to use __u32, because they are user visible and u32
is not. Also, the rule is to use __u32.
> I though such use of kernel headers in compiling user code was
> deprecated. I'd have figured this meant while we might not go out of
> way to break someone already doing it, we wouldn't make any effort, or
> tolerate any ugly as sin __foo names, in order to add to the list of
> symbols so accessible.
>
> If you have a few minutes more patience, perhaps you could explain
> where my understanding departed from reality.
How else is user-space to know about this structure?
It has always been a no-no for user-space to access __KERNEL__ wrapped
parts of headers, but sharing a header (or at least generating
user-space's version of the header from the kernel header) is the only
way to ensure that both kernel and user-space speak the same language.
And not just structures, but flags, ioctl commands, ...
Robert Love
next prev parent reply other threads:[~2004-10-01 7:39 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-28 22:33 [RFC][PATCH] inotify 0.11.0 [WITH PATCH!] John McCutchan
2004-09-30 19:01 ` [patch] inotify: locking Robert Love
2004-09-30 19:17 ` Robert Love
2004-09-30 21:36 ` [patch] inotify: ioctl makeover Robert Love
2004-09-30 22:25 ` [patch] inotify: make user visible types portable Robert Love
2004-09-30 22:30 ` Robert Love
2004-10-02 9:21 ` David Woodhouse
2004-09-30 22:57 ` Paul Jackson
2004-10-01 5:35 ` Robert Love
2004-10-01 6:44 ` Paul Jackson
2004-10-01 7:39 ` Robert Love [this message]
2004-10-01 15:40 ` Paul Jackson
2004-10-01 15:47 ` Robert Love
2004-10-01 16:13 ` Paul Jackson
2004-10-01 16:31 ` Chris Friesen
2004-10-01 18:00 ` Paul Jackson
2004-09-30 22:43 ` [patch] inotify: rename inotify_watcher Robert Love
2004-09-30 22:44 ` Robert Love
2004-09-30 22:53 ` [patch] inotify: rename slab-related stuff Robert Love
2004-10-01 17:46 ` [patch] inotify: misc changes Robert Love
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=1096616399.4803.26.camel@localhost \
--to=rml@novell.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pj@sgi.com \
--cc=ttb@tentacle.dhs.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.