mail archive of the barebox mailing list
 help / color / mirror / Atom feed
* [RFC 0/3] current read implementation and POSIX
@ 2014-02-28  7:44 Alexander Aring
  2014-02-28  7:44 ` [RFC 1/3] ramfs: add foofs for testing Alexander Aring
                   ` (2 more replies)
  0 siblings, 3 replies; 13+ messages in thread
From: Alexander Aring @ 2014-02-28  7:44 UTC (permalink / raw)
  To: barebox

Hi all,

first I want to say "Sascha, please don't apply this patch serie!". I suppose I
detected some incompatible POSIX read call behaviour.

History:

I am thinking about to add a procfs into barebox and I begun to hack this while
I sitting in the train. I don't want to talk about the procfs idea right now,
maybe we don't need something like this. But while I hacked it I detected some
misbehaviour of read(2).

Issue:

read returns the number of bytes which are readed if there are no bytes it should
return 0;

But if the file is zero read will return nothing, this is fixed in Patch 2/3 (please
review carefully, I did this fix fast and check only if it working)

Some commands/functions check if the file is zero and then these functions calls no read
but this is wrong. When a file is zero, read can read some bytes of course. A zero file
not indicate that the file has no content. Maybe I should reference the ugly POSIX opengroup
documentation, but you can see it yourself in linux:

ls -l /proc/version:
-r--r--r-- 1 root root 0 Feb 28 08:30 /proc/version

is a zero file and contains information with "cat /proc/version".

Patch 3/3 fix this issue for commands like edit which use the read_full function which
should read contents with the return value of read and not with size value.


To test the behaviour I advice you this steps:

1. Apply patch 1/3 which adds a simple ugly hacked foofs.

2. Compile a sandbox and start it.

3. in barebox run: "mkdir /bar;mount none foofs /bar"

4. run "cat /bar/foobar" and "edit /bar/foobar" -> nothing will be displayed

5. Apply patch 2/3 and 3/3 and rerun steps 2-4



So why I don't fix this issue? Because I can't test everything and I think some filesystem
and other commands can't deal with it and maybe we don't want to fix this issue and accept the
current behaviour. :-(

Another hint:

Sascha had some problems with zero files in tftpfs maybe there is some relationship between
this issue and the zero file tftpfs files... because the read of zero files is currently some
kind of broken. :-)

- Alex

Alexander Aring (3):
  ramfs: add foofs for testing
  fs: read: handle zero files
  libbb: read_full: use read return instead size

 fs/fs.c     |  3 ---
 fs/ramfs.c  | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 lib/libbb.c |  2 +-
 3 files changed, 70 insertions(+), 4 deletions(-)

-- 
1.9.0


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2014-03-03  8:56 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox