AW: [En-Nut-Discussion] Get file size vom VIRTUALDEVICE (was:Register overwriting in interrupted code)
Harald Kipp
harald.kipp at egnite.de
Sun Jul 25 14:05:17 CEST 2004
Oliver,
At 12:53 25.07.2004 +0200, you wrote:
> >
> > Actually ioctl() should be used, but I see the point. Updating
> > a counter in VIRTUALDEVICE is much less hassle then trying
> > to retrieve the number of bytes in a NETBUF queue or whatever.
>I didn't think of an additional counter, but an additional function, that
>returns the input buffer size...
I see. Right, with such a function it's up to the driver,
how it manages its buffer bookkeeping. But then we should
stick to ioctl() instead of creating additional functions.
>But, another idea (more advanced :-): What about defining some global ioctl
>commands, that are independent of the underlying hardware.
>In uart.h the ioctl definitions start from 0x100, so it makes sense for me
>to start the global ioctl commands at 0x0, for example. (The ioctl commands
>from wlan.h must then be adjusted.)
The problem with WLAN and other parts done by Michael
Fischer was, that he had been too fast for me in demanding
interface definitions. Example: The NUTDEVICE::dev_size
was a bad idea, born out of some inconsistencies with
NUTDEVICE, NUTFILE and related calls. Without following
the black magic of Nut/OS file/device relationship, I assume
that it should be possible now to get the size of a
file by an ioctl call as well.
Intentionally I reserved the first numbers for some
global ioctls, but hadn't any idea what to define global.
Querying buffer sizes is indeed a good candidate. Another
two are input and output buffer flushing. Never liked
the _write(NULL) method. Also setting buffer sizes is
something global.
Using global ioctl commands will simplify applications
and allow to write more general I/O routines, which
work with different types of devices.
Harald
More information about the En-Nut-Discussion
mailing list