[9fans] v9fs mounting in linux

[9fans] v9fs mounting in linux

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm sorting through mounting 9p services under linux.
Trying the example from Russ's swtch.com/v9fs page, I get an error:

% sudo mount -t 9p -o proto=unix,name=$USER `namespace`/acme /mnt/acme
mount: block device /tmp/ns.plalonde.:0/acme is write-protected,
mounting read-only
mount: cannot mount block device /tmp/ns.plalonde.:0/acme read-only
%

I've tried changing the permissions on the acme pipe, to no avail.

What am I doing wrong?

I do note a couple of differences from Russ' examples: my kernel
module (FC6) seems to be called 9p not 9p2000, and the protocol is
recognized as 9p not 9P.

Thanks,
     Paul

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFFYfyjpJeHo/Fbu1wRAlYfAKC1z0P9LF2a8SJtBlWvF3GOmnbKhACfcobg
OaGvgJWSnXimxv+CgmzIp2U=
=tbjt
-----END PGP SIGNATURE-----

Re: [9fans] v9fs mounting in linux

[erik quanstrom]

i use this in my /etc/fstab

/tmp/ns.quanstro.:0/acme	/home/quanstro/9/acme	9p	uid=1000,user,uname=quanstro,proto=unix,noauto	0 0
/tmp/ns.quanstro.:0/upasfs	/home/quanstro/9/upasfs	9p	uid=1000,user,uname=quanstro,proto=unix,noauto	0 0
/tmp/ns.quanstro.:0/sources	/home/quanstro/9/sources	9p	uid=1000,user,uname=quanstro,proto=unix,noauto	0 0
/tmp/ns.quanstro.:0/tapefs	/home/quanstro/9/tapefs	9p	uid=1000,user,uname=quanstro,proto=unix,noauto	0 0

this allows me to mount without su/sudo.  are you sure the permissions on /mnt/acme  are okay?

- erik

Re: [9fans] v9fs mounting in linux

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Adding the uid= option got me a mount, but I still fail on write to
any of the files; I can 9p write to (for exampe) acme/1/body, but any
attempt to write to the mounted version (/home/plalonde/mnt/acme/1/
body) give me a
body: rc: can't open: Permission denied

Any clues?

Thanks,
     Paul

On 20-Nov-06, at 11:15 AM, erik quanstrom wrote:

> i use this in my /etc/fstab
>
> /tmp/ns.quanstro.:0/acme	/home/quanstro/9/acme	9p
> uid=1000,user,uname=quanstro,proto=unix,noauto	0 0
> /tmp/ns.quanstro.:0/upasfs	/home/quanstro/9/upasfs	9p
> uid=1000,user,uname=quanstro,proto=unix,noauto	0 0
> /tmp/ns.quanstro.:0/sources	/home/quanstro/9/sources	9p
> uid=1000,user,uname=quanstro,proto=unix,noauto	0 0
> /tmp/ns.quanstro.:0/tapefs	/home/quanstro/9/tapefs	9p
> uid=1000,user,uname=quanstro,proto=unix,noauto	0 0
>
> this allows me to mount without su/sudo.  are you sure the
> permissions on /mnt/acme  are okay?
>
> - erik
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFFYi2ipJeHo/Fbu1wRAtFlAJsGmWT4Gl8ZSatgbL7EdCph5AM2HgCgvtBp
JpXNVE92M4YBVTEX+4mHhp8=
=iVdk
-----END PGP SIGNATURE-----

Re: [9fans] v9fs mounting in linux

[ron minnich]

mount it with debug=255 and look at the error. Or, did dmesg show
anything at all?

ron

Re: [9fans] v9fs mounting in linux

[Paul Lalonde]

