Re: Merging relayfs?

[Tom Zanussi]

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.

Tom


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/