From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Layton Subject: Re: [PATCH 3/7] cifs: don't declare smb_vol info on the stack Date: Sun, 30 Nov 2008 17:28:05 -0500 Message-ID: <20081130172805.3eaf6cde@tupile.poochiereds.net> References: <1228070436-6063-1-git-send-email-jlayton@redhat.com> <1228070436-6063-4-git-send-email-jlayton@redhat.com> <524f69650811301249l11bb05aev2cd3d40aba3c795c@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: smfrench@austin.rr.com, linux-cifs-client@lists.samba.org, linux-fsdevel To: "Steve French" Return-path: Received: from mx2.redhat.com ([66.187.237.31]:40160 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753070AbYK3W3A (ORCPT ); Sun, 30 Nov 2008 17:29:00 -0500 In-Reply-To: <524f69650811301249l11bb05aev2cd3d40aba3c795c@mail.gmail.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sun, 30 Nov 2008 14:49:04 -0600 "Steve French" wrote: > I have thought about this a few times, but always hesitated because I > was hoping that eventually cifs mount option parsing could use new > parsing functions (which would also shrink the "parse_mount_options" > routine which we call during cifs mount), and would cause us to > rewrite this. IIRC nfs was changed a few years ago to use the new > mount mechanism (match_table and tokens). > I think we'll still have a smb_vol struct or something like it, regardless of how we end up doing the parsing. The results of the parsing have to be recorded somewhere. There's a similar struct for NFS as well (nfs_parsed_mount_data). We definitely should switch to the standard parser, but I don't think this patch will make much difference in how that is implemented. -- Jeff Layton