default readv/writev functions

default readv/writev functions

[Simon Evans]

Hi,

I noticed in fs/jffs2/writev.c there is a mtd_fake_writev and a comment
that it should be in the MTD core. Is the following ok to commit?

cheers
si

Index: drivers/mtd/mtdcore.c
===================================================================
RCS file: /home/cvs/mtd/drivers/mtd/mtdcore.c,v
retrieving revision 1.32
diff -u -p -u -r1.32 mtdcore.c
--- drivers/mtd/mtdcore.c	7 Mar 2002 18:38:10 -0000	1.32
+++ drivers/mtd/mtdcore.c	11 Jan 2003 12:28:16 -0000
@@ -203,11 +203,74 @@ struct mtd_info *__get_mtd_device(struct
 	return ret;
 }
 
+
+/* default_mtd_writev - default mtd writev method for MTD devices that
+ *			dont implement their own
+ */
+
+int default_mtd_writev(struct mtd_info *mtd, const struct iovec *vecs,
+		       unsigned long count, loff_t to, size_t *retlen)
+{
+	unsigned long i;
+	size_t totlen = 0, thislen;
+	int ret = 0;
+
+	if(!mtd->write) {
+		ret = -EROFS;
+	} else {
+		for (i=0; i<count; i++) {
+			if (!vecs[i].iov_len)
+				continue;
+			ret = mtd->write(mtd, to, vecs[i].iov_len, &thislen, vecs[i].iov_base);
+			totlen += thislen;
+			if (ret || thislen != vecs[i].iov_len)
+				break;
+			to += vecs[i].iov_len;
+		}
+	}
+	if (retlen)
+		*retlen = totlen;
+	return ret;
+}
+
+
+/* default_mtd_readv - default mtd readv method for MTD devices that dont
+ *		       implement their own
+ */
+
+int default_mtd_readv(struct mtd_info *mtd, struct iovec *vecs,
+		      unsigned long count, loff_t from, size_t *retlen)
+{
+	unsigned long i;
+	size_t totlen = 0, thislen;
+	int ret = 0;
+
+	if(!mtd->read) {
+		ret = -EIO;
+	} else {
+		for (i=0; i<count; i++) {
+			if (!vecs[i].iov_len)
+				continue;
+			ret = mtd->read(mtd, from, vecs[i].iov_len, &thislen, vecs[i].iov_base);
+			totlen += thislen;
+			if (ret || thislen != vecs[i].iov_len)
+				break;
+			from += vecs[i].iov_len;
+		}
+	}
+	if (retlen)
+		*retlen = totlen;
+	return ret;
+}
+
+
 EXPORT_SYMBOL(add_mtd_device);
 EXPORT_SYMBOL(del_mtd_device);
 EXPORT_SYMBOL(__get_mtd_device);
 EXPORT_SYMBOL(register_mtd_user);
 EXPORT_SYMBOL(unregister_mtd_user);
+EXPORT_SYMBOL(default_mtd_writev);
+EXPORT_SYMBOL(default_mtd_readv);
 
 /*====================================================================*/
 /* Power management code */
