On Thu, Oct 31, 2013 at 8:28 AM, Richard Guy Briggs <rgb(a)redhat.com> wrote:
On Thu, Oct 31, 2013 at 08:24:11AM -0700, William Roberts wrote:
> On Thu, Oct 31, 2013 at 7:36 AM, Steve Grubb <sgrubb(a)redhat.com> wrote:
> > On Wednesday, October 30, 2013 01:18:13 PM William Roberts wrote:
> > > On Wed, Oct 30, 2013 at 12:42 PM, Steve Grubb <sgrubb(a)redhat.com>
wrote:
> > > I have compiled kernels in the past with custom COMM widths, but
> > > the memory footprint goes up, at least here were not keeping a
> > > bunch of possibly unused data around in the kernel plus we're not
> > > allocating anything on the common case of it being turned off.
> >
> > I don't like the idea of fields appearing and disappearing. The
> > complaint is "comm" is meaningless. Let's fix that.
>
> Its not that the field is disappearing, its just whether or not you
> want the value printed out. cmdline=(null) vs cmdline="something".
> That's a trivial change of not making it dynamic which is what my
> first patch did but Richard Briggs suggested making it a dynamic
> feature and I was pretty ok with that.
Ok, so how about both fields are always present, but have some keyword
that is printed that indicates it is a duplicate of the other field?
Something like cmdline=(comm)
How are you going to detect that cmdlne has changed, its a region of memory
in userspace? We would have to
cmp the values, and if we cannot detect the transition, this gets more
expensive. Also, I have yet to see a case
where the above statement is true, so it would be a very infrequent event.
However, their is a condition in my patch where an error will cause
comm=(null) not to be printed, which could be
viewed as a disappearing field.
> William C Roberts
- RGB
--
Richard Guy Briggs <rbriggs(a)redhat.com>
Senior Software Engineer
Kernel Security
AMER ENG Base Operating Systems
Remote, Ottawa, Canada
Voice: +1.647.777.2635
Internal: (81) 32635
Alt: +1.613.693.0684x3545
--
Respectfully,
William C Roberts