From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760444AbYDCEgb (ORCPT ); Thu, 3 Apr 2008 00:36:31 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751625AbYDCEgX (ORCPT ); Thu, 3 Apr 2008 00:36:23 -0400 Received: from smtp-out.google.com ([216.239.33.17]:28948 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751604AbYDCEgW (ORCPT ); Thu, 3 Apr 2008 00:36:22 -0400 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:content-transfer-encoding: content-disposition:references; b=mnuYpZTMx7v1LH9IdTt4RACoMcJXqID7vBzSpgjmW0KkvHh7+I9Zz2Fl4N/fDlwon yFxaYMKoIaLlbbvvQY3SQ== Message-ID: <6599ad830804022136o24be5797s20843e18c91aeaf0@mail.gmail.com> Date: Wed, 2 Apr 2008 21:36:13 -0700 From: "Paul Menage" To: "Serge E. Hallyn" Subject: Re: [PATCH 1/1] cgroups: introduce cft->read_seq() Cc: lkml In-Reply-To: <20080403010130.GA20543@sergelap.austin.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080403010130.GA20543@sergelap.austin.ibm.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 2, 2008 at 6:01 PM, Serge E. Hallyn wrote: > + /* > + * read_seq() is used for outputting a simple sequence > + * using seqfile. > + */ > + int (*read_seq) (struct cgroup *cont, struct cftype *cft, > + struct seq_file *m); Maybe make it read_seq_string() to emphasise that it's not intended for structured data? > > -static int cgroup_seqfile_show(struct seq_file *m, void *arg) > +static int cgroup_map_seqfile_show(struct seq_file *m, void *arg) > { > struct cgroup_seqfile_state *state = m->private; > struct cftype *cft = state->cft; > @@ -1529,6 +1529,13 @@ static int cgroup_seqfile_show(struct seq_file *m, void *arg) > return cft->read_map(state->cgroup, cft, &cb); > } I think you can make this simpler - have cgroup_seqfile_show() switch based on whether the cft has a read_seq_string or a read_map, and then you only need one function. > > +static int cgroup_simple_seqfile_show(struct seq_file *m, void *arg) > +{ > + struct cgroup_seqfile_state *state = m->private; > + struct cftype *cft = state->cft; > + return cft->read_seq(state->cgroup, cft, m); > +} > + > int cgroup_seqfile_release(struct inode *inode, struct file *file) > { > struct seq_file *seq = file->private_data; > @@ -1562,7 +1569,18 @@ static int cgroup_file_open(struct inode *inode, struct file *file) > state->cft = cft; > state->cgroup = __d_cgrp(file->f_dentry->d_parent); > file->f_op = &cgroup_seqfile_operations; > - err = single_open(file, cgroup_seqfile_show, state); > + err = single_open(file, cgroup_map_seqfile_show, state); > + if (err < 0) > + kfree(state); > + } else if (cft->read_seq) { > + struct cgroup_seqfile_state *state = > + kzalloc(sizeof(*state), GFP_USER); > + if (!state) > + return -ENOMEM; > + state->cft = cft; > + state->cgroup = __d_cgrp(file->f_dentry->d_parent); > + file->f_op = &cgroup_seqfile_operations; > + err = single_open(file, cgroup_simple_seqfile_show, state); > if (err < 0) > kfree(state); and this arm can just be eliminated, by adding "|| cft->read_seq_string" to the test for cft_read_seq_map above. It was always my intention that cgroup_seqfile_show() be able to handle multiple data types, but up until now we only had one. Paul