Index: include/linux/mtd/mtd.h
===================================================================
RCS file: /home/cvs/mtd/include/linux/mtd/mtd.h,v
retrieving revision 1.37
diff -u -p -u -r1.37 mtd.h
--- include/linux/mtd/mtd.h	19 Nov 2002 01:22:31 -0000	1.37
+++ include/linux/mtd/mtd.h	11 Jan 2003 12:28:17 -0000
@@ -257,6 +257,11 @@ struct mtd_notifier {
 extern void register_mtd_user (struct mtd_notifier *new);
 extern int unregister_mtd_user (struct mtd_notifier *old);
 
+int default_mtd_writev(struct mtd_info *mtd, const struct iovec *vecs,
+		       unsigned long count, loff_t to, size_t *retlen);
+
+int default_mtd_readv(struct mtd_info *mtd, struct iovec *vecs,
+		      unsigned long count, loff_t from, size_t *retlen);
 
 #ifndef MTDC
 #define MTD_ERASE(mtd, args...) (*(mtd->erase))(mtd, args)

Re: default readv/writev functions

[Jörn Engel]

On Sat, 11 January 2003 15:35:26 +0000, Simon Evans wrote:
> 
> I noticed in fs/jffs2/writev.c there is a mtd_fake_writev and a comment
> that it should be in the MTD core. Is the following ok to commit?
> 
> diff -u -p -u -r1.32 mtdcore.c
> --- drivers/mtd/mtdcore.c	7 Mar 2002 18:38:10 -0000	1.32
> +++ drivers/mtd/mtdcore.c	11 Jan 2003 12:28:16 -0000
>
> +int default_mtd_writev(struct mtd_info *mtd, const struct iovec *vecs,
> +		       unsigned long count, loff_t to, size_t *retlen)
> +int default_mtd_readv(struct mtd_info *mtd, struct iovec *vecs,
> +		      unsigned long count, loff_t from, size_t *retlen)
>
> +EXPORT_SYMBOL(default_mtd_writev);
> +EXPORT_SYMBOL(default_mtd_readv);
>
> diff -u -p -u -r1.37 mtd.h
> --- include/linux/mtd/mtd.h	19 Nov 2002 01:22:31 -0000	1.37
> +++ include/linux/mtd/mtd.h	11 Jan 2003 12:28:17 -0000
>
> +int default_mtd_writev(struct mtd_info *mtd, const struct iovec *vecs,
> +		       unsigned long count, loff_t to, size_t *retlen);
> +
> +int default_mtd_readv(struct mtd_info *mtd, struct iovec *vecs,
> +		      unsigned long count, loff_t from, size_t *retlen);

IMHO this is the wrong place. This should go into
drivers/mtd/chips/cfi_cmdset*.c.

Maybe I should comment on the code as well, but I'm lazy tonight. You
can compare it with cfi_cmdset_0003.c, that one should have a working
writev-function.

Jörn

-- 
Jörn Engel
mailto: joern@wohnheim.fh-wedel.de
http://wohnheim.fh-wedel.de/~joern
Phone: +49 179 6704074

Re: default readv/writev functions

[David Woodhouse]

joern@wohnheim.fh-wedel.de said:
>  IMHO this is the wrong place. This should go into drivers/mtd/chips/
> cfi_cmdset*.c.

I disagree. All chips -- or at least all NOR chips -- are going to want to
use the same implmementation it because there's almost no point in actually
having their own.

Maybe having it in chips/chipreg.c makes almost as much sense, but there 
are standalone devices like the LART driver which would want it.

--
dwmw2

Re: default readv/writev functions

[Jörn Engel]

On Tue, 14 January 2003 23:18:33 +0000, David Woodhouse wrote:
> 
> joern@wohnheim.fh-wedel.de said:
> >  IMHO this is the wrong place. This should go into drivers/mtd/chips/
> > cfi_cmdset*.c.
> 
> I disagree. All chips -- or at least all NOR chips -- are going to want to
> use the same implmementation it because there's almost no point in actually
> having their own.

How about the STMicro flashes with built-in ecc checks? Write less
than 8 bytes per vector element and you're dead.
Other than that, you are right. A central version is better for almost
all chips.

> Maybe having it in chips/chipreg.c makes almost as much sense, but there 
> are standalone devices like the LART driver which would want it.

Makes sense.

Jörn

-- 
But this is not to say that the main benefit of Linux and other GPL
software is lower-cost. Control is the main benefit--cost is secondary.
-- Bruce Perens

Re: default readv/writev functions

[David Woodhouse]

joern@wohnheim.fh-wedel.de said:
>  How about the STMicro flashes with built-in ecc checks? Write less
> than 8 bytes per vector element and you're dead. Other than that, you
> are right. A central version is better for almost all chips.

The intention is that drivers can set their own readv/writev methods to 
point at these default functions, _if_ they want to. Chips which can't use 
these functions can still provide their own.

Think of it like generic_file_read etc. for file systems. You use them if 
you don't have special requirements -- otherwise you write your own.

--
dwmw2