[linux-cifs-client] [PATCH 1/2] connect.c: define mount options enum and parsing function

Scott Lovenberg scott.lovenberg at gmail.com
Thu May 20 05:52:39 MDT 2010


>
>
>> There's really no need to assign every value on an enum. You should
>> also probably prefix these with the semi-standard "Opt_" so that they
>> aren't confused with other values. This should also be static, I think.
>>
>> Agreed on Opt prefix.  I only used the enum as it was the preferred way to
> define related constants in the kernel coding style; TBH, I'd rather just
> use #define'd constants.  If it's all the same, that's what I'll do.  It
> means I won't have to fight with keeping the alignment in vim the same as
> what gets emailed (those values were all aligned in the file and the patch
> file). :)
>

Sorry, I just realized what you were saying about assigning in the enum.
 Disregard the comment above (this is why I should have a cup of coffee
before replying to email, not during).
Unfortunately GCC throws warnings if I make the enums static.


For an example of how it's used, you can look at the NFS code, starting
>> with nfs_parse_mount_options.
>>
>> Aha!
>
> It would be best to move to that code if possible
>>
> Agreed.
>


>
>
After looking at the NFS code, I scrapped what I had and rewrote to follow
the style/semantics of the NFS option parsing.  I think this patch will be
more in line with what you had in mind.
I left the value parsing as it was and used the match_token to get the
current token.  I'll follow up with another patch if you'd like me to
implement grabbing the value with the parser lib instead of what we've got
currently.

-- 
Peace and Blessings,
-Scott.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/linux-cifs-client/attachments/20100520/a78b4a11/attachment.html>


More information about the linux-cifs-client mailing list