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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |