[Lustre-devel] (no subject)

[Lustre-devel] (no subject)

[sethpn at gmail.com]

Is there any Lenny packaged with Lustre 1.6.7? This will be great!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20090327/f7bcc52e/attachment.htm>

[Lustre-devel] (no subject)

[di.wang]

Hello, Michael

There is a logfile parser script in the attachment, which was written by 
Eric.

This script is very simple, but it should help you understand how we 
retrieve time step information from lustre debug log. On the server 
side, if you enable rpc_trace log, whenever the request arrive/start 
being processed/end of processing, there will be corresponding records 
being written into the debug log. Basically, you can get all the time 
step information from these records (actually only two of these records 
would be enough).


a. 
00000100:00100000:0.0:1272313858.472660:0:31581:0:(service.c:1625:ptlrpc_server_handle_request()) 
Handling RPC pname:cluuid+ref:pid:xid:nid:opc 
ll_mgs_00:7d4fb15c-1b1c-295f-e466-ea7d77089b52+10:4055:x1334115493386242:12345-0 at lo:400

This record means the req will being handled, so you can get the start 
time stamp(1272313858.472660) operation type (opc: 400, ping), xid 
(1334115493386242), client nid(12345-0 at lo) and so on.

b. 
00000100:00100000:0.0:1272313858.472687:0:31581:0:(service.c:1672:ptlrpc_server_handle_request()) 
Handled RPC pname:cluuid+ref:pid:xid:nid:opc 
ll_mgs_00:7d4fb15c-1b1c-295f-e466-ea7d77089b52+9:4055:x1334115493386242:12345-0 at lo:400 
Request procesed in 45us (77us total) trans 0 rc 0/0

This record means the req is already being handled, so you can get the 
end time stamp(1272313858.472687), operation type (opc: 400, ping), xid 
(1334115493386242), client nid(12345-0 at lo) and so no.

Note: (77us total) means how long it takes from the request arriving to 
the end of processing. so you can also get the request arriving time 
stamp here by (1272313858 - 77 = 1272312781).


So with these information you can draw the graph Eric mentioned in his 
email. If you have any questions, please let me know.

Thanks
WangDi


Eric Barton wrote:
>
> ------------------------------------------------------------------------
>
> Subject:
> RE: Visualising Lustre RPCs
> To:
> "Michael Kluge" <Michael.Kluge@tu-dresden.de>, "wangdi" 
> <Tom.Wang@Sun.COM>
>
> To:
> "Michael Kluge" <Michael.Kluge@tu-dresden.de>, "wangdi" 
> <Tom.Wang@Sun.COM>
> CC:
> <lustre-devel@lists.lustre.org>, "Galen M. Shipman" <gshipman@ornl.gov>
>
>
> Michael,
>
> The previous Lustre RPC visualisation effort I mentioned at the LUG 
> used the
>
> Lustre debug log entries of type D_RPCTRACE. We disabled all but these
>
> log messages and then used the Lustre debug daemon to collect them while
>
> we ran I/O tests. We then ran a simple logfile parser which used just 
> the log entries
>
> for request arrival?
>
> , start of processing and end of processing to graph request
>
> queue depth (arrival->end) and the number of requests being serviced 
> by type
>
> over time ? e.g?
>
> read3d
>
> ?which shows request queue depth (vertical) over time (axis labelled 
> 20-25) by
>
> server (axis labelled 0-80).
>
> *From:* Michael Kluge [mailto:Michael.Kluge at tu-dresden.de]
> *Sent:* 17 April 2010 6:26 AM
> *To:* Galen M. Shipman; Eric Barton
> *Subject:* Visualising Lustre RPCs
>
> Hi Galen, Eric,
>
> in order to get this little project started, I think what I need at 
> first to
>
> write a prototype for a converter are the following things:
>
> A set of test traces collected on maybe a handful of clients and some 
> servers
>
> is probably a good point to start with. It would be even better if we know
>
> what is in this traces so that we have an expectation what kind of things
>
> we want to see on the Vampir displays. This little program that Eric 
> mentioned
>
> that can read the trace file would be very helpful as well. And as the 
> last
>
> idea I have right now, a technical contact. I might come up with a couple
>
> of question after I have taken the first look onto the original trace 
> data
>
> and before I start writing code.
>
> Regards, Michael
>
>
> -- 
>
> Michael Kluge, M.Sc.
>
> Technische Universit?t Dresden
> Center for Information Services and
> High Performance Computing (ZIH)
> D-01062 Dresden
> Germany
>
> Contact:
> Willersbau, Room WIL A 208
> Phone: (+49) 351 463-34217
> Fax: (+49) 351 463-37773
> e-mail: michael.kluge at tu-dresden.de <mailto:michael.kluge@tu-dresden.de>
> WWW: http://www.tu-dresden.de/zih
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rpc_parse.tgz
Type: application/x-compressed-tar
Size: 30287 bytes
Desc: not available
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20100428/e7d90469/attachment.bin>

[Lustre-devel] (no subject)

[Andreas Dilger]

AFAIK the Handling time is when request processing starts, not when it  
first arrived at the server. We would need to check I'd there is an  
RPCTRACE message from ptlrpc_handle_req_in() that we could use to  
determine the initial request arrival time.

Cheers, Andreas

On 2010-04-28, at 19:25, "di.wang" <di.wang@oracle.com> wrote:

> Hello, Michael
>
> There is a logfile parser script in the attachment, which was  
> written by Eric.
>
> This script is very simple, but it should help you understand how we  
> retrieve time step information from lustre debug log. On the server  
> side, if you enable rpc_trace log, whenever the request arrive/start  
> being processed/end of processing, there will be corresponding  
> records being written into the debug log. Basically, you can get all  
> the time step information from these records (actually only two of  
> these records would be enough).
>
>
> a. 00000100:00100000:0.0:1272313858.472660:0:31581:0:(service.c: 
> 1625:ptlrpc_server_handle_request()) Handling RPC pname:cluuid 
> +ref:pid:xid:nid:opc ll_mgs_00:7d4fb15c-1b1c-295f-e466- 
> ea7d77089b52+10:4055:x1334115493386242:12345-0 at lo:400
>
> This record means the req will being handled, so you can get the  
> start time stamp(1272313858.472660) operation type (opc: 400, ping),  
> xid (1334115493386242), client nid(12345-0 at lo) and so on.
>
> b. 00000100:00100000:0.0:1272313858.472687:0:31581:0:(service.c: 
> 1672:ptlrpc_server_handle_request()) Handled RPC pname:cluuid 
> +ref:pid:xid:nid:opc ll_mgs_00:7d4fb15c-1b1c-295f-e466- 
> ea7d77089b52+9:4055:x1334115493386242:12345-0 at lo:400 Request  
> procesed in 45us (77us total) trans 0 rc 0/0
>
> This record means the req is already being handled, so you can get  
> the end time stamp(1272313858.472687), operation type (opc: 400,  
> ping), xid (1334115493386242), client nid(12345-0 at lo) and so no.
>
> Note: (77us total) means how long it takes from the request arriving  
> to the end of processing. so you can also get the request arriving  
> time stamp here by (1272313858 - 77 = 1272312781).
>
>
> So with these information you can draw the graph Eric mentioned in  
> his email. If you have any questions, please let me know.
>
> Thanks
> WangDi
>
>
> Eric Barton wrote:
>>
>> --- 
>> ---------------------------------------------------------------------
>>
>> Subject:
>> RE: Visualising Lustre RPCs
>> To:
>> "Michael Kluge" <Michael.Kluge@tu-dresden.de>, "wangdi" <Tom.Wang@Sun.COM 
>> >
>>
>> To:
>> "Michael Kluge" <Michael.Kluge@tu-dresden.de>, "wangdi" <Tom.Wang@Sun.COM 
>> >
>> CC:
>> <lustre-devel@lists.lustre.org>, "Galen M. Shipman" <gshipman@ornl.gov 
>> >
>>
>>
>> Michael,
>>
>> The previous Lustre RPC visualisation effort I mentioned at the LUG  
>> used the
>>
>> Lustre debug log entries of type D_RPCTRACE. We disabled all but  
>> these
>>
>> log messages and then used the Lustre debug daemon to collect them  
>> while
>>
>> we ran I/O tests. We then ran a simple logfile parser which used  
>> just the log entries
>>
>> for request arrival?
>>
>> , start of processing and end of processing to graph request
>>
>> queue depth (arrival->end) and the number of requests being  
>> serviced by type
>>
>> over time ? e.g?
>>
>> read3d
>>
>> ?which shows request queue depth (vertical) over time (axis labell 
>> ed 20-25) by
>>
>> server (axis labelled 0-80).
>>
>> *From:* Michael Kluge [mailto:Michael.Kluge at tu-dresden.de]
>> *Sent:* 17 April 2010 6:26 AM
>> *To:* Galen M. Shipman; Eric Barton
>> *Subject:* Visualising Lustre RPCs
>>
>> Hi Galen, Eric,
>>
>> in order to get this little project started, I think what I need at  
>> first to
>>
>> write a prototype for a converter are the following things:
>>
>> A set of test traces collected on maybe a handful of clients and  
>> some servers
>>
>> is probably a good point to start with. It would be even better if  
>> we know
>>
>> what is in this traces so that we have an expectation what kind of  
>> things
>>
>> we want to see on the Vampir displays. This little program that  
>> Eric mentioned
>>
>> that can read the trace file would be very helpful as well. And as  
>> the last
>>
>> idea I have right now, a technical contact. I might come up with a  
>> couple
>>
>> of question after I have taken the first look onto the original  
>> trace data
>>
>> and before I start writing code.
>>
>> Regards, Michael
>>
>>
>> -- 
>>
>> Michael Kluge, M.Sc.
>>
>> Technische Universit?t Dresden
>> Center for Information Services and
>> High Performance Computing (ZIH)
>> D-01062 Dresden
>> Germany
>>
>> Contact:
>> Willersbau, Room WIL A 208
>> Phone: (+49) 351 463-34217
>> Fax: (+49) 351 463-37773
>> e-mail: michael.kluge at tu-dresden.de <mailto:michael.kluge@tu-dresden.de 
>> >
>> WWW: http://www.tu-dresden.de/zih
>>
>
> <rpc_parse.tgz>
> _______________________________________________
> Lustre-devel mailing list
> Lustre-devel at lists.lustre.org
> http://lists.lustre.org/mailman/listinfo/lustre-devel

[Lustre-devel] (no subject)

[di.wang]

Andreas Dilger wrote:
> AFAIK the Handling time is when request processing starts, not when it  
> first arrived at the server. We would need to check I'd there is an  
> RPCTRACE message from ptlrpc_handle_req_in() that we could use to  
> determine the initial request arrival time.
>   
Oh, you can also get the arriving time in "Handled RPC" msg
by Handled RPC_time - total time.

Thanks
WangDi
> Cheers, Andreas
>
> On 2010-04-28, at 19:25, "di.wang" <di.wang@oracle.com> wrote:
>
>   
>> Hello, Michael
>>
>> There is a logfile parser script in the attachment, which was  
>> written by Eric.
>>
>> This script is very simple, but it should help you understand how we  
>> retrieve time step information from lustre debug log. On the server  
>> side, if you enable rpc_trace log, whenever the request arrive/start  
>> being processed/end of processing, there will be corresponding  
>> records being written into the debug log. Basically, you can get all  
>> the time step information from these records (actually only two of  
>> these records would be enough).
>>
>>
>> a. 00000100:00100000:0.0:1272313858.472660:0:31581:0:(service.c: 
>> 1625:ptlrpc_server_handle_request()) Handling RPC pname:cluuid 
>> +ref:pid:xid:nid:opc ll_mgs_00:7d4fb15c-1b1c-295f-e466- 
>> ea7d77089b52+10:4055:x1334115493386242:12345-0 at lo:400
>>
>> This record means the req will being handled, so you can get the  
>> start time stamp(1272313858.472660) operation type (opc: 400, ping),  
>> xid (1334115493386242), client nid(12345-0 at lo) and so on.
>>
>> b. 00000100:00100000:0.0:1272313858.472687:0:31581:0:(service.c: 
>> 1672:ptlrpc_server_handle_request()) Handled RPC pname:cluuid 
>> +ref:pid:xid:nid:opc ll_mgs_00:7d4fb15c-1b1c-295f-e466- 
>> ea7d77089b52+9:4055:x1334115493386242:12345-0 at lo:400 Request  
>> procesed in 45us (77us total) trans 0 rc 0/0
>>
>> This record means the req is already being handled, so you can get  
>> the end time stamp(1272313858.472687), operation type (opc: 400,  
>> ping), xid (1334115493386242), client nid(12345-0 at lo) and so no.
>>
>> Note: (77us total) means how long it takes from the request arriving  
>> to the end of processing. so you can also get the request arriving  
>> time stamp here by (1272313858 - 77 = 1272312781).
>>
>>
>> So with these information you can draw the graph Eric mentioned in  
>> his email. If you have any questions, please let me know.
>>
>> Thanks
>> WangDi
>>
>>
>> Eric Barton wrote:
>>     
>>> --- 
>>> ---------------------------------------------------------------------
>>>
>>> Subject:
>>> RE: Visualising Lustre RPCs
>>> To:
>>> "Michael Kluge" <Michael.Kluge@tu-dresden.de>, "wangdi" <Tom.Wang@Sun.COM 
>>>       
>>> To:
>>> "Michael Kluge" <Michael.Kluge@tu-dresden.de>, "wangdi" <Tom.Wang@Sun.COM 
>>>       
>>> CC:
>>> <lustre-devel@lists.lustre.org>, "Galen M. Shipman" <gshipman@ornl.gov 
>>>       
>>> Michael,
>>>
>>> The previous Lustre RPC visualisation effort I mentioned at the LUG  
>>> used the
>>>
>>> Lustre debug log entries of type D_RPCTRACE. We disabled all but  
>>> these
>>>
>>> log messages and then used the Lustre debug daemon to collect them  
>>> while
>>>
>>> we ran I/O tests. We then ran a simple logfile parser which used  
>>> just the log entries
>>>
>>> for request arrival?
>>>
>>> , start of processing and end of processing to graph request
>>>
>>> queue depth (arrival->end) and the number of requests being  
>>> serviced by type
>>>
>>> over time ? e.g?
>>>
>>> read3d
>>>
>>> ?which shows request queue depth (vertical) over time (axis labell 
>>> ed 20-25) by
>>>
>>> server (axis labelled 0-80).
>>>
>>> *From:* Michael Kluge [mailto:Michael.Kluge at tu-dresden.de]
>>> *Sent:* 17 April 2010 6:26 AM
>>> *To:* Galen M. Shipman; Eric Barton
>>> *Subject:* Visualising Lustre RPCs
>>>
>>> Hi Galen, Eric,
>>>
>>> in order to get this little project started, I think what I need at  
>>> first to
>>>
>>> write a prototype for a converter are the following things:
>>>
>>> A set of test traces collected on maybe a handful of clients and  
>>> some servers
>>>
>>> is probably a good point to start with. It would be even better if  
>>> we know
>>>
>>> what is in this traces so that we have an expectation what kind of  
>>> things
>>>
>>> we want to see on the Vampir displays. This little program that  
>>> Eric mentioned
>>>
>>> that can read the trace file would be very helpful as well. And as  
>>> the last
>>>
>>> idea I have right now, a technical contact. I might come up with a  
>>> couple
>>>
>>> of question after I have taken the first look onto the original  
>>> trace data
>>>
>>> and before I start writing code.
>>>
>>> Regards, Michael
>>>
>>>
>>> -- 
>>>
>>> Michael Kluge, M.Sc.
>>>
>>> Technische Universit?t Dresden
>>> Center for Information Services and
>>> High Performance Computing (ZIH)
>>> D-01062 Dresden
>>> Germany
>>>
>>> Contact:
>>> Willersbau, Room WIL A 208
>>> Phone: (+49) 351 463-34217
>>> Fax: (+49) 351 463-37773
>>> e-mail: michael.kluge at tu-dresden.de <mailto:michael.kluge@tu-dresden.de 
>>>       
>>> WWW: http://www.tu-dresden.de/zih
>>>
>>>       
>> <rpc_parse.tgz>
>> _______________________________________________
>> Lustre-devel mailing list
>> Lustre-devel at lists.lustre.org
>> http://lists.lustre.org/mailman/listinfo/lustre-devel
>>     
> _______________________________________________
> Lustre-devel mailing list
> Lustre-devel at lists.lustre.org
> http://lists.lustre.org/mailman/listinfo/lustre-devel
>   

[lustre-devel] (no subject)

[Di]

Greetings,

I am attempting to port the SysV lnet script as part of a transition to systemd. I ran into the following in lustre/scripts/lnet:

        if [ -x $LUSTRE_LNET_CONFIG_UTILITY -a -f "$LUSTRE_LNET_CONFIG_FILE" ]; then
                $LUSTRE_LNET_CONFIG_UTILITY lnet configure || exit 1
        else
                lctl network up || exit 1
        fi

Can the check for LUSTRE_LNET_CONFIG_UTILITY  (/usr/sbin/lnetctl by default) be removed so that way lnetctl is used exclusively?

Thanks,
Giuseppe Di Natale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20170105/7e17c5c9/attachment.htm>

[lustre-devel] (no subject)

[Amir Shehata]

lctl usage is kept for backwards compatibility. Eventually, we should be
moving to using lnetctl exclusively. Which lustre-release we should do that
in, is the question. 2.10?

thanks
amir

On 4 January 2017 at 16:16, Di Natale, Giuseppe <dinatale2@llnl.gov> wrote:

> Greetings,
>
> I am attempting to port the SysV lnet script as part of a transition to
> systemd. I ran into the following in lustre/scripts/lnet:
>
>         if [ -x $LUSTRE_LNET_CONFIG_UTILITY -a -f
> "$LUSTRE_LNET_CONFIG_FILE" ]; then
>                 $LUSTRE_LNET_CONFIG_UTILITY lnet configure || exit 1
>         else
>                 lctl network up || exit 1
>         fi
>
> Can the check for LUSTRE_LNET_CONFIG_UTILITY  (/usr/sbin/lnetctl by
> default) be removed so that way lnetctl is used exclusively?
>
> Thanks,
> Giuseppe Di Natale
>
> _______________________________________________
> lustre-devel mailing list
> lustre-devel at lists.lustre.org
> http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20170110/8d4158a6/attachment.htm>

[lustre-devel] (no subject)

[Christopher J. Morrone]

Sounds good to me.  Ideally, lnetctl should be able to do everything
that lctl could do (plus all of the new features).  Has it reached
parity?  If not, what else still remains to be done?

Chris

On 01/10/2017 12:15 PM, Amir Shehata wrote:
> lctl usage is kept for backwards compatibility. Eventually, we should be
> moving to using lnetctl exclusively. Which lustre-release we should do
> that in, is the question. 2.10?
> 
> thanks
> amir
> 
> On 4 January 2017 at 16:16, Di Natale, Giuseppe <dinatale2@llnl.gov
> <mailto:dinatale2@llnl.gov>> wrote:
> 
>     Greetings,
> 
>     I am attempting to port the SysV lnet script as part of a transition
>     to systemd. I ran into the following in lustre/scripts/lnet:
> 
>             if [ -x $LUSTRE_LNET_CONFIG_UTILITY -a -f
>     "$LUSTRE_LNET_CONFIG_FILE" ]; then
>                     $LUSTRE_LNET_CONFIG_UTILITY lnet configure || exit 1
>             else
>                     lctl network up || exit 1
>             fi
> 
>     Can the check for LUSTRE_LNET_CONFIG_UTILITY  (/usr/sbin/lnetctl by
>     default) be removed so that way lnetctl is used exclusively?
> 
>     Thanks,
>     Giuseppe Di Natale
> 
>     _______________________________________________
>     lustre-devel mailing list
>     lustre-devel at lists.lustre.org <mailto:lustre-devel@lists.lustre.org>
>     http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
>     <http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org>
> 
> 
> 
> 
> _______________________________________________
> lustre-devel mailing list
> lustre-devel at lists.lustre.org
> http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
> 

[lustre-devel] (no subject)

[Amir Shehata]

lnetctl was designed to control LNet only. We have not moved the rest of
the lctl functionality. lctl does a lot of other lustre specific functions.

The idea was to have lnetctl be only LNet specific, and lctl lustre
specific. In essence we are attempting to decouple LNet from lustre. There
has been some talk about upstreaming LNet before lustre with all the work
that James Simmons from ORNL is doing.

thanks
amir

On 10 January 2017 at 14:06, Christopher J. Morrone <morrone2@llnl.gov>
wrote:

> Sounds good to me.  Ideally, lnetctl should be able to do everything
> that lctl could do (plus all of the new features).  Has it reached
> parity?  If not, what else still remains to be done?
>
> Chris
>
> On 01/10/2017 12:15 PM, Amir Shehata wrote:
> > lctl usage is kept for backwards compatibility. Eventually, we should be
> > moving to using lnetctl exclusively. Which lustre-release we should do
> > that in, is the question. 2.10?
> >
> > thanks
> > amir
> >
> > On 4 January 2017 at 16:16, Di Natale, Giuseppe <dinatale2@llnl.gov
> > <mailto:dinatale2@llnl.gov>> wrote:
> >
> >     Greetings,
> >
> >     I am attempting to port the SysV lnet script as part of a transition
> >     to systemd. I ran into the following in lustre/scripts/lnet:
> >
> >             if [ -x $LUSTRE_LNET_CONFIG_UTILITY -a -f
> >     "$LUSTRE_LNET_CONFIG_FILE" ]; then
> >                     $LUSTRE_LNET_CONFIG_UTILITY lnet configure || exit 1
> >             else
> >                     lctl network up || exit 1
> >             fi
> >
> >     Can the check for LUSTRE_LNET_CONFIG_UTILITY  (/usr/sbin/lnetctl by
> >     default) be removed so that way lnetctl is used exclusively?
> >
> >     Thanks,
> >     Giuseppe Di Natale
> >
> >     _______________________________________________
> >     lustre-devel mailing list
> >     lustre-devel at lists.lustre.org <mailto:lustre-devel@lists.lustre.org>
> >     http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
> >     <http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org>
> >
> >
> >
> >
> > _______________________________________________
> > lustre-devel mailing list
> > lustre-devel at lists.lustre.org
> > http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
> >
>
> _______________________________________________
> lustre-devel mailing list
> lustre-devel at lists.lustre.org
> http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20170110/358aa93b/attachment.htm>

[lustre-devel] (no subject)

[Dilger, Andreas]

It's fine to add the lnet-specific functionality from lctl to lnetctl, but we shouldn't remove existing functionality from lctl to avoid breaking scripts that may be using it today.  4+ releases after all of the LNet specific lctl functionality has been added to lnetctl we can start printing deprecation warnings, and after 8+ releases they can be removed.

Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Intel High Performance Data Division

On 2017/01/10, 18:08, "lustre-devel on behalf of Amir Shehata" <lustre-devel-bounces at lists.lustre.org<mailto:lustre-devel-bounces@lists.lustre.org> on behalf of amir.shehata.whamcloud at gmail.com<mailto:amir.shehata.whamcloud@gmail.com>> wrote:

lnetctl was designed to control LNet only. We have not moved the rest of the lctl functionality. lctl does a lot of other lustre specific functions.

The idea was to have lnetctl be only LNet specific, and lctl lustre specific. In essence we are attempting to decouple LNet from lustre. There has been some talk about upstreaming LNet before lustre with all the work that James Simmons from ORNL is doing.

thanks
amir

On 10 January 2017 at 14:06, Christopher J. Morrone <morrone2 at llnl.gov<mailto:morrone2@llnl.gov>> wrote:
Sounds good to me.  Ideally, lnetctl should be able to do everything
that lctl could do (plus all of the new features).  Has it reached
parity?  If not, what else still remains to be done?

Chris

On 01/10/2017 12:15 PM, Amir Shehata wrote:
> lctl usage is kept for backwards compatibility. Eventually, we should be
> moving to using lnetctl exclusively. Which lustre-release we should do
> that in, is the question. 2.10?
>
> thanks
> amir
>
> On 4 January 2017 at 16:16, Di Natale, Giuseppe <dinatale2 at llnl.gov<mailto:dinatale2@llnl.gov>
> <mailto:dinatale2 at llnl.gov<mailto:dinatale2@llnl.gov>>> wrote:
>
>     Greetings,
>
>     I am attempting to port the SysV lnet script as part of a transition
>     to systemd. I ran into the following in lustre/scripts/lnet:
>
>             if [ -x $LUSTRE_LNET_CONFIG_UTILITY -a -f
>     "$LUSTRE_LNET_CONFIG_FILE" ]; then
>                     $LUSTRE_LNET_CONFIG_UTILITY lnet configure || exit 1
>             else
>                     lctl network up || exit 1
>             fi
>
>     Can the check for LUSTRE_LNET_CONFIG_UTILITY  (/usr/sbin/lnetctl by
>     default) be removed so that way lnetctl is used exclusively?
>
>     Thanks,
>     Giuseppe Di Natale
>
>     _______________________________________________
>     lustre-devel mailing list
>     lustre-devel at lists.lustre.org<mailto:lustre-devel@lists.lustre.org> <mailto:lustre-devel at lists.lustre.org<mailto:lustre-devel@lists.lustre.org>>
>     http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
>     <http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org>
>
>
>
>
> _______________________________________________
> lustre-devel mailing list
> lustre-devel at lists.lustre.org<mailto:lustre-devel@lists.lustre.org>
> http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
>

_______________________________________________
lustre-devel mailing list
lustre-devel at lists.lustre.org<mailto:lustre-devel@lists.lustre.org>
http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20170111/60435393/attachment-0001.htm>

[lustre-devel] (no subject)

[Christopher J. Morrone]

Right, I meant copy in lnet-specific functionality from lctl to lnetctl.
 I didn't mean to sound like I was suggesting moving the rest of lctl's
non-lnet parts into lnetctl.

Chris

On 01/10/2017 08:18 PM, Dilger, Andreas wrote:
> It's fine to add the lnet-specific functionality from lctl to lnetctl,
> but we shouldn't remove existing functionality from lctl to avoid
> breaking scripts that may be using it today.  4+ releases after all of
> the LNet specific lctl functionality has been added to lnetctl we can
> start printing deprecation warnings, and after 8+ releases they can be
> removed.
> 
>  
> 
> Cheers, Andreas
> 
> -- 
> 
> Andreas Dilger
> 
> Lustre Principal Architect
> 
> Intel High Performance Data Division
> 
>  
> 
> On 2017/01/10, 18:08, "lustre-devel on behalf of Amir Shehata"
> <lustre-devel-bounces@lists.lustre.org
> <mailto:lustre-devel-bounces@lists.lustre.org> on behalf of
> amir.shehata.whamcloud at gmail.com
> <mailto:amir.shehata.whamcloud@gmail.com>> wrote:
> 
>  
> 
> lnetctl was designed to control LNet only. We have not moved the rest of
> the lctl functionality. lctl does a lot of other lustre specific functions.
> 
>  
> 
> The idea was to have lnetctl be only LNet specific, and lctl lustre
> specific. In essence we are attempting to decouple LNet from lustre.
> There has been some talk about upstreaming LNet before lustre with all
> the work that James Simmons from ORNL is doing.
> 
>  
> 
> thanks
> 
> amir
> 
>  
> 
> On 10 January 2017 at 14:06, Christopher J. Morrone <morrone2@llnl.gov
> <mailto:morrone2@llnl.gov>> wrote:
> 
>     Sounds good to me.  Ideally, lnetctl should be able to do everything
>     that lctl could do (plus all of the new features).  Has it reached
>     parity?  If not, what else still remains to be done?
> 
>     Chris
> 
>     On 01/10/2017 12:15 PM, Amir Shehata wrote:
>     > lctl usage is kept for backwards compatibility. Eventually, we
>     should be
>     > moving to using lnetctl exclusively. Which lustre-release we should do
>     > that in, is the question. 2.10?
>     >
>     > thanks
>     > amir
>     >
>     > On 4 January 2017 at 16:16, Di Natale, Giuseppe
>     <dinatale2 at llnl.gov <mailto:dinatale2@llnl.gov>
>     > <mailto:dinatale2 at llnl.gov <mailto:dinatale2@llnl.gov>>> wrote:
>     >
>     >     Greetings,
>     >
>     >     I am attempting to port the SysV lnet script as part of a
>     transition
>     >     to systemd. I ran into the following in lustre/scripts/lnet:
>     >
>     >             if [ -x $LUSTRE_LNET_CONFIG_UTILITY -a -f
>     >     "$LUSTRE_LNET_CONFIG_FILE" ]; then
>     >                     $LUSTRE_LNET_CONFIG_UTILITY lnet configure ||
>     exit 1
>     >             else
>     >                     lctl network up || exit 1
>     >             fi
>     >
>     >     Can the check for LUSTRE_LNET_CONFIG_UTILITY 
>     (/usr/sbin/lnetctl by
>     >     default) be removed so that way lnetctl is used exclusively?
>     >
>     >     Thanks,
>     >     Giuseppe Di Natale
>     >
>     >     _______________________________________________
>     >     lustre-devel mailing list
>     >     lustre-devel at lists.lustre.org
>     <mailto:lustre-devel@lists.lustre.org>
>     <mailto:lustre-devel@lists.lustre.org
>     <mailto:lustre-devel@lists.lustre.org>>
>     >     http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
>     >     <http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org>
> 
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > lustre-devel mailing list
>     > lustre-devel at lists.lustre.org <mailto:lustre-devel@lists.lustre.org>
>     > http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
>     >
> 
>     _______________________________________________
>     lustre-devel mailing list
>     lustre-devel at lists.lustre.org <mailto:lustre-devel@lists.lustre.org>
>     http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
> 
>  
> 

[lustre-devel] (no subject)

[James Simmons]

> Sounds good to me.  Ideally, lnetctl should be able to do everything
> that lctl could do (plus all of the new features).  Has it reached
> parity?  If not, what else still remains to be done?

No lctl pings and the peer and connection handling is missing. I did
some work to support the missing features in lnetctl and combined with
multi-rail should fill in the gaps. Also we are missing lnetctl ping
but I think multi-rail might fix that. Not 100% sure tho.

> 
> Chris
> 
> On 01/10/2017 12:15 PM, Amir Shehata wrote:
> > lctl usage is kept for backwards compatibility. Eventually, we should be
> > moving to using lnetctl exclusively. Which lustre-release we should do
> > that in, is the question. 2.10?
> > 
> > thanks
> > amir
> > 
> > On 4 January 2017 at 16:16, Di Natale, Giuseppe <dinatale2@llnl.gov
> > <mailto:dinatale2@llnl.gov>> wrote:
> > 
> >     Greetings,
> > 
> >     I am attempting to port the SysV lnet script as part of a transition
> >     to systemd. I ran into the following in lustre/scripts/lnet:
> > 
> >             if [ -x $LUSTRE_LNET_CONFIG_UTILITY -a -f
> >     "$LUSTRE_LNET_CONFIG_FILE" ]; then
> >                     $LUSTRE_LNET_CONFIG_UTILITY lnet configure || exit 1
> >             else
> >                     lctl network up || exit 1
> >             fi
> > 
> >     Can the check for LUSTRE_LNET_CONFIG_UTILITY  (/usr/sbin/lnetctl by
> >     default) be removed so that way lnetctl is used exclusively?
> > 
> >     Thanks,
> >     Giuseppe Di Natale
> > 
> >     _______________________________________________
> >     lustre-devel mailing list
> >     lustre-devel at lists.lustre.org <mailto:lustre-devel@lists.lustre.org>
> >     http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
> >     <http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org>
> > 
> > 
> > 
> > 
> > _______________________________________________
> > lustre-devel mailing list
> > lustre-devel at lists.lustre.org
> > http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
> > 
> 
> _______________________________________________
> lustre-devel mailing list
> lustre-devel at lists.lustre.org
> http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
> 

[lustre-devel] (no subject)

[James Simmons]

> lnetctl was designed to control LNet only. We have not moved the rest of the lctl functionality. lctl does
> a lot of other lustre specific functions.
> The idea was to have lnetctl be only LNet specific, and lctl lustre specific. In essence we are attempting
> to decouple LNet from lustre. There has been some talk about upstreaming LNet before lustre with all the
> work that James Simmons from ORNL is doing.

Already done. LNet is ahead a bit for the upstream client from master but 
just recently I have been backporting that work to the OpenSFS branch.
Its almost synced up now. As for LNet leaving staging Greg wanted both
LNet and lustre to leaving staging at the same time.

> thanks
> amir
> 
> On 10 January 2017 at 14:06, Christopher J. Morrone <morrone2@llnl.gov> wrote:
>       Sounds good to me.? Ideally, lnetctl should be able to do everything
>       that lctl could do (plus all of the new features).? Has it reached
>       parity?? If not, what else still remains to be done?
> 
>       Chris
> 
>       On 01/10/2017 12:15 PM, Amir Shehata wrote:
>       > lctl usage is kept for backwards compatibility. Eventually, we should be
>       > moving to using lnetctl exclusively. Which lustre-release we should do
>       > that in, is the question. 2.10?
>       >
>       > thanks
>       > amir
>       >
>       > On 4 January 2017 at 16:16, Di Natale, Giuseppe <dinatale2@llnl.gov
>       > <mailto:dinatale2@llnl.gov>> wrote:
>       >
>       >? ? ?Greetings,
>       >
>       >? ? ?I am attempting to port the SysV lnet script as part of a transition
>       >? ? ?to systemd. I ran into the following in lustre/scripts/lnet:
>       >
>       >? ? ? ? ? ? ?if [ -x $LUSTRE_LNET_CONFIG_UTILITY -a -f
>       >? ? ?"$LUSTRE_LNET_CONFIG_FILE" ]; then
>       >? ? ? ? ? ? ? ? ? ? ?$LUSTRE_LNET_CONFIG_UTILITY lnet configure || exit 1
>       >? ? ? ? ? ? ?else
>       >? ? ? ? ? ? ? ? ? ? ?lctl network up || exit 1
>       >? ? ? ? ? ? ?fi
>       >
>       >? ? ?Can the check for LUSTRE_LNET_CONFIG_UTILITY? (/usr/sbin/lnetctl by
>       >? ? ?default) be removed so that way lnetctl is used exclusively?
>       >
>       >? ? ?Thanks,
>       >? ? ?Giuseppe Di Natale
>       >
>       >? ? ?_______________________________________________
>       >? ? ?lustre-devel mailing list
>       >? ? ?lustre-devel at lists.lustre.org <mailto:lustre-devel@lists.lustre.org>
>       >? ? ?http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
>       >? ? ?<http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org>
>       >
>       >
>       >
>       >
>       > _______________________________________________
>       > lustre-devel mailing list
>       > lustre-devel at lists.lustre.org
>       > http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
>       >
> 
>       _______________________________________________
>       lustre-devel mailing list
>       lustre-devel at lists.lustre.org
>       http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
> 
> 
> 
> 

[lustre-devel] (no subject)

[James Simmons]

> Right, I meant copy in lnet-specific functionality from lctl to lnetctl.
>  I didn't mean to sound like I was suggesting moving the rest of lctl's
> non-lnet parts into lnetctl.

I think Chris means is that if we make liblnetconfig mandatory then we can
link lctl to that library and replace alot of the functionality lctl is 
doing itself with the work in liblnetconfig.

Currently the library situation is a mess. We have:

liblnetconfig.so (okay)
libcfs.a
libcfsutil.a
libptlctl.a
liblustreapi.so

For liblustreapi.so it linked the libcfs*.a and libptlctl.a static
libraries. If you look at libptlctl.a its just composed of two source
files. One is debug.c which really belongs in libcfs. The other could
be replaced by libnetconfig. So we can kill off libptlctl.a. For
libcfsutil.a that should just merge into libcfs.

> On 01/10/2017 08:18 PM, Dilger, Andreas wrote:
> > It's fine to add the lnet-specific functionality from lctl to lnetctl,
> > but we shouldn't remove existing functionality from lctl to avoid
> > breaking scripts that may be using it today.  4+ releases after all of
> > the LNet specific lctl functionality has been added to lnetctl we can
> > start printing deprecation warnings, and after 8+ releases they can be
> > removed.
> > 
> >  
> > 
> > Cheers, Andreas
> > 
> > -- 
> > 
> > Andreas Dilger
> > 
> > Lustre Principal Architect
> > 
> > Intel High Performance Data Division
> > 
> >  
> > 
> > On 2017/01/10, 18:08, "lustre-devel on behalf of Amir Shehata"
> > <lustre-devel-bounces@lists.lustre.org
> > <mailto:lustre-devel-bounces@lists.lustre.org> on behalf of
> > amir.shehata.whamcloud at gmail.com
> > <mailto:amir.shehata.whamcloud@gmail.com>> wrote:
> > 
> >  
> > 
> > lnetctl was designed to control LNet only. We have not moved the rest of
> > the lctl functionality. lctl does a lot of other lustre specific functions.
> > 
> >  
> > 
> > The idea was to have lnetctl be only LNet specific, and lctl lustre
> > specific. In essence we are attempting to decouple LNet from lustre.
> > There has been some talk about upstreaming LNet before lustre with all
> > the work that James Simmons from ORNL is doing.
> > 
> >  
> > 
> > thanks
> > 
> > amir
> > 
> >  
> > 
> > On 10 January 2017 at 14:06, Christopher J. Morrone <morrone2@llnl.gov
> > <mailto:morrone2@llnl.gov>> wrote:
> > 
> >     Sounds good to me.  Ideally, lnetctl should be able to do everything
> >     that lctl could do (plus all of the new features).  Has it reached
> >     parity?  If not, what else still remains to be done?
> > 
> >     Chris
> > 
> >     On 01/10/2017 12:15 PM, Amir Shehata wrote:
> >     > lctl usage is kept for backwards compatibility. Eventually, we
> >     should be
> >     > moving to using lnetctl exclusively. Which lustre-release we should do
> >     > that in, is the question. 2.10?
> >     >
> >     > thanks
> >     > amir
> >     >
> >     > On 4 January 2017 at 16:16, Di Natale, Giuseppe
> >     <dinatale2 at llnl.gov <mailto:dinatale2@llnl.gov>
> >     > <mailto:dinatale2 at llnl.gov <mailto:dinatale2@llnl.gov>>> wrote:
> >     >
> >     >     Greetings,
> >     >
> >     >     I am attempting to port the SysV lnet script as part of a
> >     transition
> >     >     to systemd. I ran into the following in lustre/scripts/lnet:
> >     >
> >     >             if [ -x $LUSTRE_LNET_CONFIG_UTILITY -a -f
> >     >     "$LUSTRE_LNET_CONFIG_FILE" ]; then
> >     >                     $LUSTRE_LNET_CONFIG_UTILITY lnet configure ||
> >     exit 1
> >     >             else
> >     >                     lctl network up || exit 1
> >     >             fi
> >     >
> >     >     Can the check for LUSTRE_LNET_CONFIG_UTILITY 
> >     (/usr/sbin/lnetctl by
> >     >     default) be removed so that way lnetctl is used exclusively?
> >     >
> >     >     Thanks,
> >     >     Giuseppe Di Natale
> >     >
> >     >     _______________________________________________
> >     >     lustre-devel mailing list
> >     >     lustre-devel at lists.lustre.org
> >     <mailto:lustre-devel@lists.lustre.org>
> >     <mailto:lustre-devel@lists.lustre.org
> >     <mailto:lustre-devel@lists.lustre.org>>
> >     >     http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
> >     >     <http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org>
> > 
> >     >
> >     >
> >     >
> >     >
> >     > _______________________________________________
> >     > lustre-devel mailing list
> >     > lustre-devel at lists.lustre.org <mailto:lustre-devel@lists.lustre.org>
> >     > http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
> >     >
> > 
> >     _______________________________________________
> >     lustre-devel mailing list
> >     lustre-devel at lists.lustre.org <mailto:lustre-devel@lists.lustre.org>
> >     http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
> > 
> >  
> > 
> 
> _______________________________________________
> lustre-devel mailing list
> lustre-devel at lists.lustre.org
> http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
> 

