[lkml]   [2005]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Merging relayfs?
Roman Zippel writes:
> Hi,
> On Thu, 14 Jul 2005, Tom Zanussi wrote:
> > The netlink control channel seems to work very well, but I can
> > certainly change the examples to use something different. Could you
> > suggest something?
> It just looks like a complicated way to do an ioctl, a control file that
> you can read/write would be a lot simpler and faster.

You're right - in previous versions, we did use ioctl - we ended up
using netlink as it seemed like least offensive option to most people.
I'll try modifying the example code to use a control file or something
like that instead though.

> > > Looking through the patch there are still a few areas I'm concerned about:
> > > - the usage of atomic_t look a little silly, there is only a single
> > > writer and probably needs some cache line optimisations
> >
> > The only things that are atomic are the counts of produced and
> > consumed buffers and these are only ever updated or read in the slow
> > buffer-switch path. They're atomic because if they weren't, wouldn't
> > it be possible for the client to read an unfinished value if the
> > producer was in the middle of updating it?
> No.
> > > - I would prefer "unsigned int" over just "unsigned"
> > > - the padding/commit arrays can be easily managed by the client
> >
> > Yes, I can move them out and update the examples to reflect that, but
> > I thought that if this was something that most clients would need to
> > do, it made some sense to keep it in relayfs and avoid duplication in
> > the clients.
> If a lot of clients needs this, there a different ways to do this, e.g. by
> introducing some helper functions that clients can use. This way you can
> keep the core simple and allow the client to modify its behaviour.

OK, I'll think about the best way to change this.

> > > - overwrite mode can be implemented via the buffer switch callback
> >
> > The buffer switch callback is already where this is handled, unless
> > you're thinking of something else - one of the first checks in the
> > buffer switch is relay_buf_full(), which always returns 0 if the
> > buffer is in overwrite mode.
> I mean, relayfs doesn't has to know about this, the client itself can do
> it (e.g. via helper functions).

In a previous version, we did something like having the client pass
back a return value from the callback indicating whether or not to
continue or stop. I can try doing something like that instead again.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-07-17 17:57    [W:0.191 / U:16.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site