Roman Zippel writes:
> Hi,
>
> On Mon, 18 Jul 2005, Karim Yaghmour wrote:
>
> > I guess I just don't get the point here. Why cut something away if many
> > users will need it. If it's that popular that you're ready to provide a
> > library function to do it, then why not just leave it to boot? One of the
> > goals of relayfs is to avoid code duplication with regards to buffering
> > in general.
>
> The road to bloatness is paved with lots of little features.
> There aren't that many users anyway (none of the examples use that
> feature). I'd prefer to concentrate on a simple and correct relayfs layer
> and we can still think about other features as more users appear.
> Starting a design by implementing every little feature which _might_ be
> needed is a really bad idea.
>
OK, if we got rid of the padding counts and commit counts and let the
client manage those, we can simplify the buffer switch slow path and
make the API simpler in the process. Here's a first proposal for
doing that - I won't know until I actually do it what snags I may run
into, but if this looks like the right direction to go, I'll go ahead
with it...
- get rid of the padding counts - the client can manage those if it
wants to, but in any case pass the padding for the previous sub-buffer
in to the subbuf_start callback.
- get rid of the commit counts - the client can manage those. Also,
get rid of the related API functions that deal with those
i.e. relay_commit() and the deliver() callback.
- change the buffer_start() callback to something like the following
(the body shows an example of what would typically be done by a
client):
/*
* subbuf_start() callback.
*
* Return 1 to allow logging to continue, 0 to stop.
*/
static int subbuf_start_default_callback (struct rchan_buf *buf,
void *subbuf,
void *prev_subbuf,
int prev_padding)
{
*((int *)prev_subbuf) = prev_padding;
if (relay_buf_full(buf))
return 0;
relay_reserve(subbuf, sizeof (int));
return 1;
}
- add a relay_reserve() function for the client to use to reserve
space at the beginning of the sub-buffer (it can use this reserved
space to save the padding among other things). This would be used by
the client in the subbuf_start callback, rather than returning it via
an outparam or struct.
- remove the buf_full() callback - the client can determine this in
the subbuf_start() callback.
Also, as far as the netlink/ioctl/proc file communication, I'll have
to think more about it, but will play around with something when I
update the example code.
Let me know if this sounds ok, or if you have better suggestions.
Thanks,
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]
| |
 |