[lustre-devel] (no subject)

[Christopher J. Morrone]

On 01/16/2017 01:02 PM, James Simmons wrote:
> 
>> Sounds good to me.  Ideally, lnetctl should be able to do everything
>> that lctl could do (plus all of the new features).  Has it reached
>> parity?  If not, what else still remains to be done?
> 
> No lctl pings and the peer and connection handling is missing. I did
> some work to support the missing features in lnetctl and combined with
> multi-rail should fill in the gaps. Also we are missing lnetctl ping
> but I think multi-rail might fix that. Not 100% sure tho.

Thanks, James.  That is the information that I was looking for.

Chris

[lustre-devel] (no subject)

[Amir Shehata]

We have a patch for lnetctl ping coming in soon.

On 16 January 2017 at 13:02, James Simmons <jsimmons@infradead.org> wrote:

>
> > Sounds good to me.  Ideally, lnetctl should be able to do everything
> > that lctl could do (plus all of the new features).  Has it reached
> > parity?  If not, what else still remains to be done?
>
> No lctl pings and the peer and connection handling is missing. I did
> some work to support the missing features in lnetctl and combined with
> multi-rail should fill in the gaps. Also we are missing lnetctl ping
> but I think multi-rail might fix that. Not 100% sure tho.
>
> >
> > Chris
> >
> > On 01/10/2017 12:15 PM, Amir Shehata wrote:
> > > lctl usage is kept for backwards compatibility. Eventually, we should
> be
> > > moving to using lnetctl exclusively. Which lustre-release we should do
> > > that in, is the question. 2.10?
> > >
> > > thanks
> > > amir
> > >
> > > On 4 January 2017 at 16:16, Di Natale, Giuseppe <dinatale2@llnl.gov
> > > <mailto:dinatale2@llnl.gov>> wrote:
> > >
> > >     Greetings,
> > >
> > >     I am attempting to port the SysV lnet script as part of a
> transition
> > >     to systemd. I ran into the following in lustre/scripts/lnet:
> > >
> > >             if [ -x $LUSTRE_LNET_CONFIG_UTILITY -a -f
> > >     "$LUSTRE_LNET_CONFIG_FILE" ]; then
> > >                     $LUSTRE_LNET_CONFIG_UTILITY lnet configure || exit
> 1
> > >             else
> > >                     lctl network up || exit 1
> > >             fi
> > >
> > >     Can the check for LUSTRE_LNET_CONFIG_UTILITY  (/usr/sbin/lnetctl by
> > >     default) be removed so that way lnetctl is used exclusively?
> > >
> > >     Thanks,
> > >     Giuseppe Di Natale
> > >
> > >     _______________________________________________
> > >     lustre-devel mailing list
> > >     lustre-devel at lists.lustre.org <mailto:lustre-devel@lists.
> lustre.org>
> > >     http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
> > >     <http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org>
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > lustre-devel mailing list
> > > lustre-devel at lists.lustre.org
> > > http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
> > >
> >
> > _______________________________________________
> > lustre-devel mailing list
> > lustre-devel at lists.lustre.org
> > http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
> >
> _______________________________________________
> lustre-devel mailing list
> lustre-devel at lists.lustre.org
> http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20170118/75d022c0/attachment.htm>

(no subject)

[Fabian Huegel]

We cleaned up a lot of checkpatch errors and warnings in obd_class.h,
but there are still some CHECKs and two warnings about flow control
inside macros left.

Changing those macros to inline functions would probably
be a good idea, unfortunatly it's not straightforward since they use
'#op' to print the name of the operation.

We also did some aligning to make the code more readable and removed
an unnecessary macro.

We only tested, that the kernel still compiles and the lustre kernel
module loads successfully, but given the harmless nature of these
changes we don't expect any problems.

The patches are based on the staging-testing branch of the staging tree.

[PATCH 1/8] staging: lustre: Enclose complex macros in parentheses

[Fabian Huegel]

Checkpatch wants complex macros to be enclosed in parentheses, so we
put parentheses around these four macros.

Signed-off-by: Fabian Huegel <fabian_huegel@web.de>
Signed-off-by: Christoph Volkert <linux@christoph-volkert.de>
---
 drivers/staging/lustre/lustre/include/obd_class.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/obd_class.h b/drivers/staging/lustre/lustre/include/obd_class.h
index 67c535c..5c8cf30 100644
--- a/drivers/staging/lustre/lustre/include/obd_class.h
+++ b/drivers/staging/lustre/lustre/include/obd_class.h
@@ -294,10 +294,10 @@ struct obdo;
 
 void obdo_to_ioobj(const struct obdo *oa, struct obd_ioobj *ioobj);
 
-#define OBT(dev)	(dev)->obd_type
-#define OBP(dev, op)    (dev)->obd_type->typ_dt_ops->op
-#define MDP(dev, op)    (dev)->obd_type->typ_md_ops->op
-#define CTXTP(ctxt, op) (ctxt)->loc_logops->lop_##op
+#define OBT(dev)	((dev)->obd_type)
+#define OBP(dev, op)    ((dev)->obd_type->typ_dt_ops->op)
+#define MDP(dev, op)    ((dev)->obd_type->typ_md_ops->op)
+#define CTXTP(ctxt, op) ((ctxt)->loc_logops->lop_##op)
 
 /* Ensure obd_setup: used for cleanup which must be called
  * while obd is stopping
-- 
2.7.4

[PATCH 2/8] staging: lustre: Enclose complex macros in do-while loops

[Fabian Huegel]

Some complex multi-line macros were not enclosed by a do-while(0),
so we fixed that.

Signed-off-by: Fabian Huegel <fabian_huegel@web.de>
Signed-off-by: Christoph Volkert <linux@christoph-volkert.de>
---
 drivers/staging/lustre/lustre/include/obd_class.h | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/obd_class.h b/drivers/staging/lustre/lustre/include/obd_class.h
index 5c8cf30..dbe8225 100644
--- a/drivers/staging/lustre/lustre/include/obd_class.h
+++ b/drivers/staging/lustre/lustre/include/obd_class.h
@@ -332,22 +332,26 @@ static inline int obd_check_dev_active(struct obd_device *obd)
 	 / sizeof(((struct obd_ops *)(0))->iocontrol))
 
 #define OBD_COUNTER_INCREMENT(obdx, op)			   \
+do {							  \
 	if ((obdx)->obd_stats) {				  \
 		unsigned int coffset;			     \
 		coffset = (unsigned int)((obdx)->obd_cntr_base) + \
 			OBD_COUNTER_OFFSET(op);		   \
 		LASSERT(coffset < (obdx)->obd_stats->ls_num);     \
 		lprocfs_counter_incr((obdx)->obd_stats, coffset); \
-	}
+	}							  \
+} while (0)
 
 #define EXP_COUNTER_INCREMENT(export, op)				    \
+do {								\
 	if ((export)->exp_obd->obd_stats) {			  \
 		unsigned int coffset;					\
 		coffset = (unsigned int)((export)->exp_obd->obd_cntr_base) + \
 			OBD_COUNTER_OFFSET(op);			      \
 		LASSERT(coffset < (export)->exp_obd->obd_stats->ls_num);     \
 		lprocfs_counter_incr((export)->exp_obd->obd_stats, coffset); \
-	}
+	}								\
+} while (0)
 
 #define MD_COUNTER_OFFSET(op)				   \
 	((offsetof(struct md_ops, op) -		   \
@@ -355,15 +359,18 @@ static inline int obd_check_dev_active(struct obd_device *obd)
 	 / sizeof(((struct md_ops *)(0))->getstatus))
 
 #define MD_COUNTER_INCREMENT(obdx, op)			   \
+do {						   \
 	if ((obd)->md_stats) {			   \
 		unsigned int coffset;			    \
 		coffset = (unsigned int)((obdx)->md_cntr_base) + \
 			MD_COUNTER_OFFSET(op);		   \
 		LASSERT(coffset < (obdx)->md_stats->ls_num);     \
 		lprocfs_counter_incr((obdx)->md_stats, coffset); \
-	}
+	}							 \
+} while (0)
 
 #define EXP_MD_COUNTER_INCREMENT(export, op)				 \
+do {								\
 	if ((export)->exp_obd->obd_stats) {				  \
 		unsigned int coffset;					\
 		coffset = (unsigned int)((export)->exp_obd->md_cntr_base) +  \
@@ -373,7 +380,8 @@ static inline int obd_check_dev_active(struct obd_device *obd)
 		if ((export)->exp_md_stats)				  \
 			lprocfs_counter_incr(				\
 				(export)->exp_md_stats, coffset);	    \
-	}
+	}								\
+} while (0)
 
 #define EXP_CHECK_MD_OP(exp, op)				\
 do {							    \
-- 
2.7.4

[PATCH 3/8] staging: lustre: Remove DECLARE_LU_VARS macro

[Fabian Huegel]

This macro was only used in four places to declare two variables.
It saved one line of code, but in our opinion hurt readability.
So we removed the macro, substituting every occurrence with the
declaration of the two variables (like the preprocessor would have done).

Signed-off-by: Fabian Huegel <fabian_huegel@web.de>
Signed-off-by: Christoph Volkert <linux@christoph-volkert.de>
---
 drivers/staging/lustre/lustre/include/obd_class.h | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/obd_class.h b/drivers/staging/lustre/lustre/include/obd_class.h
index dbe8225..8fc14ed 100644
--- a/drivers/staging/lustre/lustre/include/obd_class.h
+++ b/drivers/staging/lustre/lustre/include/obd_class.h
@@ -489,14 +489,11 @@ static inline int obd_set_info_async(const struct lu_env *env,
  * obd_precleanup() and obd_cleanup() call both lu_device and obd operations.
  */
 
