Messages in this thread | | | Date | Sat, 28 Nov 2009 13:26:26 +0100 | From | Tilman Schmidt <> | Subject | Re: [PATCH] proc_fops: convert drivers/isdn/ to seq_file |
| |
Am 23.11.2009 02:56 schrieb Alexey Dobriyan: > --- a/Documentation/isdn/INTERFACE.CAPI > +++ b/Documentation/isdn/INTERFACE.CAPI > @@ -149,8 +149,8 @@ char *(*procinfo)(struct capi_ctr *ctrlr) > pointer to a callback function returning the entry for the device in > the CAPI controller info table, /proc/capi/controller > > -read_proc_t *ctr_read_proc > - pointer to the read_proc callback function for the device's proc file > +const struct file_operations *proc_fops > + pointers to callback functions for the device's proc file > system entry, /proc/capi/controllers/<n>; will be called with a > pointer to the device's capi_ctr structure as the last (data) argument >
This doesn't look correct. AFACIS, most of the callback functions in proc_fops don't have a last argument named data or looking as if it might lend itself to passing a pointer to the device's capi_ctr structure. In fact, later in your patch you replace uses of that last argument by accesses to the m->private member of the struct seq_file *m argument, like here:
> --- a/drivers/isdn/hardware/avm/b1.c > +++ b/drivers/isdn/hardware/avm/b1.c [...] > @@ -634,18 +636,17 @@ irqreturn_t b1_interrupt(int interrupt, void *devptr) > } > > /* ------------------------------------------------------------- */ > -int b1ctl_read_proc(char *page, char **start, off_t off, > - int count, int *eof, struct capi_ctr *ctrl) > +static int b1ctl_proc_show(struct seq_file *m, void *v) > { > + struct capi_ctr *ctrl = m->private; > avmctrl_info *cinfo = (avmctrl_info *)(ctrl->driverdata); > avmcard *card = cinfo->card; > u8 flag; [...]
So I guess the paragraph Documentation/isdn/INTERFACE.CAPI needs to be adapted to describe correctly where the callbacks will find their controller data structure after that change.
OTOH, the new proc_show functions sport a second argument void *v that doesn't appear to get used anywhere. It would be nice if that could be explained a bit somewhere.
Thanks, Tilman
-- Tilman Schmidt E-Mail: tilman@imap.cc Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
[unhandled content-type:application/pgp-signature] | |