> > Also, do not use a random MAJOR number that you just picked out of no > > where, that too will break working systems and needs to be fixed. Use > > the dynamic allocation method, or better yet, just use a misc device. > > What do you exactly mean by misc device ?
> Look at include/linux/miscdevice.h for the details. I will study http://www.embeddedlinux.org.cn/essentiallinuxdevicedrivers/final/ch05lev1sec7.html on my own. I am still working on the hardware verilog side now. > I am actually a bit worried with circ_queue structure and its corresponding > push() and pull() functions which systemtap complains to have some > significant timing overhead, but to be frank, this is not the root cause of > why the full duplex version of the driver is slower. > Yes, that's kind of obvious by looking at that code :) > Again, fix up the driver to use the in-kernel data structures for this > type of thing and you will see a much better improvement in performance. To be frank, the 3x slowdown is actually due to "one extra wake_up() call" in the full-duplex version of riffa_driver.c line 685 if I am not wrong. https://github.com/promach/riffa/blob/full_duplex/driver/linux/riffa_driver.c#L685 If I use https://www.kernel.org/doc/html/v4.19/core-api/circular-buffers.html#the-producer instead of https://github.com/promach/riffa/blob/full_duplex/driver/linux/circ_queue.c , I actually worry that the in-kernel data structure with memory barrier can actually have more timing delay or overhead than atomic functions used in circ_queue.c Please advise regarding wake_up(consumer). _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
