Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1292433 > unrolled thread

RE: [PATCH 13/40] staging: lustre: Dynamic LNet Configuration (DLC) show command

Started by"Simmons, James A." <simmonsja@ornl.gov>
First post2015-12-15 19:20 +0100
Last post2015-12-15 21:00 +0100
Articles 6 — 4 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  RE: [PATCH 13/40] staging: lustre: Dynamic LNet Configuration (DLC)  show command "Simmons, James A." <simmonsja@ornl.gov> - 2015-12-15 19:20 +0100
    Re: [PATCH 13/40] staging: lustre: Dynamic LNet Configuration (DLC)  show command Dan Carpenter <dan.carpenter@oracle.com> - 2015-12-15 19:30 +0100
      RE: [PATCH 13/40] staging: lustre: Dynamic LNet Configuration (DLC)  show command "Simmons, James A." <simmonsja@ornl.gov> - 2015-12-15 19:40 +0100
    Re: [PATCH 13/40] staging: lustre: Dynamic LNet Configuration (DLC)  show command Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-12-15 19:50 +0100
      RE: [PATCH 13/40] staging: lustre: Dynamic LNet Configuration (DLC)  show command "Simmons, James A." <simmonsja@ornl.gov> - 2015-12-15 20:50 +0100
        Re: [PATCH 13/40] staging: lustre: Dynamic LNet Configuration (DLC)  show command 'Greg Kroah-Hartman' <gregkh@linuxfoundation.org> - 2015-12-15 21:00 +0100

#1292433 — RE: [PATCH 13/40] staging: lustre: Dynamic LNet Configuration (DLC) show command

From"Simmons, James A." <simmonsja@ornl.gov>
Date2015-12-15 19:20 +0100
SubjectRE: [PATCH 13/40] staging: lustre: Dynamic LNet Configuration (DLC) show command
Message-ID<qG2mC-7LE-13@gated-at.bofh.it>
  
