On 7 Feb 02 at 9:43, Patrick Mochel wrote:
> > And neither of driverfs_read_file nor driverfs_write_file supports
> > semantic we use with other filesystems: If at least one byte was
> > read/written, return byte count (even if error happens). Only if zero
> > bytes was written, return error code.
>
> I would think that you would want to return the error code. Say you did:
>
> echo "action parameter" > file
>
> and 'parameter' is an invalid parameter, as determined by the driver. It
> would require another arbitrary check to determine if the command
> succeeded or not if it returned the number of bytes written. Returning
> -EINVAL lets userspace know that it made a boo-boo. Is that not good?
If you want bidirectional communication, something like SOCK_SEQPACKET
or SOCK_DGRAM is better suitable. And if we learn open() to open
unix sockets, even 'echo' can be still used for configuring. I understand
that it is radical change, but why these configuration points should
look like real files if they are not ones? And you do not have troubles
with supporting lseek() on them - if contents of file is "minutes\n",
is it correct to do lseek(fd, 1, SEEK_SET); write(fd, "onths\n", 6);
or is it incorrect usage?
If you do not want to change these objects from files to sockets,
I agree with your explanation for write(). But I do not agree with this
semantic for read() - reading byte after byte, and reading in one big
chunk should not yield in different results on regular files, otherwise
couple of nasty surprises is hidding there.
Thanks,
Petr Vandrovec
vandrove@vc.cvut.cz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Feb 07 2002 - 21:01:04 EST