[-- Attachment #1.1: Type: text/plain, Size: 306 bytes --]

Ah!  A debug option.  Handy.

But I don't see anything that jumps out and says "error" to me in the
dump.  I've attached it.

This is from doing:

echo "foo" > mnt/acme/new/body

The new window appeared, as expected, but no body text made it in,
and the Permission denied came with the write.


[-- Attachment #1.2: foo --]
[-- Type: application/octet-stream, Size: 7066 bytes --]

-- v9fs_poll_mux (32005): mux ddd39a00 can write
-- v9fs_poll_proc (32005): sleeping...
-- v9fs_poll_mux (32005): mux ddd39a00 can write
-- v9fs_poll_proc (32005): sleeping...
-- v9fs_poll_mux (32005): mux ddd39a00 can write
-- v9fs_poll_proc (32005): sleeping...
-- v9fs_vfs_lookup (31275): dir: def31410 dentry: (new) c7ce3ef8 nameidata: c7050f34
-- v9fs_fid_lookup (31275):  dentry: / (c7ce3aec)
-- v9fs_t_walk (31275): fid 0 newfid 1 wname 'new'
-- v9fs_send_request (31275): mux ddd39a00 task c5e1b200 tcall c4ce8600 id 110
-- v9fs_write_work (31227): mux ddd39a00 pos 0 size 22
-- v9fs_write_work (31227): mux ddd39a00 sent 22 bytes
-- v9fs_poll_mux (32005): mux ddd39a00 can write
-- v9fs_poll_proc (32005): sleeping...
-- v9fs_poll_mux (32005): mux ddd39a00 can read
-- v9fs_poll_mux (32005): schedule read work mux ddd39a00
-- v9fs_poll_mux (32005): mux ddd39a00 can write
-- v9fs_poll_proc (32005): sleeping...
-- v9fs_read_work (31227): start mux ddd39a00 pos 0
-- v9fs_read_work (31227): mux ddd39a00 got 22 bytes
-- v9fs_deserialize_fcall (31227): size 22 id 111 tag 0
-- v9fs_read_work (31227): mux ddd39a00 fcall id 111 tag 0
-- v9fs_mux_rpc_cb (31227): req d13bea20 r c7050d20
-- v9fs_t_stat (31275): fid 1
-- v9fs_send_request (31275): mux ddd39a00 task c5e1b200 tcall c4ce8600 id 124
-- v9fs_write_work (31227): mux ddd39a00 pos 0 size 11
-- v9fs_write_work (31227): mux ddd39a00 sent 11 bytes
-- v9fs_poll_mux (32005): mux ddd39a00 can write
-- v9fs_poll_proc (32005): sleeping...
-- v9fs_poll_mux (32005): mux ddd39a00 can read
-- v9fs_poll_mux (32005): schedule read work mux ddd39a00
-- v9fs_poll_mux (32005): mux ddd39a00 can write
-- v9fs_poll_proc (32005): sleeping...
-- v9fs_read_work (31227): start mux ddd39a00 pos 0
-- v9fs_read_work (31227): mux ddd39a00 got 83 bytes
-- v9fs_deserialize_fcall (31227): size 83 id 125 tag 0
-- v9fs_read_work (31227): mux ddd39a00 fcall id 125 tag 0
-- v9fs_mux_rpc_cb (31227): req d13bea20 r c7050d24
-- v9fs_get_inode (31275): super block: df556400 mode: 40500
-- v9fs_fid_create (31275): fid create fid 1
-- v9fs_fid_insert (31275): fid 1 (d7b88720) dentry new (c7ce3ef8)
-- v9fs_vfs_lookup (31275): dir: d2e45c18 dentry: (body) c91da388 nameidata: c7050f34
-- v9fs_fid_lookup (31275):  dentry: new (c7ce3ef8)
-- v9fs_t_walk (31275): fid 1 newfid 2 wname 'body'
-- v9fs_send_request (31275): mux ddd39a00 task c5e1b200 tcall c4ce8600 id 110
-- v9fs_write_work (31227): mux ddd39a00 pos 0 size 23
-- v9fs_write_work (31227): mux ddd39a00 sent 23 bytes
-- v9fs_poll_mux (32005): mux ddd39a00 can write
-- v9fs_poll_proc (32005): sleeping...
-- v9fs_poll_mux (32005): mux ddd39a00 can read
-- v9fs_poll_mux (32005): schedule read work mux ddd39a00
-- v9fs_poll_mux (32005): mux ddd39a00 can write
-- v9fs_poll_proc (32005): sleeping...
-- v9fs_read_work (31227): start mux ddd39a00 pos 0
-- v9fs_read_work (31227): mux ddd39a00 got 22 bytes
-- v9fs_deserialize_fcall (31227): size 22 id 111 tag 0
-- v9fs_read_work (31227): mux ddd39a00 fcall id 111 tag 0
-- v9fs_mux_rpc_cb (31227): req d13bea20 r c7050e1c
-- v9fs_t_stat (31275): fid 2
-- v9fs_send_request (31275): mux ddd39a00 task c5e1b200 tcall c4ce8600 id 124
-- v9fs_write_work (31227): mux ddd39a00 pos 0 size 11
-- v9fs_write_work (31227): mux ddd39a00 sent 11 bytes
-- v9fs_poll_mux (32005): mux ddd39a00 can write
-- v9fs_poll_proc (32005): sleeping...
-- v9fs_poll_mux (32005): mux ddd39a00 can read
-- v9fs_poll_mux (32005): schedule read work mux ddd39a00
-- v9fs_poll_mux (32005): mux ddd39a00 can write
-- v9fs_poll_proc (32005): sleeping...
-- v9fs_read_work (31227): start mux ddd39a00 pos 0
-- v9fs_read_work (31227): mux ddd39a00 got 86 bytes
-- v9fs_deserialize_fcall (31227): size 86 id 125 tag 0
-- v9fs_read_work (31227): mux ddd39a00 fcall id 125 tag 0
-- v9fs_mux_rpc_cb (31227): req d13bea20 r c7050e20
-- v9fs_get_inode (31275): super block: df556400 mode: 100600
-- v9fs_fid_create (31275): fid create fid 2
-- v9fs_fid_insert (31275): fid 2 (c75815c0) dentry body (c91da388)
-- v9fs_fid_lookup (31275):  dentry: body (c91da388)
-- v9fs_vfs_setattr (31275):
-- v9fs_t_wstat (31275): fid 2
-- v9fs_send_request (31275): mux ddd39a00 task c5e1b200 tcall c4ce8600 id 126
-- v9fs_write_work (31227): mux ddd39a00 pos 0 size 62
-- v9fs_write_work (31227): mux ddd39a00 sent 62 bytes
-- v9fs_poll_mux (32005): mux ddd39a00 can write
-- v9fs_poll_proc (32005): sleeping...
-- v9fs_poll_mux (32005): mux ddd39a00 can read
-- v9fs_poll_mux (32005): schedule read work mux ddd39a00
-- v9fs_poll_mux (32005): mux ddd39a00 can write
-- v9fs_poll_proc (32005): sleeping...
-- v9fs_read_work (31227): start mux ddd39a00 pos 0
-- v9fs_read_work (31227): mux ddd39a00 got 26 bytes
-- v9fs_deserialize_fcall (31227): size 26 id 107 tag 0
-- v9fs_read_work (31227): mux ddd39a00 fcall id 107 tag 0
-- process_request (31227): Rerror permission denied
-- v9fs_mux_rpc_cb (31227): req d13bea20 r c7050d70
-- v9fs_vfs_setattr (31275): wstat error: permission denied
-- v9fs_dentry_delete (31275):  dentry: body (c91da388)
-- v9fs_dentry_release (31275):  dentry: body (c91da388)
-- v9fs_t_clunk (31275): fid 2
-- v9fs_send_request (31275): mux ddd39a00 task c5e1b200 tcall c4ce8600 id 120
-- v9fs_write_work (31227): mux ddd39a00 pos 0 size 11
-- v9fs_write_work (31227): mux ddd39a00 sent 11 bytes
-- v9fs_poll_mux (32005): mux ddd39a00 can write
-- v9fs_poll_proc (32005): sleeping...
-- v9fs_poll_mux (32005): mux ddd39a00 can read
-- v9fs_poll_mux (32005): schedule read work mux ddd39a00
-- v9fs_poll_mux (32005): mux ddd39a00 can write
-- v9fs_poll_proc (32005): sleeping...
-- v9fs_read_work (31227): start mux ddd39a00 pos 0
-- v9fs_read_work (31227): mux ddd39a00 got 7 bytes
-- v9fs_deserialize_fcall (31227): size 7 id 121 tag 0
-- v9fs_read_work (31227): mux ddd39a00 fcall id 121 tag 0
-- v9fs_mux_rpc_cb (31227): req d13bea20 r c7050e24
-- v9fs_dentry_delete (31275):  dentry: new (c7ce3ef8)
-- v9fs_dentry_release (31275):  dentry: new (c7ce3ef8)
-- v9fs_t_clunk (31275): fid 1
-- v9fs_send_request (31275): mux ddd39a00 task c5e1b200 tcall c4ce8600 id 120
-- v9fs_write_work (31227): mux ddd39a00 pos 0 size 11
-- v9fs_write_work (31227): mux ddd39a00 sent 11 bytes
-- v9fs_poll_mux (32005): mux ddd39a00 can write
-- v9fs_poll_proc (32005): sleeping...
-- v9fs_poll_mux (32005): mux ddd39a00 can read
-- v9fs_poll_mux (32005): schedule read work mux ddd39a00
-- v9fs_poll_mux (32005): mux ddd39a00 can write
-- v9fs_poll_proc (32005): sleeping...
-- v9fs_read_work (31227): start mux ddd39a00 pos 0
-- v9fs_read_work (31227): mux ddd39a00 got 7 bytes
-- v9fs_deserialize_fcall (31227): size 7 id 121 tag 0
-- v9fs_read_work (31227): mux ddd39a00 fcall id 121 tag 0
-- v9fs_mux_rpc_cb (31227): req d13bea20 r c7050e24
-- v9fs_poll_mux (32005): mux ddd39a00 can write
-- v9fs_poll_proc (32005): sleeping...
-- v9fs_poll_mux (32005): mux ddd39a00 can write
-- v9fs_poll_proc (32005): sleeping...

[-- Attachment #1.3: Type: text/plain, Size: 188 bytes --]


Thanks for your patience,

Paul

On 20-Nov-06, at 4:27 PM, ron minnich wrote:

> mount it with debug=255 and look at the error. Or, did dmesg show
> anything at all?
>
> ron


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 193 bytes --]

[9fans] Re: echo -n

[arisawa]

Thanks all for following to my question.

Just my impression ...
If 0 byte writing is a message other than EOF, then we should have
some mechanism that enables to distinguish between 0 byte read and
true EOF.
However introducing a new mechanism to system call is a great surgery.

Coming back to my original question:
	0 byte write using echo -n
What is intended by this operation?
Let  "ECHO" be another "echo" that does not write 0 byte to stdout.
How to distinguish these two commands?
Using the command in rc script to pipe will make the difference.
Are there any other cases that make difference?

If the difference is only in pipe, then we should consider:
is it a legitimate method to let the other end close the pipe?

Re: [9fans] Re: echo -n

[ron minnich]

This whole discussion has been coming up for years. I can't remember
the first time I saw it but it was definitely over a quarter century
ago. I think at some point we figured the issue was roughly akin to
the difference between the empty string and the null string -- where
EOF is the null string, and 0 bytes of data is the empty string --
which you can't actually distinguish via read. I'm NOT saying this is
exactly it, but I think it provides an analogy and a  way to think
about it.

I think Plan 9 got it completely right. Being able to push a 0-byte
write through the kernel is mighty handy. I got quite annoyed with
Unix at various points over the years as I watched "optimizations"
gobble up my attempts to get a 0 byte write through the kernel.

Score one more for Plan 9 -- it lets you do what you want to do.

I hope people enjoyed this discussion more than the up-arrow thread.

thanks

ron

Re: [9fans] v9fs mounting in linux

[ron minnich]

Looks to me like the Twstat is failing. I am guessing it is because
when you do a '>' the open will try to ftruncate the file. This is a
frequent problem with synthetics -- they return errors on Twstat when
they might be better off ignoring them.

Try a >> instead of a > and let us know.

ron

Re: [9fans] v9fs mounting in linux

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bang on!  '>>' works fine.

Thanks for the help!

Paul

On 20-Nov-06, at 6:36 PM, ron minnich wrote:

> Looks to me like the Twstat is failing. I am guessing it is because
> when you do a '>' the open will try to ftruncate the file. This is a
> frequent problem with synthetics -- they return errors on Twstat when
> they might be better off ignoring them.
>
> Try a >> instead of a > and let us know.
>
> ron

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFFYmd+pJeHo/Fbu1wRApZ3AKDfZwIlrD4WhhVl9lI9JV07lVMcCQCgs4eG
n65QePbnmfR7Uyeiu+wJapY=
=zE8z
-----END PGP SIGNATURE-----

Re: [9fans] v9fs mounting in linux

[ron minnich]

On 11/20/06, Paul Lalonde <plalonde@telus.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Bang on!  '>>' works fine.
>

so can we change acme to just ignore silly systems that try to
truncate things to 0 length (or whatever it was that was failing --
maybe the mtime as well)

ron

Re: [9fans] v9fs mounting in linux

[erik quanstrom]

i was going to suggest '>>', but it doesn't work on my system.
rather than figure it out, i'll just use the real thing.

- erik

[9fans] read of eof

[Michael Baldwin]

Obviously, a read of end-of-file should return -42. And if the data
is possessed, -666.

Seriously, there were two languages that I thought integrated
exceptions / failures well enough that you could actually use them
all the time pleasantly: Icon and Mesa. System calls (or expressions)
would "fail" instead of return in-band values, and the syntactic
sugar was light enough on calories that you didn't have the sense
that you were dragging out an exception handling harness with whipped
cream on top all the time just for one little call.

Ah well.

Re: [9fans] read of eof

[Bruce Ellis]

This is crap - we are talking about delimitered messages.

But say what you like, no one listens.

brucee

On 11/21/06, Michael Baldwin <michael@cibernet.com> wrote:
> Obviously, a read of end-of-file should return -42. And if the data
> is possessed, -666.
>
> Seriously, there were two languages that I thought integrated
> exceptions / failures well enough that you could actually use them
> all the time pleasantly: Icon and Mesa. System calls (or expressions)
> would "fail" instead of return in-band values, and the syntactic
> sugar was light enough on calories that you didn't have the sense
> that you were dragging out an exception handling harness with whipped
> cream on top all the time just for one little call.
>
> Ah well.
>
>

Re: Re: [9fans] Re: echo -n

[andrey mirtchovski]

"the parable of glenda and the multitudes"? this is stuck in my head
as the expanded version but i have not been able to find it...

Re: [9fans] Re: echo -n

[Andrew Lynch]

On 21.11.2006, at 03:32, ron minnich wrote:

> This whole discussion has been coming up for years. I can't remember
> the first time I saw it but it was definitely over a quarter century
> ago. I think at some point we figured the issue was roughly akin to
> the difference between the empty string and the null string -- where
> EOF is the null string, and 0 bytes of data is the empty string --
> which you can't actually distinguish via read. I'm NOT saying this is
> exactly it, but I think it provides an analogy and a  way to think
> about it.


I'm surprised nobody has mentioned Doug McIlroy's "The UNIX and the
Echo"(*) yet.
An amusing fable about the problem of saying nothing vs. not saying
anything.
I believe I saw an expanded version of it somewhere on the web many
years ago.

Andrew.

(*) The UNIX Programming Environment
Brian W. Kernighan & Rob Pike
Prentice-Hall, 1984

Re: [9fans] Re: echo -n

[Axel Belinfante]

http://9fans.net/archive/2001/09/54 is what you mean, I think.

> "the parable of glenda and the multitudes"? this is stuck in my head
> as the expanded version but i have not been able to find it...

Re: Re: [9fans] Re: echo -n

[andrey mirtchovski]

On 11/21/06, Axel Belinfante <Axel.Belinfante@cs.utwente.nl> wrote:
> http://9fans.net/archive/2001/09/54 is what you mean, I think.
>

thank you!

Re: [9fans] Re: echo -n

[Axel Belinfante]

> > http://9fans.net/archive/2001/09/54 is what you mean, I think.
> >
>
> thank you!

no thanks, it could very well _not_ be what you were looking for -
I realized a few minutes after posting... at least that's when I
recalled something that fitted the description better, but where that is???

Re: [9fans] Re: echo -n

[Skip Tavakkolian]

the BUGS section of echo man page should say something
like "echo -n produces a lot of output on 9fans".

Re: [9fans] Re: echo -n

[dmr]

  > This whole discussion has been coming up for years. I can't remember
  > the first time I saw it but it was definitely over a quarter century
  > ago.

Indeed.  7th edition and earlier did ignore 0-length
writes.  8th edition streams began to transmit them
over pipes (or networks).  I recall there were two
problems associated with this; one I forget, the other
was that nroff (for some input) would sometimes
generate one for no good reason, so
  nroff thing.ms | whatever
would terminate prematurely.  It was simplest to
fix nroff.

	Dennis

Re: [9fans] Re: echo -n

[Lyndon Nerenberg]

On Nov 21, 2006, at 5:32 PM, dmr@plan9.bell-labs.com wrote:

> 8th edition streams began to transmit them
> over pipes (or networks).

Since this thread started I've been nagged by the memory of UUCP's
'e' protocol.  If my brain hasn't completely cached out, 'e' used the
ability of Datakit to preserve 0-length messages as an inband
delimiter, vs. the 't' protocols use of explicit protocol field
length counters.  (Or was it 'x' that used null read/write ops ... ?)

--lyndon

Re: [9fans] Re: echo -n

[Bruce Ellis]

0 is a number ... a fine and useful one.  if you want to ignore echo
then SYSCALL(1) will do exactly what you want.

brucee

On 11/24/06, Lyndon Nerenberg <lyndon@orthanc.ca> wrote:
> On Nov 21, 2006, at 5:32 PM, dmr@plan9.bell-labs.com wrote:
>
> > 8th edition streams began to transmit them
> > over pipes (or networks).
>
> Since this thread started I've been nagged by the memory of UUCP's
> 'e' protocol.  If my brain hasn't completely cached out, 'e' used the
> ability of Datakit to preserve 0-length messages as an inband
> delimiter, vs. the 't' protocols use of explicit protocol field
> length counters.  (Or was it 'x' that used null read/write ops ... ?)
>
> --lyndon
>

Re: [9fans] Re: echo -n

[Lyndon Nerenberg]

On Nov 21, 2006, at 1:01 AM, Fco. J. Ballesteros wrote:

> Do you remember why you wanted to push a 0-byte write?

Look at what FTP has to do with out-of-band messages to abort a
transfer.

Re: [9fans] Re: echo -n

[Bakul Shah]

> > :  I think Plan 9 got it completely right. Being able to push a 0-byte
> > :  write through the kernel is mighty handy. I got quite annoyed with
> > :  Unix at various points over the years as I watched "optimizations"
> > :  gobble up my attempts to get a 0 byte write through the kernel.

Reminds me of OSes where you couldn't have a 0 length file.
Their designers couldn't imagine why anyone would perform
such a despicable act.

> but, seriously, it's the general issue that you need to tell something
> (program, io device, network, whatever) that you don't have anything
> to say, which is not the same as saying nothing.

I am waiting for someone to write a book with the title
"zero one two...0xffffffff: Facts and Explorations of Computer Science".

Re: [9fans] Re: echo -n

[Brantley Coile]

> it's usually io or networking.

like runing wc on a remote machine.  You have
to send an end-of-file to wc's input without
taking down the connection.  Otherwise you never
see the counts.

Re: [9fans] Re: echo -n

[erik quanstrom]

of course it goes without saying that an honorable fellow like
yourself wouldn't be appropriating punch cards that way.

;-)
- erik

On Tue Nov 21 10:38:17 EST 2006, rminnich@gmail.com wrote:
> there is of course the need to write a blank punch card with a 0-byte
> write, assuming you can find a card punch. And as david mentioned, in
> a real case, tape marks.

Re: [9fans] Re: echo -n

[ron minnich]

On 11/21/06, Fco. J. Ballesteros <nemo@lsub.org> wrote:
> :  I think Plan 9 got it completely right. Being able to push a 0-byte
> :  write through the kernel is mighty handy. I got quite annoyed with
> :  Unix at various points over the years as I watched "optimizations"
> :  gobble up my attempts to get a 0 byte write through the kernel.
>
> Do you remember why you wanted to push a 0-byte write?


it's usually io or networking.

many of the wacky networks I have dealt with have at times needed a
0-byte write; we got the effect via ioctl, since the kernel gobbled up
0-byte writes, the kernel of course knowing much better than you what
you were trying to do, e.g. Linux.

there is of course the need to write a blank punch card with a 0-byte
write, assuming you can find a card punch. And as david mentioned, in
a real case, tape marks.

but, seriously, it's the general issue that you need to tell something
(program, io device, network, whatever) that you don't have anything
to say, which is not the same as saying nothing.

ron

Re: [9fans] Re: echo -n

[Dave Lukes]

My .25¢:
    echo -n
does precisely nothing,
so if you want that effect as an rc command, then why not use, for example:
     . /dev/null
instead?

>  Do you remember why you wanted to push a 0-byte write?

How else can you write tapemarks on a half-inch magtape?

Also, "push a 0-byte write" is the wrong way to think about it:
it's "send a 0-length chunk".
In the case of boundaryless media, it's nugatory; In the case of 
boundaryful media, it's useful.

To be honest, I don't care if no-one can think of an application for it.
To me it makes perfect sense, whereas the alternative doesn't:
1) write boundary preservation is definitely useful, and I've heard 
no-one say otherwise.
   Therefore you have to chose to either refuse or ignore 0-length 
records (which?) as a special case
   or you do as is done now and treat them like any other chunk.

2) it's impossible to reassemble write boundaries if they're lost:
   the converse is untrue.
   i.e. you can simulate a boundaryless system easily with a boundaryful 
system,
   but not vice-versa.

To me, either of the above is sufficient reason to leave things as they are.

DaveL

Re: [9fans] Re: echo -n

[Fco. J. Ballesteros]

:  I think Plan 9 got it completely right. Being able to push a 0-byte
:  write through the kernel is mighty handy. I got quite annoyed with
:  Unix at various points over the years as I watched "optimizations"
:  gobble up my attempts to get a 0 byte write through the kernel.

Do you remember why you wanted to push a 0-byte write?

thanks