>>  struct libcfs_ioctl_hdr {
>>  	__u32 ioc_len;
>> @@ -87,6 +88,13 @@ do {						    \
>>  	data.ioc_hdr.ioc_len = sizeof(data);			\
>>  } while (0)
>>  
>> +#define LIBCFS_IOC_INIT_V2(data, hdr)			\
>> +do {							\
>> +	memset(&(data), 0, sizeof(data));		\
>> +	(data).hdr.ioc_version = LIBCFS_IOCTL_VERSION2;	\
>> +	(data).hdr.ioc_len = sizeof(data);		\
>> +} while (0)
>> +
>
>Do we really need this?

Would you be okay if this was a inline function? This is used by user land and kernel space code.


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

[toc] | [next] | [standalone]

#1292442

FromDan Carpenter <dan.carpenter@oracle.com>
Date2015-12-15 19:30 +0100
Message-ID<qG2wj-7PJ-31@gated-at.bofh.it>
In reply to#1292433
On Tue, Dec 15, 2015 at 06:14:19PM +0000, Simmons, James A. wrote:
>   
> >>  struct libcfs_ioctl_hdr {
> >>  	__u32 ioc_len;
> >> @@ -87,6 +88,13 @@ do {						    \
> >>  	data.ioc_hdr.ioc_len = sizeof(data);			\
> >>  } while (0)
> >>  
> >> +#define LIBCFS_IOC_INIT_V2(data, hdr)			\
> >> +do {							\
> >> +	memset(&(data), 0, sizeof(data));		\
> >> +	(data).hdr.ioc_version = LIBCFS_IOCTL_VERSION2;	\
> >> +	(data).hdr.ioc_len = sizeof(data);		\
> >> +} while (0)
> >> +
> >
> >Do we really need this?
> 
> Would you be okay if this was a inline function? This is used by user land and kernel space code.
> 

I try (not very hard) to sound like a broken record but this business of
sharing code with userland is a pain in the butt.  It's not used in the
kernel or in any patches you have sent.

It would look better as an inline function though so I wouldn't have
even noticed it.

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

[toc] | [prev] | [next] | [standalone]

#1292451

From"Simmons, James A." <simmonsja@ornl.gov>
Date2015-12-15 19:40 +0100
Message-ID<qG2FY-7U3-11@gated-at.bofh.it>
In reply to#1292442
>On Tue, Dec 15, 2015 at 06:14:19PM +0000, Simmons, James A. wrote:
>>   
>> >>  struct libcfs_ioctl_hdr {
>> >>  	__u32 ioc_len;
>> >> @@ -87,6 +88,13 @@ do {						    \
>> >>  	data.ioc_hdr.ioc_len = sizeof(data);			\
>> >>  } while (0)
>> >>  
>> >> +#define LIBCFS_IOC_INIT_V2(data, hdr)			\
>> >> +do {							\
>> >> +	memset(&(data), 0, sizeof(data));		\
>> >> +	(data).hdr.ioc_version = LIBCFS_IOCTL_VERSION2;	\
>> >> +	(data).hdr.ioc_len = sizeof(data);		\
>> >> +} while (0)
>> >> +
>> >
>> >Do we really need this?
>> 
>> Would you be okay if this was a inline function? This is used by user land and kernel space code.
>> 
>
>I try (not very hard) to sound like a broken record but this business of
>sharing code with userland is a pain in the butt.  It's not used in the
>kernel or in any patches you have sent.
>
>It would look better as an inline function though so I wouldn't have
>even noticed it.

I'm glad you noticed.  I just looked at the production source code and yep it is only used
in the userland tools code. I need to update our tools so they don't break. Then we can
remove these macros.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1292463

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2015-12-15 19:50 +0100
Message-ID<qG2PE-7Xw-17@gated-at.bofh.it>
In reply to#1292433
On Tue, Dec 15, 2015 at 06:14:19PM +0000, Simmons, James A. wrote:
>   
> >>  struct libcfs_ioctl_hdr {
> >>  	__u32 ioc_len;
> >> @@ -87,6 +88,13 @@ do {						    \
> >>  	data.ioc_hdr.ioc_len = sizeof(data);			\
> >>  } while (0)
> >>  
> >> +#define LIBCFS_IOC_INIT_V2(data, hdr)			\
> >> +do {							\
> >> +	memset(&(data), 0, sizeof(data));		\
> >> +	(data).hdr.ioc_version = LIBCFS_IOCTL_VERSION2;	\
> >> +	(data).hdr.ioc_len = sizeof(data);		\
> >> +} while (0)
> >> +
> >
> >Do we really need this?
> 
> Would you be okay if this was a inline function? This is used by user
> land and kernel space code.

Then your code is broken, please never do that.

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

[toc] | [prev] | [next] | [standalone]

#1292498

From"Simmons, James A." <simmonsja@ornl.gov>
Date2015-12-15 20:50 +0100
Message-ID<qG3LH-78-9@gated-at.bofh.it>
In reply to#1292463
>On Tue, Dec 15, 2015 at 06:14:19PM +0000, Simmons, James A. wrote:
>>   
>> >>  struct libcfs_ioctl_hdr {
>> >>  	__u32 ioc_len;
>> >> @@ -87,6 +88,13 @@ do {						    \
>> >>  	data.ioc_hdr.ioc_len = sizeof(data);			\
>> >>  } while (0)
>> >>  
>> >> +#define LIBCFS_IOC_INIT_V2(data, hdr)			\
>> >> +do {							\
>> >> +	memset(&(data), 0, sizeof(data));		\
>> >> +	(data).hdr.ioc_version = LIBCFS_IOCTL_VERSION2;	\
>> >> +	(data).hdr.ioc_len = sizeof(data);		\
>> >> +} while (0)
>> >> +
>> >
>> >Do we really need this?
>> 
>> Would you be okay if this was a inline function? This is used by user
>> land and kernel space code.
>
>Then your code is broken, please never do that.

This brings up a good point. This header doesn't contain structures for userland so it is a uapi
type header.  Should such headers only contain data structures?

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

[toc] | [prev] | [next] | [standalone]

#1292505

From'Greg Kroah-Hartman' <gregkh@linuxfoundation.org>
Date2015-12-15 21:00 +0100
Message-ID<qG3Vq-aC-43@gated-at.bofh.it>
In reply to#1292498
On Tue, Dec 15, 2015 at 07:48:22PM +0000, Simmons, James A. wrote:
> >On Tue, Dec 15, 2015 at 06:14:19PM +0000, Simmons, James A. wrote:
> >>   
> >> >>  struct libcfs_ioctl_hdr {
> >> >>  	__u32 ioc_len;
> >> >> @@ -87,6 +88,13 @@ do {						    \
> >> >>  	data.ioc_hdr.ioc_len = sizeof(data);			\
> >> >>  } while (0)
> >> >>  
> >> >> +#define LIBCFS_IOC_INIT_V2(data, hdr)			\
> >> >> +do {							\
> >> >> +	memset(&(data), 0, sizeof(data));		\
> >> >> +	(data).hdr.ioc_version = LIBCFS_IOCTL_VERSION2;	\
> >> >> +	(data).hdr.ioc_len = sizeof(data);		\
> >> >> +} while (0)
> >> >> +
> >> >
> >> >Do we really need this?
> >> 
> >> Would you be okay if this was a inline function? This is used by user
> >> land and kernel space code.
> >
> >Then your code is broken, please never do that.
> 
> This brings up a good point. This header doesn't contain structures for userland so it is a uapi
> type header.  Should such headers only contain data structures?

Yes, that would make more sense.

thanks,

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web