All of lore.kernel.org
 help / color / mirror / Atom feed
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



  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.