Shachar Raindel wrote:
Note that if you have already implemented the "give away the CPU while
no input, until input arrives", adding the delay bit becomes
relatively simple (storing the jiffies value when writing the first
byte in the buffer, comparing it to now, if smaller than minimum,
going i
On Tue, Apr 26, 2011 at 11:33 PM, Nadav Har'El wrote:
> On Tue, Apr 26, 2011, Eli Billauer wrote about "Re: [Haifux] Implementing
> read() like UNIX guys like it":
>> >(...) Second, if the CPU *did* have "something useful" to do (run other
>> >pro
On Tue, Apr 26, 2011, Eli Billauer wrote about "Re: [Haifux] Implementing
read() like UNIX guys like it":
> >(...) Second, if the CPU *did* have "something useful" to do (run other
> >processes,
> >or whatever), it would, causing a bit more time to pass bet
Hello,
Regarding your previous mail, we agree, except that I will implement the
"wait a little" thing. Believe me, after implementing the hardware part,
kernel programming is a breeze.
Nadav Har'El wrote:
The drawback of doing this
exactly like this, is that if data arrives at a slow rate
On Sat, Apr 23, 2011, Eli Billauer wrote about "Re: [Haifux] Implementing
read() like UNIX guys like it":
> >if the user calls "read" and there is data - return what you have to the
> >user without blocking.
> That is one of the options I considered. The dra
On Fri, Apr 22, 2011, Eli Billauer wrote about "[Haifux] Implementing read()
like UNIX guys like it":
> Now the dilemma: Suppose that the read() method was called with a requested
> byte count of 512. The driver checks its internal buffer, and discovers
> that it can supply
Hi,
All three modes will be implemented anyhow. What I get from the answers
so far is that there is no standard solution indeed, so I'll go for the
TCP/IP-like solution by default (wait some 10 ms before returning a
non-full read() buffer). I suppose this will do more or less what most
peopl
Hi Eli,
Since I don't think that there is a definite answer to your dilemma, I suggest a
common solution to it, which you might not like, but here it goes: implement all
three behaviors and use module parameters to select and configure each mode.
Then you can play and experiment with each of them
Hello Guy,
guy keren wrote:
first - it does not seem that you have a notion of "end of file" for
your input - is there?
As a matter of fact there is: An extra line (in hardware) will say "no
more data from hardware" which will cause an end of file condition on
the Linux side. This is not man
Hi Eli,
i'm afraid you're trying to solve the "holy grail" of non-local files.
you can't hold the pole on both sides.
first - it does not seem that you have a notion of "end of file" for
your input - is there? the only time when read is allowed to return 0,
is when it reached end of file (for a
Hi Muli,
I'll answer the your last question first: What I'm doing is basically a
general-purpose connection between a hardware FIFO within an FPGA and a
device file in Linux, with PCI Express as the data transport. That's why
I don't know if data will be coming constantly or in small drops in
On Fri, Apr 22, 2011 at 01:31:02PM +0300, Eli Billauer wrote:
> The overall package I'm working on is kind-of general purpose, and
> it's the package's user who chooses how the hardware input behaves.
> I can't know anything about the data flow behavior, and still, I
> want the reads from the rele
Hello all,
I'm implementing a Linux device driver for a piece of hardware I'm
working on. It's important for me that it will behave in a classic UNIX
way, whatever that means.
Now the dilemma: Suppose that the read() method was called with a
requested byte count of 512. The driver checks i
13 matches
Mail list logo
