On Thu, 7 Feb 2002, Petr Vandrovec wrote:
> 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.
Ok, I agree with your argument concerning read().
Concerning reading/writing from offsets, it's up to the drivers for them
to either support it or not. In the files I've done so far, I return 0 if
show() is called with an offset. Which will give different results if you
read byte-by-byte or an entire chunk.
It makes the callbacks simpler, but it is not technically correct.
Something I did a while ago was implement default callbacks for basic
types. So you would have something like:
default_show_u32(char * buf, size_t count, loff_t off, u32 * data)
{
...
}
So the driver could do
driver_show(struct device * dev, char * buf, size_t count, loff_t off)
{
return default_show_u32(buf,count,off,&data);
}
And in the default_* handle the offset appropriately.
If that seems reasonable, I'll dig it up and integrate it...
-pat
-
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