On Tuesday, January 30, 2001 4:53 PM, Ralph Blach
[off-list ref] wrote:
I am writing a character device driver. I want this device driver to
return an error if the user request less than say 1024 byte of data.
What errno should I use? Is it legal to return an error if not enouth
bytes are requested?
I have a similar driver that wants exactly one long's worth of data to
be read. If the supplied buffer is smaller than a long, I return 0,
otherwise I return sizeof(long) (assuming their are no other errors).
Admittedly this does not let the user level distinguish "buffer too
small" from "no data", but I let the programmer at the user level deal
with that! Just mention it in the documentation for your driver, if
there is any.
Wolfgang Denk suggested EINVAL. I didn't use that as the man page for
read(2) says that means "fd is attached to an object which is unsuitable
for reading." There's no harm in overloading this meaning though. Just
document what your driver does.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Hi Ian,
In your driver's read() fileop implementation, assuming you're using a non-blocking
technique, if the count parameter is not 1024 just return 0 for num byes written to
user's buffer. The error codes are actually used as -EINVAL for example, any
positive return value or 0 indicates the bytes actually processed. Also if you're
intending the user program to select() your device then you need to implement the
poll() fileop.
I just finished writing a non-blocking char device driver, so can offer some tips if
need be.
Cheers, Ron
Ron Bianco
Computer Systems Technologist
Level Control Systems
email: ronb@junction.net
phone: 250-549-2558 Ext 8
web: www.lcsaudio.com
-----Original Message-----
From: owner-linuxppc-embedded@lists.linuxppc.org
[mailto:owner-linuxppc-embedded@lists.linuxppc.org]On Behalf Of Ian
Abbott
Sent: Wednesday, January 31, 2001 10:48 AM
To: Embedded Linux list
Subject: RE: which errno should I use
On Tuesday, January 30, 2001 4:53 PM, Ralph Blach
[off-list ref] wrote:
quoted
I am writing a character device driver. I want this device driver to
return an error if the user request less than say 1024 byte of data.
What errno should I use? Is it legal to return an error if not enouth
bytes are requested?
I have a similar driver that wants exactly one long's worth of data to
be read. If the supplied buffer is smaller than a long, I return 0,
otherwise I return sizeof(long) (assuming their are no other errors).
Admittedly this does not let the user level distinguish "buffer too
small" from "no data", but I let the programmer at the user level deal
with that! Just mention it in the documentation for your driver, if
there is any.
Wolfgang Denk suggested EINVAL. I didn't use that as the man page for
read(2) says that means "fd is attached to an object which is unsuitable
for reading." There's no harm in overloading this meaning though. Just
document what your driver does.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
I'm using HHL developement kit.
I used command 'add-symbole-file' for module debugging, but It doesn't work
properly...
I loaded the object file, and typed 'list <function>' command
The module has 10 functions included in one source file, but I can only access 4
of them form start line.
When I typed 'list' command for 'device_release', this message displayed.
No line number known for device_release.
Maybe it seems that only some portion of symbols are loaded.
Why aren't whole symbols loaded?
This happened using gdb 5.0 for powerpc cross debugging, but never happened
using i386 debugging for the same source.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Sorry, I just fount there was a problem not on debugger but compiler.
When I loaded x86 object file to gdb for powerpc (It seems symbols are
compatible) I can see the functions. but loaded ppc object file to gdb for x86
I can't see the functions.
The compiler for ppc is gcc on HHL developement kit. Of course I gave option
'-g'.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/