From: Matt Helsley <matthltc@us.ibm.com>
To: Yi Yang <yang.y.yi@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>,
Michael Kerrisk <michael.kerrisk@gmx.net>,
Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Subject: Re: [2.6.16 PATCH] Connector: Filesystem Events Connector
Date: Fri, 24 Mar 2006 01:53:26 -0800 [thread overview]
Message-ID: <1143194006.29668.251.camel@stark> (raw)
In-Reply-To: <44235E65.2020708@gmail.com>
On Fri, 2006-03-24 at 10:50 +0800, Yi Yang wrote:
> Matt Helsley wrote:
> > On Wed, 2006-03-22 at 22:58 +0800, Yi Yang wrote:
<snip>
> >> +struct fsevent {
> >> + __u32 type;
> >> + __u32 cpu;
> >> + struct timespec timestamp;
> >> + __u32 tgid;
> >>
> >
> > I think pid_t would be more appropriate here instead of a __u32.
> > Also a tid field of type pid_t would be consistent with the Process
> > Events returned to userspace. If a userspace program ever wanted to
> > relate the two sets of events the tid field could be important. That
> > said it would be nice to know if any userspace programs are planning on
> > using this.
> >
>
> I think size of pid_t must be changed from 2.4 to 2.6, in Redhat 9.0, I
> find size of pid_t in user space is
> different from kernel space, I believe that is the problem of stale
> header files.
I'm not sure why a connector would have to be concerned with the size of
pid_t in linux-2.4.x unless it's backported since, as far as I'm aware,
connectors have not been backported.
> >
> >> + __u32 uid;
> >> + __u32 gid;
> >> + __u32 err;
> >>
> >
> > The err field appears to be unused when sending events back to
> > userspace. I suggest reusing it for the event mask and using the type
> > field to indicate whether the message is a CMDACK or simply an EVENT.
> >
> err is useful when you use unknown CMD for the connector, ACK will tell
> the user CMD is invalid.
Yes, but the point is for an event -- which presumably is *much* more
frequent that a CMD -- the err field would be unused. Hence my
suggestion of having it serve as the mask field for event messages
instead of combining the event mask into the type field.
<snip>
Cheers,
-Matt Helsley
next prev parent reply other threads:[~2006-03-24 10:07 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-22 14:58 [2.6.16 PATCH] Connector: Filesystem Events Connector Yi Yang
2006-03-22 20:14 ` Serge E. Hallyn
2006-03-23 1:01 ` Yi Yang
2006-03-23 7:43 ` Matt Helsley
2006-03-23 8:52 ` Evgeniy Polyakov
2006-03-24 1:25 ` Yi Yang
2006-03-24 1:21 ` Yi Yang
2006-03-24 7:35 ` Matt Helsley
2006-03-24 8:11 ` Evgeniy Polyakov
2006-03-24 9:42 ` Matt Helsley
2006-03-24 10:09 ` Evgeniy Polyakov
2006-03-24 14:04 ` yang.y.yi
2006-03-24 2:50 ` [2.6.16 PATCH] " Yi Yang
2006-03-24 9:53 ` Matt Helsley [this message]
2006-03-23 8:17 ` Arjan van de Ven
2006-03-24 0:45 ` Yi Yang
2006-03-24 6:46 ` Arjan van de Ven
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=1143194006.29668.251.camel@stark \
--to=matthltc@us.ibm.com \
--cc=akpm@osdl.org \
--cc=johnpol@2ka.mipt.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.kerrisk@gmx.net \
--cc=yang.y.yi@gmail.com \
/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.