read() from driverfs files can read more bytes

read() from driverfs files can read more bytes

Post by Petr Vandrove » Sat, 09 Feb 2002 02:40:06





> > Attached patch adds check that returned value is less then requested
> > byte count. I know that actual callback function device_read_status()
> > should also be fixed, but I found this bug after midnight and
> > decided to sleep a little :)

> That sanity check was in there, once upon a time. However, in moving the
> weight from the driver callbacks to the driverfs read_file() and
> write_file(), it must have got dropped...

> Thank you. It's been applied and will be pushed forward.

[I have only 2.5.3 sources here yet]

Can you also check for size >= PAGE_SIZE on enter to entry->show()
procedure? It looks ugly to me that each driver has to check for this
constant unless it wants to smash some innocent kernel memory.

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.
                                Thanks,
                                            Petr Vandrovec

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

read() from driverfs files can read more bytes

Post by Patrick Moche » Sat, 09 Feb 2002 02:50:15


Quote:> Can you also check for size >= PAGE_SIZE on enter to entry->show()
> procedure? It looks ugly to me that each driver has to check for this
> constant unless it wants to smash some innocent kernel memory.

Done. Thanks.

Quote:> 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?

        -pat

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

read() from driverfs files can read more bytes

Post by Thomas Hoo » Sat, 09 Feb 2002 03:20:10


Quote:> Can you also check for size >= PAGE_SIZE on enter
> to entry->show() procedure?

FYI I recently wrote a patch for procfs which addresses a
similar problem there.  See the link at:
   http://panopticon.csustan.edu/thood/pnpbios.html

--
Thomas Hood

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

read() from driverfs files can read more bytes

Post by Petr Vandrove » Sat, 09 Feb 2002 05:20:10



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

What about extremelly nice stuff Al Viro made for us in
fs/seq_file.c ? It made putting stuff into procfs really easy...
                                            Petr Vandrovec

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

read() from driverfs files can read more bytes

Post by Patrick Moche » Sat, 09 Feb 2002 05:30:10




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

> What about extremelly nice stuff Al Viro made for us in
> fs/seq_file.c ? It made putting stuff into procfs really easy...

It is really nice, but it's too much for the common case. The goal is to
have each file export one and only one value. Setting up an iterator is
overkill for one value.

        -pat

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

read() from driverfs files can read more bytes

Post by Alexander Vir » Sat, 09 Feb 2002 05:30:12



> It is really nice, but it's too much for the common case. The goal is to
> have each file export one and only one value. Setting up an iterator is
> overkill for one value.

You don't have to use the iterator side of that.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

read() from driverfs files can read more bytes

Post by Patrick Moche » Sat, 09 Feb 2002 06:10:12




> > It is really nice, but it's too much for the common case. The goal is to
> > have each file export one and only one value. Setting up an iterator is
> > overkill for one value.

> You don't have to use the iterator side of that.

Well, I'll be...

I like the seq_ stuff, and the ->read() side of things take care of the
issues discussed in this thread. What's even nicer is that if I convert to
that, driver callbacks become something like either:

int driver_show(struct device * dev, struct seq_file * m)

or

int driver_show(struct device * dev, char * buf)

Have you considered doing write()?

        -pat

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

read() from driverfs files can read more bytes

Post by Alexander Vir » Sat, 09 Feb 2002 06:40:14



> issues discussed in this thread. What's even nicer is that if I convert to
> that, driver callbacks become something like either:

> int driver_show(struct device * dev, struct seq_file * m)

> or

> int driver_show(struct device * dev, char * buf)

Preferably the former.

Quote:> Have you considered doing write()?

I had and that's going to be resurrected when remount() will be dealt
with (options-parsing both benefits a lot from and is a good testbed for
such helpers).

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

read() from driverfs files can read more bytes

Post by Pavel Mache » Sun, 10 Feb 2002 06:20:15


Hi!

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

[snip solution]

Why not just say those files are character devices? It is okay for
character device to behave like crazy ;-).
                                                                        Pavel
--
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. read() from driverfs files can read more bytes then requested

That sanity check was in there, once upon a time. However, in moving the
weight from the driver callbacks to the driverfs read_file() and
write_file(), it must have got dropped...

Thank you. It's been applied and will be pushed forward.

        -pat

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. Debian 2.2.16 - HP Printer, Zoom ISA modem, soundcard

3. read() does not return bytes read from FIFO - pipe.txt [1/1]

4. RockRidge extension converter - I wrote one, anybody else want it?

5. Q: How do I read linux dirs byte-by-byte?

6. Wizard UK (London) Solaris 10 training

7. Reading bytes from a file?

8. Communicator 4 b6 shell problem

9. Read a File with 8200 Bytes

10. LILO answers HERE read read read

11. Reading files using kHTTPd method, first byte only?

12. Reading a directory and knowing which type of file am I reading

13. [ak@suse.de: Re: iosched: impact of streaming read on read-many-files]