On Mon, 04 Jun 2018 15:49:37 -0700, Abu Rasheda said:
> Any recommendations what device driver is missing and open source
> community could benefit from a new driver or enhance some existing driver?
Short answer: One that you have the hardware for so you can actually test your
code.
Nobody want
On Mon, 04 Jun 2018 18:31:31 -0400, Hugo Lefeuvre said:
> Do you mean that the ioctl/read/write call increments the reference
> count in this case ? It would mean that these syscalls aren't really
> using passed FD but instead create duplicates to make sure the open
> file description won't be fre
Hello,
I am an experienced Linux kernel and driver developer and have some time! I
like to develop a driver for Linux open source.
Any recommendations what device driver is missing and open source
community could benefit from a new driver or enhance some existing driver?
Where could I go for suc
> > > The vfs documentation states: release() is "called when the last
> > > reference to an open file is closed".
> > >
> > > Let's say we have a program with threads T1 and T2.
> > >
> > > - T1 calls ioctl on a file descriptor FD.
> > > - (on another processor) T2 closes FD.
> > >
> > > Since
On Mon, 04 Jun 2018 05:33:03 +0200, Valentin Vidic said:
> On Sun, Jun 03, 2018 at 06:25:56PM -0400, Hugo Lefeuvre wrote:
> > The vfs documentation states: release() is "called when the last
> > reference to an open file is closed".
> >
> > Let's say we have a program with threads T1 and T2.
> >
> Nothing fancy, just added debug print statements to the release
> and ioctl methods of the pi433 driver. The ioctl method also has
> a 5s sleep so it takes some time to execute while the other thread
> calls close on the same file descriptor.
>
> The timing should be as follows:
>
> 0s thread1
On Mon, Jun 04, 2018 at 02:05:05PM +0200, Greg KH wrote:
> The problem in this design might happen right here. What happens
> in the device between the interrupt being signaled, and the data being
> copied out of the buffer? Where do new packets go to? How does the
> device know it is "safe" to
On Mon, Jun 04, 2018 at 03:55:34PM +0530, Mahesh Sivapuram wrote:
> Hello All,
>
> We are facing an issue with 3.10.65 kernel + RT69 patch on a 12core xeon.
First off, that is a very old and "obsolete" kernel version. As you are
probably stuck at that version due to a support contract, I strongl
On Mon, Jun 04, 2018 at 01:12:48PM +0200, Christoph Böhmwalder wrote:
> Hi,
>
> I'm not sure how on-topic this is on this list, but I have a question
> regarding a device driver design issue.
>
> For our Bachelor's project my team and I are tasked to optimize an
> existing hardware solution. The
Hi,
I'm not sure how on-topic this is on this list, but I have a question
regarding a device driver design issue.
For our Bachelor's project my team and I are tasked to optimize an
existing hardware solution. The design utilizes an FPGA to accomplish
various tasks, including a Triple Speed Ethern
Hello All,
We are facing an issue with 3.10.65 kernel + RT69 patch on a 12core xeon.
We are running real time applications (higher priority than kernel threads,
requiring the resolution of 1ms or less) on ioslated CPU's which are
configured through kernel boot arguments as indicated below. Also, w
On Mon, Jun 04, 2018 at 06:27:43AM +, Nicholas Mc Guire wrote:
> are you using kprobes to get this information or how did you trace
> these calls ? could you explain how you did that ? I assume that
> would be of interest to others as well not only me.
Nothing fancy, just added debug print sta
12 matches
Mail list logo
