So it is! But dont know why is there such a huge difference between a
pair of read and write. I mean if read could hide the space difference
(by internally using copy_to_user) then why not the same with write?
That would've kept the interfaces simple and uniform.
Guess anyway procfs is dying a slow death (replaced by sysfs)
Thanks Matthias.
On Fri, 2009-02-27 at 15:54 +0100, Matthias Kaehlcke wrote:
> El Fri, Feb 27, 2009 at 07:38:59PM +0530 Sabin ha dit:
> > I saw the following code:
> > static int uart_read_proc(char *page, char **start, off_t off,
> > int count, int *eof, void *data)
> > {
> > struct tty_driver *ttydrv = data;
> > struct uart_driver *drv = ttydrv->driver_state;
> > int i, len = 0, l;
> > off_t begin = 0;
> >
> > len += sprintf(page, "serinfo:1.0 driver%s%s revision:%s\n",
> > "", "", "");
> >
> > I dont understand why sprintf is used and not copy_to_user?
> > When we write a module/driver we treat both read and write buffer as
> > coming from userspace and hence use put_user/get_user or
> > copy_from_user/copy_to_user.
> > Anybody has any idea why proc read is handled differently?
>
> good observation!
>
> the read_proc function of an proc entry is called from
> proc_file_read(), which passes it a non-userspace
> buffer. proc_file_read() is in charge of copying the data from this
> buffer to the buffer provided by userspace:
>
> http://lxr.linux.no/linux+v2.6.28/fs/proc/generic.c#L41
>
>
> write_proc on the other receives a user space buffer from
> proc_file_write() and is therefore required to use copy_from_user() or
> get_user():
>
> http://lxr.linux.no/linux+v2.6.28/fs/proc/generic.c#L187
>
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to [email protected]
Please read the FAQ at http://kernelnewbies.org/FAQ
