Messages in this thread | | | From | Duncan Sands <> | Subject | Re: [PATCH 3/3] cxacru: Store all device status information and report it when atm_proc_read is called. | Date | Thu, 1 Feb 2007 10:15:31 +0100 |
| |
On Thursday 1 February 2007 00:39:14 you wrote: > On Tue, 30 Jan 2007 21:30:29 +0000 > Simon Arlott <simon@arlott.org> wrote: > > > +static int cxacru_proc_read(struct usbatm_data *usbatm_instance, > > + struct atm_dev *atm_dev, loff_t * pos, char *page) > > +{ > > + struct cxacru_data *instance = usbatm_instance->driver_data; > > + u32 *cxinf = instance->cxinf_status; > > + int left = *pos; > > + > > + if (!left--) > > + return sprintf(page, "# %s\n", usbatm_instance->description); > > + > > + if (!left--) { > > + if (cxinf[CXINF_LINE_STATUS] == 5) { > > + return sprintf(page, "# UP %u/%u\n", > > + cxinf[CXINF_DOWNSTREAM_RATE], > > + cxinf[CXINF_UPSTREAM_RATE]); > > + } else { > > + return sprintf(page, "# DOWN\n"); > > + } > > + } > > hm, how well-tested was this proc interface? The pread() and lseek() > behaviour might be strange. > > I guess as long as it doesn't oops, hang or anything like that then it'll > be OK. Anyone who does anything apart from a single big-fat-read from a > procfile has a good chance of getting into trouble :(
All the ATM drivers seem to do it like this. That doesn't mean they are right of course! But I never saw anyone complain on the ATM mailing list. On the other hand, why does Simon want this? If he has written a user space tool that extracts bits from the proc file (eg: to tell users what's going on) then he could run into trouble, depending on how he implements it.
Ciao,
Duncan. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |