From: Alexander Aring <alex.aring@gmail.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: [RFC 1/3] ramfs: add foofs for testing
Date: Mon, 3 Mar 2014 10:08:21 +0100 [thread overview]
Message-ID: <20140303090820.GB24214@x61s.Speedport_W_921V_1_24_000> (raw)
In-Reply-To: <20140303083620.GN17250@pengutronix.de>
Hi Sascha,
On Mon, Mar 03, 2014 at 09:36:20AM +0100, Sascha Hauer wrote:
> On Fri, Feb 28, 2014 at 08:44:26AM +0100, Alexander Aring wrote:
> > Signed-off-by: Alexander Aring <alex.aring@gmail.com>
> > ---
> > fs/ramfs.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 69 insertions(+)
> >
> > diff --git a/fs/ramfs.c b/fs/ramfs.c
> > index f45a454..4b93c2e 100644
> > --- a/fs/ramfs.c
> > +++ b/fs/ramfs.c
> > @@ -608,6 +608,48 @@ static int ramfs_probe(struct device_d *dev)
> > return 0;
> > }
> >
> > +static int foofs_read(struct device_d *_dev, FILE *f, void *buf, size_t insize)
> > +{
> > + if (f->pos == strlen("Hello World!\n"))
> > + return 0;
> > +
> > + return sprintf(buf, "%s", "Hello World!\n");
> > +}
>
> You should never read more bytes than insize. This is also true for
> insize == 0. Implement this correctly and you'll see that your patches
> do not solve the problem.
>
yes it's not correctly implemented. Maybe I implement a "testfs"
filesystem for barebox with unit-tests which can be used to test the
filesystem layer to see if something broken or not. This fs should be
based on ramfs.
The fs tests be placed into commands -> testing and it's only interesting for
some developers.
- Alex
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2014-03-03 8:56 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-28 7:44 [RFC 0/3] current read implementation and POSIX Alexander Aring
2014-02-28 7:44 ` [RFC 1/3] ramfs: add foofs for testing Alexander Aring
2014-02-28 7:56 ` Alexander Aring
2014-03-03 8:36 ` Sascha Hauer
2014-03-03 9:08 ` Alexander Aring [this message]
2014-02-28 7:44 ` [RFC 2/3] fs: read: handle zero files Alexander Aring
2014-02-28 7:44 ` [RFC 3/3] libbb: read_full: use read return instead size Alexander Aring
2014-02-28 8:03 ` Alexander Aring
2014-02-28 14:21 ` Sascha Hauer
2014-02-28 17:12 ` Alexander Aring
2014-02-28 17:58 ` Alexander Aring
2014-03-03 8:30 ` Sascha Hauer
2014-03-03 9:04 ` Alexander Aring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140303090820.GB24214@x61s.Speedport_W_921V_1_24_000 \
--to=alex.aring@gmail.com \
--cc=barebox@lists.infradead.org \
--cc=s.hauer@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox