Re: Driver "Read" standard usage ('protocol')

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Aug 21, 2007 at 05:11:34PM +0200, anon... anon.al wrote:
> On 8/21/07, Erik Mouw <mouw@xxxxxxxxxxxx> wrote:
> > When read() returns 0 it has the special meaning that you reached the
> > end of file (see read(2)). You simply cannot return 0 without breaking
> > over 25 years of established Unix semantics.
> 
> Am just beginning with this stuff, and you might be wondering "where
> am I coming from" with this stuff: ->
> If I use cat, on my driver, it expects 4096 bytes (on my machine),
> meaning it will block continuously until it has got all that data.

It will probably get only 16 bytes at every read.

> But that is not what I want.
> I want to test my driver (I thought I'd use cat), and get back at
> least one message with cat's blocking read.
> Because in reality, the HW-device will never reach EOF, it will supply
> new messages until "the end of time". I don't want my cat to wait for
> ever...

Well, that's what cat does, it reads until it reaches EOF or until it
got an IO error.

> ... is my intuition correct, that cat is the wrong thing to use, for
> testing this driver...

Yeah, better use dd.

> > > The application then knows that no new data is available. Nonetheless, if
> > > the application still wants the next 16 bytes, it will start a new round,
> > > again calling "read(fd, buffer, len)" with len = 16, which will now cause
> > > the instance to block (note removed), until these 16 bytes are available.
> >
> > No, the applications now knows that there is no more data available and
> > exits.
> 
> Yes, that is actually what I want(ed). In this point in time, the
> application has received at least one message and now there's no
> additional message left. (This may change in 5 seconds, if a new msg
> arrives)
> 
> But I think I do see your point:
> I think I have to develop my own cat, which uses 2 flags:
> 
> mycat --step=16 --num=32
> mycat -s16 -n32

No need for that, dd already does what you want (and more):

  dd if=/dev/yourdriver bs=16 count=32

> In other words: put the desired functionality into the application,
> and not code the driver for a specific application - cat.
> Hope this makes sense?

That's correct. cat can be useful in lots of cases, but in other cases
it's worthless. You can't for example use cat on tape devices, they
really expect reads with the correct blocksize.


Erik

- -- 
They're all fools. Don't worry. Darwin may be slow, but he'll
eventually get them. -- Matthew Lammers in alt.sysadmin.recovery
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGzAuR/PlVHJtIto0RAtQOAJ9ZDiw4w9oPQpiqzguhaDAJW8QbAgCfZZTx
oeSIx4n0MmKOFxUFgQdPNF8=
=kJFs
-----END PGP SIGNATURE-----

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux