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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
