[lkml]   [2002]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] read() from driverfs files can read more bytes

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...


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:18    [W:0.040 / U:6.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site