64 bit event code. How to split up?
Hi All,
Given Michael has already run out of space in our 32 bit event code I suggest we bite the bullet and move over to a 64 bit one now. I doubt there is much userspace code in place so this shouldn't be 'too' painful.
So to start the ball rolling, how about the following split. The final will probably still be a macro of doom. Bitfields get a bit confusing cross architectures. I 'think' the following should even be fine of arm oabi (IIRC that has 4 byte alignment for structures).
The following avoids all the conditionals we currently have in the macro. It costs us space, but we have more of that. Note we'll need to add a NO_MOD modifier and add 1 to all the modifier codes. It should also allow us to use enums for everything.
/**
* iio_event - general purpose event to userspace.
* @time: timestamp
* @chan: index of non differential channel
* @chan1: index of first end of differential channel
* @chan2: index of second end of differential channel
* @chan_type: an iio_chan_type (we currently have 15)
* @modifier: currently we interleave several types of these (axial, light).
* having this much space would allow us to relax that and lead to
* simpler code.
* @direction: currently only 3, but definitely want level versions as well.
* @type: event type (currently thresh, mag, roc). Can see we will have more
* of these.
*/
struct iio_event {
int64_t time;
union {
unsigned chan:32;
struct {
unsigned chan1:16;
unsigned chan2:16;
};
};
unsigned chan_type:8;
unsigned modifier:8;
unsigned direction:8;
unsigned type:8;
};So the question is, is this rough and ready distribution of bits good enough, or do we need more channel types for example at the cost of some directions?
I'll hack some patches based on this together shortly so we can see what other cleanups it allows.
Jonathan
Quoted 16 lines · Jonathan Cameron
Hi All,
Given Michael has already run out of space in our 32 bit event code I suggest we bite the bullet and move over to a 64 bit one now. I doubt there is much userspace code in place so this shouldn't be 'too' painful.
So to start the ball rolling, how about the following split. The final will probably still be a macro of doom. Bitfields get a bit confusing cross architectures. I 'think' the following should even be fine of arm oabi (IIRC that has 4 byte alignment for structures).
The following avoids all the conditionals we currently have in the macro. It costs us space, but we have more of that. Note we'll need to add a
NO_MODmodifier and add 1 to all the modifier codes. It should also allow us to use enums for everything.
Quoted 13 lines
/**
*iio_event- general purpose event to userspace.
* @time: timestamp
* @chan: index of non differential channel
* @chan1: index of first end of differential channel
* @chan2: index of second end of differential channel
* @chan_type: aniio_chan_type(we currently have 15)
* @modifier: currently we interleave several types of these (axial, light).
* having this much space would allow us to relax that and lead to
* simpler code.
* @direction: currently only 3, but definitely want level versions as well.
* @type: event type (currently thresh, mag, roc). Can see we will have more
* of these.
Forgot to say, this also effects the size of the event_mask in iio_chan_spec. Right now that allows for 8 types and 4 directions. It's going to be fiddly to allow that to expand beyond 64 bits.
Quoted 30 lines
*/
struct iio_event { int64_t time; union { unsigned chan:32; struct { unsigned chan1:16; unsigned chan2:16; }; }; unsigned chan_type:8; unsigned modifier:8; unsigned direction:8; unsigned type:8; };So the question is, is this rough and ready distribution of bits good enough, or do we need more channel types for example at the cost of some directions?
I'll hack some patches based on this together shortly so we can see what other cleanups it allows.
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 46 lines · Jonathan Cameron
Hi All,
Given Michael has already run out of space in our 32 bit event code I suggest we bite the bullet and move over to a 64 bit one now. I doubt there is much userspace code in place so this shouldn't be 'too' painful.
So to start the ball rolling, how about the following split. The final will probably still be a macro of doom. Bitfields get a bit confusing cross architectures. I 'think' the following should even be fine of arm oabi (IIRC that has 4 byte alignment for structures).
The following avoids all the conditionals we currently have in the macro. It costs us space, but we have more of that. Note we'll need to add a
NO_MODmodifier and add 1 to all the modifier codes. It should also allow us to use enums for everything./**
*iio_event- general purpose event to userspace.
* @time: timestamp
* @chan: index of non differential channel
* @chan1: index of first end of differential channel
* @chan2: index of second end of differential channel
* @chan_type: aniio_chan_type(we currently have 15)
* @modifier: currently we interleave several types of these (axial, light).
* having this much space would allow us to relax that and lead to
* simpler code.
* @direction: currently only 3, but definitely want level versions as well.
* @type: event type (currently thresh, mag, roc). Can see we will have more
* of these.
*/struct iio_event { int64_t time; union { unsigned chan:32; struct { unsigned chan1:16; unsigned chan2:16; }; }; unsigned chan_type:8; unsigned modifier:8; unsigned direction:8; unsigned type:8; };
Quoted 4 lines
So the question is, is this rough and ready distribution of bits good enough, or do we need more channel types for example at the cost of some directions?
Looks good to me.
Quoted 5 lines
I'll hack some patches based on this together shortly so we can see what other cleanups it allows.
Jonathan
Signature · 8 lines
Greetings, Michael -- Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368; Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin, Margaret Seif