Re: why not choose another way to define the _IOC_xxxMASK related to the ioctl

2013-03-30 Thread Valdis . Kletnieks
On Sat, 30 Mar 2013 18:01:32 +0800, RS said: > > Now I think this will spend more time than the kernel code when executed. Have you actually examined the generated code on several popular architectures to see what gcc actually does? (hint - many things can constant-folded at compile time. So if

Re:Re: why not choose another way to define the _IOC_xxxMASK related to the ioctl

2013-03-30 Thread RS
Think you ! Oh , I was wrong . How careless I was. I have fixed it : #define _IOC_NRMASK (((1 << _IOC_NRBITS)-1) << _IOC_NRSHIFT) // if the _IOC_NRBITS is 8 ,then the result is 0XFF #define _IOC_DIR(nr)((nr & _IOC_DIRMASK) >> _IOC_DIRSHIFT) // when decode , keep the same. Now I th

Re: why not choose another way to define the _IOC_xxxMASK related to the ioctl

2013-03-30 Thread Tobias Boege
On Sat, 30 Mar 2013, RS wrote: > it defines in the kernel: #define _IOC_NRMASK((1 << _IOC_NRBITS)-1) > //define ... #define _IOC_NRSHIFT0 ... #define _IOC_DIR(nr) > (((nr) >> _IOC_DIRSHIFT) & _IOC_DIRMASK) //when decode > > why not define it like this: > #define

why not choose another way to define the _IOC_xxxMASK related to the ioctl

2013-03-29 Thread RS
it defines in the kernel: #define _IOC_NRMASK ((1 << _IOC_NRBITS)-1) //define ... #define _IOC_NRSHIFT0 ... #define _IOC_DIR(nr) (((nr) >> _IOC_DIRSHIFT) & _IOC_DIRMASK) //when decode why not define it like this: #define _IOC_NRSHIFT 0 ... #define _IOC_NRMASK ((_IO