Re: Merging relayfs?

[Roman Zippel <zippel@linux-m68k.org>]

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.

>  > 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.

>  > - 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).

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