Re: [patch] Performance Counters for Linux, v3

[Ingo Molnar]

* Peter Zijlstra <a.p.zijlstra@xxxxxxxxx> wrote:

> On Thu, 2008-12-11 at 20:34 +0100, Ingo Molnar wrote:
> 
> >  struct perf_counter_hw_event {
> >         s64                     type;
> > 
> >         u64                     irq_period;
> >         u32                     record_type;
> > 
> >         u32                     disabled     :  1, /* off by default */
> >                                 nmi          :  1, /* NMI sampling   */
> >                                 raw          :  1, /* raw event type */
> >                                 __reserved_1 : 29;
> > 
> >         u64                     __reserved_2;
> >  };
> > 
> > if the hw_event.raw bit is set to 1, then the hw_event.type is fully 
> > 'raw'. The default is for raw to be 0. So negative numbers can be used 
> > for sw events, positive numbers for hw events. Both can be extended 
> > gradually, without arbitrarily limits introduced.
> 
> On that, I still don't think its a good idea to use bitfields in an 
> ABI. The C std is just not strict enough on them, and I guess that is 
> the reason this would be the first such usage.

I dont feel strongly about this, we could certainly change it.

But these are system calls which have per platform bit order anyway - is 
it really an issue? I'd agree that it would be bad for any sort of 
persistent or otherwise cross-platform data such as filesystems, network 
protocol bits, etc.

We use bitfields in a couple of system calls ABIs already, for example in 
PPP:

if_ppp.h-/* For PPPIOCGL2TPSTATS */
if_ppp.h-struct pppol2tp_ioc_stats {
if_ppp.h-       __u16           tunnel_id;      /* redundant */
if_ppp.h-       __u16           session_id;     /* if zero, get tunnel stats */
if_ppp.h:       __u32           using_ipsec:1;  /* valid only for session_id == 

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