-#define DECLARE_LU_VARS(ldt, d)		 \
-	struct lu_device_type *ldt;       \
-	struct lu_device *d
-
 static inline int obd_setup(struct obd_device *obd, struct lustre_cfg *cfg)
 {
 	int rc;
-	DECLARE_LU_VARS(ldt, d);
+	struct lu_device_type *ldt;
+	struct lu_device *d;
 
 	ldt = obd->obd_type->typ_lu;
 	if (ldt) {
@@ -534,7 +531,8 @@ static inline int obd_setup(struct obd_device *obd, struct lustre_cfg *cfg)
 static inline int obd_precleanup(struct obd_device *obd)
 {
 	int rc;
-	DECLARE_LU_VARS(ldt, d);
+	struct lu_device_type *ldt;
+	struct lu_device *d;
 
 	rc = obd_check_dev(obd);
 	if (rc)
@@ -560,7 +558,8 @@ static inline int obd_precleanup(struct obd_device *obd)
 static inline int obd_cleanup(struct obd_device *obd)
 {
 	int rc;
-	DECLARE_LU_VARS(ldt, d);
+	struct lu_device_type *ldt;
+	struct lu_device *d;
 
 	rc = obd_check_dev(obd);
 	if (rc)
@@ -608,7 +607,8 @@ static inline int
 obd_process_config(struct obd_device *obd, int datalen, void *data)
 {
 	int rc;
-	DECLARE_LU_VARS(ldt, d);
+	struct lu_device_type *ldt;
+	struct lu_device *d;
 
 	rc = obd_check_dev(obd);
 	if (rc)
-- 
2.7.4

[PATCH 4/8] staging: lustre: Fix comment style

[Fabian Huegel]

Most multi-line comments started on the first line, but the preferred
linux kernel style is to start multi-line comments on the second line.
Some comments became less readable after the change, so we changed them
to single-line comments.

Signed-off-by: Fabian Huegel <fabian_huegel@web.de>
Signed-off-by: Christoph Volkert <linux@christoph-volkert.de>
---
 drivers/staging/lustre/lustre/include/obd_class.h | 47 +++++++++++++----------
 1 file changed, 27 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/obd_class.h b/drivers/staging/lustre/lustre/include/obd_class.h
index 8fc14ed..9a61117 100644
--- a/drivers/staging/lustre/lustre/include/obd_class.h
+++ b/drivers/staging/lustre/lustre/include/obd_class.h
@@ -40,15 +40,12 @@
 #include <lustre_lib.h>
 #include <lprocfs_status.h>
 
-#define OBD_STATFS_NODELAY      0x0001  /* requests should be send without delay
-					 * and resends for avoid deadlocks
-					 */
-#define OBD_STATFS_FROM_CACHE   0x0002  /* the statfs callback should not update
-					 * obd_osfs_age
-					 */
-#define OBD_STATFS_FOR_MDT0	0x0004	/* The statfs is only for retrieving
-					 * information from MDT0.
-					 */
+/* requests should be send without delay and resends for avoid deadlocks */
+#define OBD_STATFS_NODELAY      0x0001
+/* the statfs callback should not update obd_osfs_age */
+#define OBD_STATFS_FROM_CACHE   0x0002
+/* the statfs is only for retrieving information from MDT0 */
+#define OBD_STATFS_FOR_MDT0	0x0004
 
 /* OBD Device Declarations */
 extern struct obd_device *obd_devs[MAX_OBD_DEVICES];
@@ -137,7 +134,7 @@ int class_config_llog_handler(const struct lu_env *env,
 			      struct llog_rec_hdr *rec, void *data);
 int class_add_uuid(const char *uuid, __u64 nid);
 
-/*obdecho*/
+/* obdecho */
 void lprocfs_echo_init_vars(struct lprocfs_static_vars *lvars);
 
 #define CFG_F_START     0x01   /* Set when we start updating from a log */
@@ -182,7 +179,8 @@ struct config_llog_data {
 	struct obd_export	  *cld_mgcexp;
 	struct mutex		    cld_lock;
 	int			 cld_type;
-	unsigned int		cld_stopping:1, /* we were told to stop
+	unsigned int		cld_stopping:1, /*
+						 * we were told to stop
 						 * watching
 						 */
 				cld_lostlock:1; /* lock not requeued */
@@ -299,7 +297,8 @@ void obdo_to_ioobj(const struct obdo *oa, struct obd_ioobj *ioobj);
 #define MDP(dev, op)    ((dev)->obd_type->typ_md_ops->op)
 #define CTXTP(ctxt, op) ((ctxt)->loc_logops->lop_##op)
 
-/* Ensure obd_setup: used for cleanup which must be called
+/*
+ * Ensure obd_setup: used for cleanup which must be called
  * while obd is stopping
  */
 static inline int obd_check_dev(struct obd_device *obd)
@@ -586,7 +585,8 @@ static inline int obd_cleanup(struct obd_device *obd)
 
 static inline void obd_cleanup_client_import(struct obd_device *obd)
 {
-	/* If we set up but never connected, the
+	/*
+	 * If we set up but never connected, the
 	 * client import will not have been cleaned.
 	 */
 	down_write(&obd->u.cli.cl_sem);
@@ -725,7 +725,8 @@ static inline struct obd_uuid *obd_get_uuid(struct obd_export *exp)
 	return uuid;
 }
 
-/** Create a new /a exp on device /a obd for the uuid /a cluuid
+/*
+ * Create a new /a exp on device /a obd for the uuid /a cluuid
  * @param exp New export handle
  * @param d Connect data, supported flags are set, flags also understood
  *    by obd are returned.
@@ -737,7 +738,8 @@ static inline int obd_connect(const struct lu_env *env,
 			      void *localdata)
 {
 	int rc;
-	__u64 ocf = data ? data->ocd_connect_flags : 0; /* for post-condition
+	__u64 ocf = data ? data->ocd_connect_flags : 0; /*
+							 * for post-condition
 							 * check
 							 */
 
@@ -902,7 +904,8 @@ static inline int obd_destroy_export(struct obd_export *exp)
 	return 0;
 }
 
-/* @max_age is the oldest time in jiffies that we accept using a cached data.
+/*
+ * @max_age is the oldest time in jiffies that we accept using a cached data.
  * If the cache is older than @max_age we will get a new value from the
  * target.  Use a value of "cfs_time_current() + HZ" to guarantee freshness.
  */
@@ -963,7 +966,8 @@ static inline int obd_statfs_rqset(struct obd_export *exp,
 	return rc;
 }
 
-/* @max_age is the oldest time in jiffies that we accept using a cached data.
+/*
+ * @max_age is the oldest time in jiffies that we accept using a cached data.
  * If the cache is older than @max_age we will get a new value from the
  * target.  Use a value of "cfs_time_current() + HZ" to guarantee freshness.
  */
@@ -1126,7 +1130,8 @@ static inline int obd_quotactl(struct obd_export *exp,
 static inline int obd_health_check(const struct lu_env *env,
 				   struct obd_device *obd)
 {
-	/* returns: 0 on healthy
+	/*
+	 * returns: 0 on healthy
 	 *	 >0 on unhealthy + reason code/flag
 	 *	    however the only supported reason == 1 right now
 	 *	    We'll need to define some better reasons
@@ -1499,7 +1504,8 @@ static inline int md_get_fid_from_lsm(struct obd_export *exp,
 	return rc;
 }
 
-/* Unpack an MD struct from disk to in-memory format.
+/*
+ * Unpack an MD struct from disk to in-memory format.
  * Returns +ve size of unpacked MD (0 for free), or -ve error.
  *
  * If *plsm != NULL and lmm == NULL then *lsm will be freed.
@@ -1535,7 +1541,8 @@ struct lwp_register_item {
 	char		    lri_name[MTI_NAME_MAXLEN];
 };
 
-/* I'm as embarrassed about this as you are.
+/*
+ * I'm as embarrassed about this as you are.
  *
  * <shaver> // XXX do not look into _superhack with remaining eye
  * <shaver> // XXX if this were any uglier, I'd get my own show on MTV
-- 
2.7.4

[PATCH 5/8] staging: lustre: Add identifier names to function declarations

[Fabian Huegel]

Checkpatch was complaining about missing identifier names in function
declarations. So we added the missing names according to the names in
the respective function implementation. *obd_import* was sometimes named
*import* and sometimes *imp* (in genops.c), so to avoid confusion we just
named it imp everywhere.

Signed-off-by: Fabian Huegel <fabian_huegel@web.de>
Signed-off-by: Christoph Volkert <linux@christoph-volkert.de>
---
 drivers/staging/lustre/lustre/include/obd_class.h | 22 ++++++++++++----------
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/obd_class.h b/drivers/staging/lustre/lustre/include/obd_class.h
index 9a61117..d195866 100644
--- a/drivers/staging/lustre/lustre/include/obd_class.h
+++ b/drivers/staging/lustre/lustre/include/obd_class.h
@@ -52,7 +52,7 @@ extern struct obd_device *obd_devs[MAX_OBD_DEVICES];
 extern rwlock_t obd_dev_lock;
 
 /* OBD Operations Declarations */
-struct obd_device *class_exp2obd(struct obd_export *);
+struct obd_device *class_exp2obd(struct obd_export *exp);
 int class_handle_ioctl(unsigned int cmd, unsigned long arg);
 int lustre_get_jobid(char *jobid);
 
@@ -60,10 +60,10 @@ struct lu_device_type;
 
 /* genops.c */
 extern struct list_head obd_types;
-struct obd_export *class_conn2export(struct lustre_handle *);
-int class_register_type(struct obd_ops *, struct md_ops *,
-			const char *nm, struct lu_device_type *ldt);
-int class_unregister_type(const char *nm);
+struct obd_export *class_conn2export(struct lustre_handle *conn);
+int class_register_type(struct obd_ops *dt_ops, struct md_ops *md_ops,
+			const char *name, struct lu_device_type *ldt);
+int class_unregister_type(const char *name);
 
 struct obd_device *class_newdev(const char *type_name, const char *name);
 void class_release_dev(struct obd_device *obd);
@@ -203,9 +203,11 @@ void class_del_profiles(void);
 
 #if LUSTRE_TRACKS_LOCK_EXP_REFS
 
-void __class_export_add_lock_ref(struct obd_export *, struct ldlm_lock *);
-void __class_export_del_lock_ref(struct obd_export *, struct ldlm_lock *);
-extern void (*class_export_dump_hook)(struct obd_export *);
+void __class_export_add_lock_ref(struct obd_export *exp,
+				 struct ldlm_lock *lock);
+void __class_export_del_lock_ref(struct obd_export *exp,
+				 struct ldlm_lock *lock);
+extern void (*class_export_dump_hook)(struct obd_export *exp);
 
 #else
 
@@ -221,8 +223,8 @@ struct obd_export *class_new_export(struct obd_device *obddev,
 				    struct obd_uuid *cluuid);
 void class_unlink_export(struct obd_export *exp);
 
-struct obd_import *class_import_get(struct obd_import *);
-void class_import_put(struct obd_import *);
+struct obd_import *class_import_get(struct obd_import *imp);
+void class_import_put(struct obd_import *imp);
 struct obd_import *class_new_import(struct obd_device *obd);
 void class_destroy_import(struct obd_import *exp);
 
-- 
2.7.4

[PATCH 6/8] staging: lustre: Fix overlong lines

[Fabian Huegel]

Fixed four lines that went over the 80 character limit
to reduce checkpatch warnings.

Signed-off-by: Fabian Huegel <fabian_huegel@web.de>
Signed-off-by: Christoph Volkert <linux@christoph-volkert.de>
---
 drivers/staging/lustre/lustre/include/obd_class.h | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/obd_class.h b/drivers/staging/lustre/lustre/include/obd_class.h
index d195866..06f825b 100644
--- a/drivers/staging/lustre/lustre/include/obd_class.h
+++ b/drivers/staging/lustre/lustre/include/obd_class.h
@@ -850,7 +850,9 @@ static inline int obd_pool_del(struct obd_device *obd, char *poolname)
 	return rc;
 }
 
-static inline int obd_pool_add(struct obd_device *obd, char *poolname, char *ostname)
+static inline int obd_pool_add(struct obd_device *obd,
+			       char *poolname,
+			       char *ostname)
 {
 	int rc;
 
@@ -861,7 +863,9 @@ static inline int obd_pool_add(struct obd_device *obd, char *poolname, char *ost
 	return rc;
 }
 
-static inline int obd_pool_rem(struct obd_device *obd, char *poolname, char *ostname)
+static inline int obd_pool_rem(struct obd_device *obd,
+			       char *poolname,
+			       char *ostname)
 {
 	int rc;
 
@@ -997,7 +1001,8 @@ static inline int obd_statfs(const struct lu_env *env, struct obd_export *exp,
 			spin_unlock(&obd->obd_osfs_lock);
 		}
 	} else {
-		CDEBUG(D_SUPER, "%s: use %p cache blocks %llu/%llu objects %llu/%llu\n",
+		CDEBUG(D_SUPER,
+		       "%s: use %p cache blocks %llu/%llu objects %llu/%llu\n",
 		       obd->obd_name, &obd->obd_osfs,
 		       obd->obd_osfs.os_bavail, obd->obd_osfs.os_blocks,
 		       obd->obd_osfs.os_ffree, obd->obd_osfs.os_files);
@@ -1579,7 +1584,8 @@ int class_procfs_init(void);
 int class_procfs_clean(void);
 
 /* prng.c */
-#define ll_generate_random_uuid(uuid_out) get_random_bytes(uuid_out, sizeof(class_uuid_t))
+#define ll_generate_random_uuid(uuid_out) \
+	get_random_bytes(uuid_out, sizeof(class_uuid_t))
 
 /* statfs_pack.c */
 struct kstatfs;
-- 
2.7.4

[PATCH 7/8] staging: lustre: Align struct member identifiers

[Fabian Huegel]

This patch properly left aligns all member identifiers in every
struct defined in obd_class.h for better readability.

Signed-off-by: Fabian Huegel <fabian_huegel@web.de>
Signed-off-by: Christoph Volkert <linux@christoph-volkert.de>
---
 drivers/staging/lustre/lustre/include/obd_class.h | 44 +++++++++++------------
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/obd_class.h b/drivers/staging/lustre/lustre/include/obd_class.h
index 06f825b..99c9a3d 100644
--- a/drivers/staging/lustre/lustre/include/obd_class.h
+++ b/drivers/staging/lustre/lustre/include/obd_class.h
@@ -145,13 +145,13 @@ void lprocfs_echo_init_vars(struct lprocfs_static_vars *lvars);
 
 /* Passed as data param to class_config_parse_llog */
 struct config_llog_instance {
-	char	       *cfg_obdname;
-	void	       *cfg_instance;
+	char		   *cfg_obdname;
+	void		   *cfg_instance;
 	struct super_block *cfg_sb;
 	struct obd_uuid     cfg_uuid;
 	llog_cb_t	    cfg_callback;
-	int		 cfg_last_idx; /* for partial llog processing */
-	int		 cfg_flags;
+	int		    cfg_last_idx; /* for partial llog processing */
+	int		    cfg_flags;
 };
 
 int class_config_parse_llog(const struct lu_env *env, struct llog_ctxt *ctxt,
@@ -169,31 +169,31 @@ enum {
 
 /* list of active configuration logs  */
 struct config_llog_data {
-	struct ldlm_res_id	  cld_resid;
+	struct ldlm_res_id	    cld_resid;
 	struct config_llog_instance cld_cfg;
-	struct list_head		  cld_list_chain;
-	atomic_t		cld_refcount;
+	struct list_head	    cld_list_chain;
+	atomic_t		    cld_refcount;
 	struct config_llog_data    *cld_sptlrpc;/* depended sptlrpc log */
 	struct config_llog_data	   *cld_params;	/* common parameters log */
 	struct config_llog_data    *cld_recover;/* imperative recover log */
-	struct obd_export	  *cld_mgcexp;
+	struct obd_export	   *cld_mgcexp;
 	struct mutex		    cld_lock;
-	int			 cld_type;
-	unsigned int		cld_stopping:1, /*
-						 * we were told to stop
-						 * watching
-						 */
-				cld_lostlock:1; /* lock not requeued */
-	char			cld_logname[0];
+	int			    cld_type;
+	unsigned int		    cld_stopping:1, /*
+						     * we were told to stop
+						     * watching
+						     */
+				    cld_lostlock:1; /* lock not requeued */
+	char			    cld_logname[0];
 };
 
 struct lustre_profile {
-	struct list_head       lp_list;
-	char	    *lp_profile;
-	char	    *lp_dt;
-	char	    *lp_md;
-	int			lp_refs;
-	bool			lp_list_deleted;
+	struct list_head lp_list;
+	char		*lp_profile;
+	char		*lp_dt;
+	char		*lp_md;
+	int		 lp_refs;
+	bool		 lp_list_deleted;
 };
 
 struct lustre_profile *class_get_profile(const char *prof);
@@ -1544,7 +1544,7 @@ struct lwp_register_item {
 	struct obd_export **lri_exp;
 	register_lwp_cb	    lri_cb_func;
 	void		   *lri_cb_data;
-	struct list_head	    lri_list;
+	struct list_head    lri_list;
 	char		    lri_name[MTI_NAME_MAXLEN];
 };
 
-- 
2.7.4

[PATCH 8/8] staging: lustre: Align backslashes in multi-line macros

[Fabian Huegel]

This patch right aligns all backslashes in multi-line macros
in obd_class.h for better readability.

Signed-off-by: Fabian Huegel <fabian_huegel@web.de>
Signed-off-by: Christoph Volkert <linux@christoph-volkert.de>
---
 drivers/staging/lustre/lustre/include/obd_class.h | 166 +++++++++++-----------
 1 file changed, 83 insertions(+), 83 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/obd_class.h b/drivers/staging/lustre/lustre/include/obd_class.h
index 99c9a3d..6b8027f 100644
--- a/drivers/staging/lustre/lustre/include/obd_class.h
+++ b/drivers/staging/lustre/lustre/include/obd_class.h
@@ -327,116 +327,116 @@ static inline int obd_check_dev_active(struct obd_device *obd)
 	return rc;
 }
 
-#define OBD_COUNTER_OFFSET(op)				  \
-	((offsetof(struct obd_ops, op) -		  \
-	  offsetof(struct obd_ops, iocontrol))		\
-	 / sizeof(((struct obd_ops *)(0))->iocontrol))
-
-#define OBD_COUNTER_INCREMENT(obdx, op)			   \
-do {							  \
-	if ((obdx)->obd_stats) {				  \
-		unsigned int coffset;			     \
-		coffset = (unsigned int)((obdx)->obd_cntr_base) + \
-			OBD_COUNTER_OFFSET(op);		   \
-		LASSERT(coffset < (obdx)->obd_stats->ls_num);     \
-		lprocfs_counter_incr((obdx)->obd_stats, coffset); \
-	}							  \
+#define OBD_COUNTER_OFFSET(op)					\
+	((offsetof(struct obd_ops, op) -			\
+		offsetof(struct obd_ops, iocontrol))		\
+		/ sizeof(((struct obd_ops *)(0))->iocontrol))
+
+#define OBD_COUNTER_INCREMENT(obdx, op)					\
+do {									\
+	if ((obdx)->obd_stats) {					\
+		unsigned int coffset;					\
+		coffset = (unsigned int)((obdx)->obd_cntr_base) +	\
+			OBD_COUNTER_OFFSET(op);				\
+		LASSERT(coffset < (obdx)->obd_stats->ls_num);		\
+		lprocfs_counter_incr((obdx)->obd_stats, coffset);	\
+	}								\
 } while (0)
 
-#define EXP_COUNTER_INCREMENT(export, op)				    \
-do {								\
-	if ((export)->exp_obd->obd_stats) {			  \
-		unsigned int coffset;					\
+#define EXP_COUNTER_INCREMENT(export, op)				     \
+do {									     \
+	if ((export)->exp_obd->obd_stats) {				     \
+		unsigned int coffset;					     \
 		coffset = (unsigned int)((export)->exp_obd->obd_cntr_base) + \
-			OBD_COUNTER_OFFSET(op);			      \
+			OBD_COUNTER_OFFSET(op);				     \
 		LASSERT(coffset < (export)->exp_obd->obd_stats->ls_num);     \
 		lprocfs_counter_incr((export)->exp_obd->obd_stats, coffset); \
-	}								\
+	}								     \
 } while (0)
 
-#define MD_COUNTER_OFFSET(op)				   \
-	((offsetof(struct md_ops, op) -		   \
-	  offsetof(struct md_ops, getstatus))		 \
-	 / sizeof(((struct md_ops *)(0))->getstatus))
+#define MD_COUNTER_OFFSET(op)					\
+	((offsetof(struct md_ops, op) -				\
+		offsetof(struct md_ops, getstatus))		\
+		/ sizeof(((struct md_ops *)(0))->getstatus))
 
-#define MD_COUNTER_INCREMENT(obdx, op)			   \
-do {						   \
-	if ((obd)->md_stats) {			   \
-		unsigned int coffset;			    \
+#define MD_COUNTER_INCREMENT(obdx, op)				 \
+do {								 \
+	if ((obd)->md_stats) {					 \
+		unsigned int coffset;				 \
 		coffset = (unsigned int)((obdx)->md_cntr_base) + \
-			MD_COUNTER_OFFSET(op);		   \
-		LASSERT(coffset < (obdx)->md_stats->ls_num);     \
+			MD_COUNTER_OFFSET(op);			 \
+		LASSERT(coffset < (obdx)->md_stats->ls_num);	 \
 		lprocfs_counter_incr((obdx)->md_stats, coffset); \
 	}							 \
 } while (0)
 
-#define EXP_MD_COUNTER_INCREMENT(export, op)				 \
-do {								\
-	if ((export)->exp_obd->obd_stats) {				  \
-		unsigned int coffset;					\
-		coffset = (unsigned int)((export)->exp_obd->md_cntr_base) +  \
-			MD_COUNTER_OFFSET(op);			       \
-		LASSERT(coffset < (export)->exp_obd->md_stats->ls_num);      \
-		lprocfs_counter_incr((export)->exp_obd->md_stats, coffset);  \
-		if ((export)->exp_md_stats)				  \
-			lprocfs_counter_incr(				\
+#define EXP_MD_COUNTER_INCREMENT(export, op)				    \
+do {									    \
+	if ((export)->exp_obd->obd_stats) {				    \
+		unsigned int coffset;					    \
+		coffset = (unsigned int)((export)->exp_obd->md_cntr_base) + \
+			MD_COUNTER_OFFSET(op);				    \
+		LASSERT(coffset < (export)->exp_obd->md_stats->ls_num);	    \
+		lprocfs_counter_incr((export)->exp_obd->md_stats, coffset); \
+		if ((export)->exp_md_stats)				    \
+			lprocfs_counter_incr(				    \
 				(export)->exp_md_stats, coffset);	    \
-	}								\
+	}								    \
 } while (0)
 
 #define EXP_CHECK_MD_OP(exp, op)				\
-do {							    \
-	if (!(exp)) {				    \
-		CERROR("obd_" #op ": NULL export\n");	   \
-		return -ENODEV;				\
-	}						       \
-	if (!(exp)->exp_obd || !OBT((exp)->exp_obd)) {   \
+do {								\
+	if (!(exp)) {						\
+		CERROR("obd_" #op ": NULL export\n");		\
+		return -ENODEV;					\
+	}							\
+	if (!(exp)->exp_obd || !OBT((exp)->exp_obd)) {		\
 		CERROR("obd_" #op ": cleaned up obd\n");	\
-		return -EOPNOTSUPP;			    \
-	}						       \
-	if (!OBT((exp)->exp_obd) || !MDP((exp)->exp_obd, op)) { \
+		return -EOPNOTSUPP;				\
+	}							\
+	if (!OBT((exp)->exp_obd) || !MDP((exp)->exp_obd, op)) {	\
 		CERROR("obd_" #op ": dev %s/%d no operation\n", \
-		       (exp)->exp_obd->obd_name,		\
-		       (exp)->exp_obd->obd_minor);	      \
-		return -EOPNOTSUPP;			    \
-	}						       \
+			(exp)->exp_obd->obd_name,		\
+			(exp)->exp_obd->obd_minor);		\
+		return -EOPNOTSUPP;				\
+	}							\
 } while (0)
 
-#define OBD_CHECK_DT_OP(obd, op, err)			   \
-do {							    \
-	if (!OBT(obd) || !OBP((obd), op)) {		     \
-		if (err)					\
-			CERROR("obd_" #op ": dev %d no operation\n",    \
-			       obd->obd_minor);		 \
-		return err;				    \
-	}						       \
+#define OBD_CHECK_DT_OP(obd, op, err)					\
+do {									\
+	if (!OBT(obd) || !OBP((obd), op)) {				\
+		if (err)						\
+			CERROR("obd_" #op ": dev %d no operation\n",	\
+				obd->obd_minor);			\
+		return err;						\
+	}								\
 } while (0)
 
 #define EXP_CHECK_DT_OP(exp, op)				\
-do {							    \
-	if (!(exp)) {				    \
-		CERROR("obd_" #op ": NULL export\n");	   \
-		return -ENODEV;				\
-	}						       \
-	if (!(exp)->exp_obd || !OBT((exp)->exp_obd)) {   \
+do {								\
+	if (!(exp)) {						\
+		CERROR("obd_" #op ": NULL export\n");		\
+		return -ENODEV;					\
+	}							\
+	if (!(exp)->exp_obd || !OBT((exp)->exp_obd)) {		\
 		CERROR("obd_" #op ": cleaned up obd\n");	\
-		return -EOPNOTSUPP;			    \
-	}						       \
-	if (!OBT((exp)->exp_obd) || !OBP((exp)->exp_obd, op)) { \
-		CERROR("obd_" #op ": dev %d no operation\n",    \
-		       (exp)->exp_obd->obd_minor);	      \
-		return -EOPNOTSUPP;			    \
-	}						       \
+		return -EOPNOTSUPP;				\
+	}							\
+	if (!OBT((exp)->exp_obd) || !OBP((exp)->exp_obd, op)) {	\
+		CERROR("obd_" #op ": dev %d no operation\n",	\
+			(exp)->exp_obd->obd_minor);		\
+		return -EOPNOTSUPP;				\
+	}							\
 } while (0)
 
-#define CTXT_CHECK_OP(ctxt, op, err)				 \
-do {								 \
-	if (!OBT(ctxt->loc_obd) || !CTXTP((ctxt), op)) {	     \
-		if (err)					     \
-			CERROR("lop_" #op ": dev %d no operation\n", \
-			       ctxt->loc_obd->obd_minor);	    \
-		return err;					 \
-	}							    \
+#define CTXT_CHECK_OP(ctxt, op, err)					\
+do {									\
+	if (!OBT(ctxt->loc_obd) || !CTXTP((ctxt), op)) {		\
+		if (err)						\
+			CERROR("lop_" #op ": dev %d no operation\n",	\
+				ctxt->loc_obd->obd_minor);		\
+		return err;						\
+	}								\
 } while (0)
 
 static inline int class_devno_max(void)
-- 
2.7.4

[lustre-devel] (no subject)

[Ben Evans]

I've been working off and on with this.  Since you're getting into the
counters in a couple of the patches, part of the reason for all the
#defines here are because MDC, MDT and OST counters are all shoved into
the same array dynamically, sometimes.  It would be a much cleaner
approach to have a separate array for the MDC stats, then print them
conditionally.

This would reduce all of the calls to these macros to counter increments.

-Ben Evans

On 1/11/18, 12:16 PM, "Fabian Huegel" <fabian_huegel@web.de> wrote:

>We cleaned up a lot of checkpatch errors and warnings in obd_class.h,
>but there are still some CHECKs and two warnings about flow control
>inside macros left.
>
>Changing those macros to inline functions would probably
>be a good idea, unfortunatly it's not straightforward since they use
>'#op' to print the name of the operation.
>
>We also did some aligning to make the code more readable and removed
>an unnecessary macro.
>
>We only tested, that the kernel still compiles and the lustre kernel
>module loads successfully, but given the harmless nature of these
>changes we don't expect any problems.
>
>The patches are based on the staging-testing branch of the staging tree.
>

Re:

[Ben Evans]

I've been working off and on with this.  Since you're getting into the
counters in a couple of the patches, part of the reason for all the
#defines here are because MDC, MDT and OST counters are all shoved into
the same array dynamically, sometimes.  It would be a much cleaner
approach to have a separate array for the MDC stats, then print them
conditionally.

This would reduce all of the calls to these macros to counter increments.

-Ben Evans

On 1/11/18, 12:16 PM, "Fabian Huegel" <fabian_huegel@web.de> wrote:

>We cleaned up a lot of checkpatch errors and warnings in obd_class.h,
>but there are still some CHECKs and two warnings about flow control
>inside macros left.
>
>Changing those macros to inline functions would probably
>be a good idea, unfortunatly it's not straightforward since they use
>'#op' to print the name of the operation.
>
>We also did some aligning to make the code more readable and removed
>an unnecessary macro.
>
>We only tested, that the kernel still compiles and the lustre kernel
>module loads successfully, but given the harmless nature of these
>changes we don't expect any problems.
>
>The patches are based on the staging-testing branch of the staging tree.
>

[lustre-devel] [PATCH 1/8] staging: lustre: Enclose complex macros in parentheses

[Greg Kroah-Hartman]

On Thu, Jan 11, 2018 at 06:16:55PM +0100, Fabian Huegel wrote:
> Checkpatch wants complex macros to be enclosed in parentheses, so we
> put parentheses around these four macros.
> 
> Signed-off-by: Fabian Huegel <fabian_huegel@web.de>
> Signed-off-by: Christoph Volkert <linux@christoph-volkert.de>
> ---
>  drivers/staging/lustre/lustre/include/obd_class.h | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lustre/include/obd_class.h b/drivers/staging/lustre/lustre/include/obd_class.h
> index 67c535c..5c8cf30 100644
> --- a/drivers/staging/lustre/lustre/include/obd_class.h
> +++ b/drivers/staging/lustre/lustre/include/obd_class.h
> @@ -294,10 +294,10 @@ struct obdo;
>  
>  void obdo_to_ioobj(const struct obdo *oa, struct obd_ioobj *ioobj);
>  
> -#define OBT(dev)	(dev)->obd_type
> -#define OBP(dev, op)    (dev)->obd_type->typ_dt_ops->op
> -#define MDP(dev, op)    (dev)->obd_type->typ_md_ops->op
> -#define CTXTP(ctxt, op) (ctxt)->loc_logops->lop_##op
> +#define OBT(dev)	((dev)->obd_type)
> +#define OBP(dev, op)    ((dev)->obd_type->typ_dt_ops->op)
> +#define MDP(dev, op)    ((dev)->obd_type->typ_md_ops->op)
> +#define CTXTP(ctxt, op) ((ctxt)->loc_logops->lop_##op)

That really doesn't make any sense, as this can only be a variable in
here, not any "complex expression".  Sometimes checkpatch.pl isn't very
smart.

Also, these macros are horridly named, odds are they are not even
needed...

thanks,

greg k-h

Re: [PATCH 1/8] staging: lustre: Enclose complex macros in parentheses

[Greg Kroah-Hartman]

On Thu, Jan 11, 2018 at 06:16:55PM +0100, Fabian Huegel wrote:
> Checkpatch wants complex macros to be enclosed in parentheses, so we
> put parentheses around these four macros.
> 
> Signed-off-by: Fabian Huegel <fabian_huegel@web.de>
> Signed-off-by: Christoph Volkert <linux@christoph-volkert.de>
> ---
>  drivers/staging/lustre/lustre/include/obd_class.h | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lustre/include/obd_class.h b/drivers/staging/lustre/lustre/include/obd_class.h
> index 67c535c..5c8cf30 100644
> --- a/drivers/staging/lustre/lustre/include/obd_class.h
> +++ b/drivers/staging/lustre/lustre/include/obd_class.h
> @@ -294,10 +294,10 @@ struct obdo;
>  
>  void obdo_to_ioobj(const struct obdo *oa, struct obd_ioobj *ioobj);
>  
> -#define OBT(dev)	(dev)->obd_type
> -#define OBP(dev, op)    (dev)->obd_type->typ_dt_ops->op
> -#define MDP(dev, op)    (dev)->obd_type->typ_md_ops->op
> -#define CTXTP(ctxt, op) (ctxt)->loc_logops->lop_##op
> +#define OBT(dev)	((dev)->obd_type)
> +#define OBP(dev, op)    ((dev)->obd_type->typ_dt_ops->op)
> +#define MDP(dev, op)    ((dev)->obd_type->typ_md_ops->op)
> +#define CTXTP(ctxt, op) ((ctxt)->loc_logops->lop_##op)

That really doesn't make any sense, as this can only be a variable in
here, not any "complex expression".  Sometimes checkpatch.pl isn't very
smart.

Also, these macros are horridly named, odds are they are not even
needed...

thanks,

greg k-h

[lustre-devel] [PATCH 4/8] staging: lustre: Fix comment style

[Greg Kroah-Hartman]

On Thu, Jan 11, 2018 at 06:16:58PM +0100, Fabian Huegel wrote:
> Most multi-line comments started on the first line, but the preferred
> linux kernel style is to start multi-line comments on the second line.
> Some comments became less readable after the change, so we changed them
> to single-line comments.
> 
> Signed-off-by: Fabian Huegel <fabian_huegel@web.de>
> Signed-off-by: Christoph Volkert <linux@christoph-volkert.de>
> ---
>  drivers/staging/lustre/lustre/include/obd_class.h | 47 +++++++++++++----------
>  1 file changed, 27 insertions(+), 20 deletions(-)

This, and another patch, did not apply to my tree, probably because I
didn't take the first one.  Please rebase and resend the remaining ones.

thanks,

greg k-h

Re: [PATCH 4/8] staging: lustre: Fix comment style

[Greg Kroah-Hartman]

On Thu, Jan 11, 2018 at 06:16:58PM +0100, Fabian Huegel wrote:
> Most multi-line comments started on the first line, but the preferred
> linux kernel style is to start multi-line comments on the second line.
> Some comments became less readable after the change, so we changed them
> to single-line comments.
> 
> Signed-off-by: Fabian Huegel <fabian_huegel@web.de>
> Signed-off-by: Christoph Volkert <linux@christoph-volkert.de>
> ---
>  drivers/staging/lustre/lustre/include/obd_class.h | 47 +++++++++++++----------
>  1 file changed, 27 insertions(+), 20 deletions(-)

This, and another patch, did not apply to my tree, probably because I
didn't take the first one.  Please rebase and resend the remaining ones.

thanks,

greg k-h

staging: lustre: Cleanup of obd_class.h

[Fabian Huegel]

Here are the remaining patches rebased on the current staging-testing.

_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/2] staging: lustre: Fix comment style

[Fabian Huegel]

Most multi-line comments started on the first line, but the preferred
linux kernel style is to start multi-line comments on the second line.
Some comments became less readable after the change, so we changed them
to single-line comments.

Signed-off-by: Fabian Huegel <fabian_huegel@web.de>
Signed-off-by: Christoph Volkert <linux@christoph-volkert.de>
---
 drivers/staging/lustre/lustre/include/obd_class.h | 47 +++++++++++++----------
 1 file changed, 27 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/obd_class.h b/drivers/staging/lustre/lustre/include/obd_class.h
index 199b593..f517a05 100644
--- a/drivers/staging/lustre/lustre/include/obd_class.h
+++ b/drivers/staging/lustre/lustre/include/obd_class.h
@@ -40,15 +40,12 @@
 #include <lustre_lib.h>
 #include <lprocfs_status.h>
 
-#define OBD_STATFS_NODELAY      0x0001  /* requests should be send without delay
-					 * and resends for avoid deadlocks
-					 */
-#define OBD_STATFS_FROM_CACHE   0x0002  /* the statfs callback should not update
-					 * obd_osfs_age
-					 */
-#define OBD_STATFS_FOR_MDT0	0x0004	/* The statfs is only for retrieving
-					 * information from MDT0.
-					 */
+/* requests should be send without delay and resends for avoid deadlocks */
+#define OBD_STATFS_NODELAY      0x0001
+/* the statfs callback should not update obd_osfs_age */
+#define OBD_STATFS_FROM_CACHE   0x0002
+/* the statfs is only for retrieving information from MDT0 */
+#define OBD_STATFS_FOR_MDT0	0x0004
 
 /* OBD Device Declarations */
 extern struct obd_device *obd_devs[MAX_OBD_DEVICES];
@@ -137,7 +134,7 @@ int class_config_llog_handler(const struct lu_env *env,
 			      struct llog_rec_hdr *rec, void *data);
 int class_add_uuid(const char *uuid, __u64 nid);
 
-/*obdecho*/
+/* obdecho */
 void lprocfs_echo_init_vars(struct lprocfs_static_vars *lvars);
 
 #define CFG_F_START     0x01   /* Set when we start updating from a log */
@@ -182,7 +179,8 @@ struct config_llog_data {
 	struct obd_export	  *cld_mgcexp;
 	struct mutex		    cld_lock;
 	int			 cld_type;
-	unsigned int		cld_stopping:1, /* we were told to stop
+	unsigned int		cld_stopping:1, /*
+						 * we were told to stop
 						 * watching
 						 */
 				cld_lostlock:1; /* lock not requeued */
@@ -301,7 +299,8 @@ void obdo_to_ioobj(const struct obdo *oa, struct obd_ioobj *ioobj);
 #define MDP(dev, op)    (dev)->obd_type->typ_md_ops->op
 #define CTXTP(ctxt, op) (ctxt)->loc_logops->lop_##op
 
-/* Ensure obd_setup: used for cleanup which must be called
+/*
+ * Ensure obd_setup: used for cleanup which must be called
  * while obd is stopping
  */
 static inline int obd_check_dev(struct obd_device *obd)
@@ -588,7 +587,8 @@ static inline int obd_cleanup(struct obd_device *obd)
 
 static inline void obd_cleanup_client_import(struct obd_device *obd)
 {
-	/* If we set up but never connected, the
+	/*
+	 * If we set up but never connected, the
 	 * client import will not have been cleaned.
 	 */
 	down_write(&obd->u.cli.cl_sem);
@@ -727,7 +727,8 @@ static inline struct obd_uuid *obd_get_uuid(struct obd_export *exp)
 	return uuid;
 }
 
-/** Create a new /a exp on device /a obd for the uuid /a cluuid
+/*
+ * Create a new /a exp on device /a obd for the uuid /a cluuid
  * @param exp New export handle
  * @param d Connect data, supported flags are set, flags also understood
  *    by obd are returned.
@@ -739,7 +740,8 @@ static inline int obd_connect(const struct lu_env *env,
 			      void *localdata)
 {
 	int rc;
-	__u64 ocf = data ? data->ocd_connect_flags : 0; /* for post-condition
+	__u64 ocf = data ? data->ocd_connect_flags : 0; /*
+							 * for post-condition
 							 * check
 							 */
 
@@ -908,7 +910,8 @@ static inline int obd_destroy_export(struct obd_export *exp)
 	return 0;
 }
 
-/* @max_age is the oldest time in jiffies that we accept using a cached data.
+/*
+ * @max_age is the oldest time in jiffies that we accept using a cached data.
  * If the cache is older than @max_age we will get a new value from the
  * target.  Use a value of "cfs_time_current() + HZ" to guarantee freshness.
  */
@@ -969,7 +972,8 @@ static inline int obd_statfs_rqset(struct obd_export *exp,
 	return rc;
 }
 
-/* @max_age is the oldest time in jiffies that we accept using a cached data.
+/*
+ * @max_age is the oldest time in jiffies that we accept using a cached data.
  * If the cache is older than @max_age we will get a new value from the
  * target.  Use a value of "cfs_time_current() + HZ" to guarantee freshness.
  */
@@ -1133,7 +1137,8 @@ static inline int obd_quotactl(struct obd_export *exp,
 static inline int obd_health_check(const struct lu_env *env,
 				   struct obd_device *obd)
 {
-	/* returns: 0 on healthy
+	/*
+	 * returns: 0 on healthy
 	 *	 >0 on unhealthy + reason code/flag
 	 *	    however the only supported reason == 1 right now
 	 *	    We'll need to define some better reasons
@@ -1506,7 +1511,8 @@ static inline int md_get_fid_from_lsm(struct obd_export *exp,
 	return rc;
 }
 
-/* Unpack an MD struct from disk to in-memory format.
+/*
+ * Unpack an MD struct from disk to in-memory format.
  * Returns +ve size of unpacked MD (0 for free), or -ve error.
  *
  * If *plsm != NULL and lmm == NULL then *lsm will be freed.
@@ -1542,7 +1548,8 @@ struct lwp_register_item {
 	char		    lri_name[MTI_NAME_MAXLEN];
 };
 
-/* I'm as embarrassed about this as you are.
+/*
+ * I'm as embarrassed about this as you are.
  *
  * <shaver> // XXX do not look into _superhack with remaining eye
  * <shaver> // XXX if this were any uglier, I'd get my own show on MTV
-- 
2.7.4

_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/2] staging: lustre: Align struct member identifiers

[Fabian Huegel]

This patch properly left aligns all member identifiers in every
struct defined in obd_class.h for better readability.

Signed-off-by: Fabian Huegel <fabian_huegel@web.de>
Signed-off-by: Christoph Volkert <linux@christoph-volkert.de>
---
 drivers/staging/lustre/lustre/include/obd_class.h | 44 +++++++++++------------
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/obd_class.h b/drivers/staging/lustre/lustre/include/obd_class.h
index f517a05..531e8dd 100644
--- a/drivers/staging/lustre/lustre/include/obd_class.h
+++ b/drivers/staging/lustre/lustre/include/obd_class.h
@@ -145,13 +145,13 @@ void lprocfs_echo_init_vars(struct lprocfs_static_vars *lvars);
 
 /* Passed as data param to class_config_parse_llog */
 struct config_llog_instance {
-	char	       *cfg_obdname;
-	void	       *cfg_instance;
+	char		   *cfg_obdname;
+	void		   *cfg_instance;
 	struct super_block *cfg_sb;
 	struct obd_uuid     cfg_uuid;
 	llog_cb_t	    cfg_callback;
-	int		 cfg_last_idx; /* for partial llog processing */
-	int		 cfg_flags;
+	int		    cfg_last_idx; /* for partial llog processing */
+	int		    cfg_flags;
 };
 
 int class_config_parse_llog(const struct lu_env *env, struct llog_ctxt *ctxt,
@@ -169,31 +169,31 @@ enum {
 
 /* list of active configuration logs  */
 struct config_llog_data {
-	struct ldlm_res_id	  cld_resid;
+	struct ldlm_res_id	    cld_resid;
 	struct config_llog_instance cld_cfg;
-	struct list_head		  cld_list_chain;
-	atomic_t		cld_refcount;
+	struct list_head	    cld_list_chain;
+	atomic_t		    cld_refcount;
 	struct config_llog_data    *cld_sptlrpc;/* depended sptlrpc log */
 	struct config_llog_data	   *cld_params;	/* common parameters log */
 	struct config_llog_data    *cld_recover;/* imperative recover log */
-	struct obd_export	  *cld_mgcexp;
+	struct obd_export	   *cld_mgcexp;
 	struct mutex		    cld_lock;
-	int			 cld_type;
-	unsigned int		cld_stopping:1, /*
-						 * we were told to stop
-						 * watching
-						 */
-				cld_lostlock:1; /* lock not requeued */
-	char			cld_logname[0];
+	int			    cld_type;
+	unsigned int		    cld_stopping:1, /*
+						     * we were told to stop
+						     * watching
+						     */
+				    cld_lostlock:1; /* lock not requeued */
+	char			    cld_logname[0];
 };
 
 struct lustre_profile {
-	struct list_head       lp_list;
-	char	    *lp_profile;
-	char	    *lp_dt;
-	char	    *lp_md;
-	int			lp_refs;
-	bool			lp_list_deleted;
+	struct list_head lp_list;
+	char		*lp_profile;
+	char		*lp_dt;
+	char		*lp_md;
+	int		 lp_refs;
+	bool		 lp_list_deleted;
 };
 
 struct lustre_profile *class_get_profile(const char *prof);
@@ -1544,7 +1544,7 @@ struct lwp_register_item {
 	struct obd_export **lri_exp;
 	register_lwp_cb	    lri_cb_func;
 	void		   *lri_cb_data;
-	struct list_head	    lri_list;
+	struct list_head    lri_list;
 	char		    lri_name[MTI_NAME_MAXLEN];
 };
 
-- 
2.7.4

_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[lustre-devel] [PATCH 6/8] staging: lustre: Fix overlong lines

[Dilger, Andreas]

On Jan 11, 2018, at 10:17, Fabian Huegel <fabian_huegel@web.de> wrote:
> 
> Fixed four lines that went over the 80 character limit
> to reduce checkpatch warnings.
> 
> Signed-off-by: Fabian Huegel <fabian_huegel@web.de>
> Signed-off-by: Christoph Volkert <linux@christoph-volkert.de>
> ---
> drivers/staging/lustre/lustre/include/obd_class.h | 14 ++++++++++----
> 1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lustre/include/obd_class.h b/drivers/staging/lustre/lustre/include/obd_class.h
> index d195866..06f825b 100644
> --- a/drivers/staging/lustre/lustre/include/obd_class.h
> +++ b/drivers/staging/lustre/lustre/include/obd_class.h
> @@ -850,7 +850,9 @@ static inline int obd_pool_del(struct obd_device *obd, char *poolname)
> 	return rc;
> }
> 
> -static inline int obd_pool_add(struct obd_device *obd, char *poolname, char *ostname)
> +static inline int obd_pool_add(struct obd_device *obd,
> +			       char *poolname,
> +			       char *ostname)

This only needs a single field moved onto the next line, like:

+static inline int obd_pool_add(struct obd_device *obd, char *poolname,
+			       char *ostname)


> @@ -861,7 +863,9 @@ static inline int obd_pool_add(struct obd_device *obd, char *poolname, char *ost
> 	return rc;
> }
> 
> -static inline int obd_pool_rem(struct obd_device *obd, char *poolname, char *ostname)
> +static inline int obd_pool_rem(struct obd_device *obd,
> +			       char *poolname,
> +			       char *ostname)

Same.

> @@ -997,7 +1001,8 @@ static inline int obd_statfs(const struct lu_env *env, struct obd_export *exp,
> 			spin_unlock(&obd->obd_osfs_lock);
> 		}
> 	} else {
> -		CDEBUG(D_SUPER, "%s: use %p cache blocks %llu/%llu objects %llu/%llu\n",
> +		CDEBUG(D_SUPER,
> +		       "%s: use %p cache blocks %llu/%llu objects %llu/%llu\n",
> 		       obd->obd_name, &obd->obd_osfs,
> 		       obd->obd_osfs.os_bavail, obd->obd_osfs.os_blocks,
> 		       obd->obd_osfs.os_ffree, obd->obd_osfs.os_files);
> @@ -1579,7 +1584,8 @@ int class_procfs_init(void);
> int class_procfs_clean(void);
> 
> /* prng.c */
> -#define ll_generate_random_uuid(uuid_out) get_random_bytes(uuid_out, sizeof(class_uuid_t))
> +#define ll_generate_random_uuid(uuid_out) \
> +	get_random_bytes(uuid_out, sizeof(class_uuid_t))

This looks like it would be better to replace ll_generate_random_uuid()
callers with generate_random_uuid().

Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Intel Corporation

Re: [PATCH 6/8] staging: lustre: Fix overlong lines

[Dilger, Andreas]

On Jan 11, 2018, at 10:17, Fabian Huegel <fabian_huegel@web.de> wrote:
> 
> Fixed four lines that went over the 80 character limit
> to reduce checkpatch warnings.
> 
> Signed-off-by: Fabian Huegel <fabian_huegel@web.de>
> Signed-off-by: Christoph Volkert <linux@christoph-volkert.de>
> ---
> drivers/staging/lustre/lustre/include/obd_class.h | 14 ++++++++++----
> 1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lustre/include/obd_class.h b/drivers/staging/lustre/lustre/include/obd_class.h
> index d195866..06f825b 100644
> --- a/drivers/staging/lustre/lustre/include/obd_class.h
> +++ b/drivers/staging/lustre/lustre/include/obd_class.h
> @@ -850,7 +850,9 @@ static inline int obd_pool_del(struct obd_device *obd, char *poolname)
> 	return rc;
> }
> 
> -static inline int obd_pool_add(struct obd_device *obd, char *poolname, char *ostname)
> +static inline int obd_pool_add(struct obd_device *obd,
> +			       char *poolname,
> +			       char *ostname)

This only needs a single field moved onto the next line, like:

+static inline int obd_pool_add(struct obd_device *obd, char *poolname,
+			       char *ostname)


> @@ -861,7 +863,9 @@ static inline int obd_pool_add(struct obd_device *obd, char *poolname, char *ost
> 	return rc;
> }
> 
> -static inline int obd_pool_rem(struct obd_device *obd, char *poolname, char *ostname)
> +static inline int obd_pool_rem(struct obd_device *obd,
> +			       char *poolname,
> +			       char *ostname)

Same.

> @@ -997,7 +1001,8 @@ static inline int obd_statfs(const struct lu_env *env, struct obd_export *exp,
> 			spin_unlock(&obd->obd_osfs_lock);
> 		}
> 	} else {
> -		CDEBUG(D_SUPER, "%s: use %p cache blocks %llu/%llu objects %llu/%llu\n",
> +		CDEBUG(D_SUPER,
> +		       "%s: use %p cache blocks %llu/%llu objects %llu/%llu\n",
> 		       obd->obd_name, &obd->obd_osfs,
> 		       obd->obd_osfs.os_bavail, obd->obd_osfs.os_blocks,
> 		       obd->obd_osfs.os_ffree, obd->obd_osfs.os_files);
> @@ -1579,7 +1584,8 @@ int class_procfs_init(void);
> int class_procfs_clean(void);
> 
> /* prng.c */
> -#define ll_generate_random_uuid(uuid_out) get_random_bytes(uuid_out, sizeof(class_uuid_t))
> +#define ll_generate_random_uuid(uuid_out) \
> +	get_random_bytes(uuid_out, sizeof(class_uuid_t))

This looks like it would be better to replace ll_generate_random_uuid()
callers with generate_random_uuid().

Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Intel Corporation

[lustre-devel] [PATCH 1/2] staging: lustre: Fix comment style

[Joe Perches]

On Thu, 2018-01-18 at 16:51 +0100, Fabian Huegel wrote:
> Most multi-line comments started on the first line, but the preferred
> linux kernel style is to start multi-line comments on the second line.
> Some comments became less readable after the change, so we changed them
> to single-line comments.
[]
> diff --git a/drivers/staging/lustre/lustre/include/obd_class.h b/drivers/staging/lustre/lustre/include/obd_class.h
> 
> @@ -182,7 +179,8 @@ struct config_llog_data {
>  	struct obd_export	  *cld_mgcexp;
>  	struct mutex		    cld_lock;
>  	int			 cld_type;
> -	unsigned int		cld_stopping:1, /* we were told to stop
> +	unsigned int		cld_stopping:1, /*
> +						 * we were told to stop
>  						 * watching
>  						 */
>  				cld_lostlock:1; /* lock not requeued */

probably better for both of these to be bool
instead of bitfield.

Re: [PATCH 1/2] staging: lustre: Fix comment style

[Joe Perches]

On Thu, 2018-01-18 at 16:51 +0100, Fabian Huegel wrote:
> Most multi-line comments started on the first line, but the preferred
> linux kernel style is to start multi-line comments on the second line.
> Some comments became less readable after the change, so we changed them
> to single-line comments.
[]
> diff --git a/drivers/staging/lustre/lustre/include/obd_class.h b/drivers/staging/lustre/lustre/include/obd_class.h
> 
> @@ -182,7 +179,8 @@ struct config_llog_data {
>  	struct obd_export	  *cld_mgcexp;
>  	struct mutex		    cld_lock;
>  	int			 cld_type;
> -	unsigned int		cld_stopping:1, /* we were told to stop
> +	unsigned int		cld_stopping:1, /*
> +						 * we were told to stop
>  						 * watching
>  						 */
>  				cld_lostlock:1; /* lock not requeued */

probably better for both of these to be bool
instead of bitfield.

_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[lustre-devel] [PATCH 1/2] staging: lustre: Fix comment style

[Greg Kroah-Hartman]

On Fri, Jan 19, 2018 at 05:53:59PM -0800, Joe Perches wrote:
> On Thu, 2018-01-18 at 16:51 +0100, Fabian Huegel wrote:
> > Most multi-line comments started on the first line, but the preferred
> > linux kernel style is to start multi-line comments on the second line.
> > Some comments became less readable after the change, so we changed them
> > to single-line comments.
> []
> > diff --git a/drivers/staging/lustre/lustre/include/obd_class.h b/drivers/staging/lustre/lustre/include/obd_class.h
> > 
> > @@ -182,7 +179,8 @@ struct config_llog_data {
> >  	struct obd_export	  *cld_mgcexp;
> >  	struct mutex		    cld_lock;
> >  	int			 cld_type;
> > -	unsigned int		cld_stopping:1, /* we were told to stop
> > +	unsigned int		cld_stopping:1, /*
> > +						 * we were told to stop
> >  						 * watching
> >  						 */
> >  				cld_lostlock:1; /* lock not requeued */
> 
> probably better for both of these to be bool
> instead of bitfield.

That's a change best left for a separate patch :)

thanks,

greg k-h

Re: [PATCH 1/2] staging: lustre: Fix comment style

[Greg Kroah-Hartman]

On Fri, Jan 19, 2018 at 05:53:59PM -0800, Joe Perches wrote:
> On Thu, 2018-01-18 at 16:51 +0100, Fabian Huegel wrote:
> > Most multi-line comments started on the first line, but the preferred
> > linux kernel style is to start multi-line comments on the second line.
> > Some comments became less readable after the change, so we changed them
> > to single-line comments.
> []
> > diff --git a/drivers/staging/lustre/lustre/include/obd_class.h b/drivers/staging/lustre/lustre/include/obd_class.h
> > 
> > @@ -182,7 +179,8 @@ struct config_llog_data {
> >  	struct obd_export	  *cld_mgcexp;
> >  	struct mutex		    cld_lock;
> >  	int			 cld_type;
> > -	unsigned int		cld_stopping:1, /* we were told to stop
> > +	unsigned int		cld_stopping:1, /*
> > +						 * we were told to stop
> >  						 * watching
> >  						 */
> >  				cld_lostlock:1; /* lock not requeued */
> 
> probably better for both of these to be bool
> instead of bitfield.

That's a change best left for a separate patch :)

thanks,

greg k-h
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel