* Frank Ch. Eigler ([EMAIL PROTECTED]) wrote: > Mathieu Desnoyers <[EMAIL PROTECTED]> writes: > > > This updated version of the Linux Kernel Markers mostly adds a unique 16 > > bits > > per marker ID and a per-probe marker group. [...] >
Hello, > Could you motivate this part better? It is not covered in the > documentation patch. > > It seems to be a way of having a marker handling (callback) module > give alternate names/ids to markers. If so, why, considering that > there is already a private void* callback parameter available to pass > data back to itself through? > The original reason was to get rid of a supplementary kmalloc() for each active marker. However, I just noticed that I could pack my private data in a slab cache, which makes the problem go away. I am therefore removing IDs and groups from the markers.. they don't really belong to this low-level infrastructure anyway, so this is all better. > Also, what if different marker handling modules want to set different > id/group numbers on the same set of markers? > The way I see things now is to provide the simplest way to do the job, without over-design. Clearly, putting the IDs and groups there was not the best idea. I also think it will be up to a "tee" callback module to implement a list of handlers (notifiers). However, supporting such a list of handlers should not be a requirement for the low-level markers, since has a significant performance impact which can be unwanted in the common case (only one probe connected to a marker). Mathieu > - FChE -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - 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/
