On Sun, Dec 02, 2012 at 07:26:27PM +0200, Eli Billauer wrote:I'm currently writing some documentation which will cover the API and also help reading the code, I hope. It takes some time...
On 11/30/2012 06:32 PM, Greg KH wrote:Given that I don't really understand how you can have that many device
It has just occurred to me that DYNAMIC_MINORS is 64It is no problem to create dozens of misc devices. It makes your driverWhen Xillybus is used, the whole system's mission is usually around>>+static struct class *xillybus_class;>Why not just use the misc interface instead of your own class?
it (e.g. it's a computer doing data acquisition through the Xillybus
pipes). So giving it a high profile makes sense, I believe. Besides,
a dozen of device files are not rare.
smaller, contain less code that I have to audit and you have to ensure
you got right, and it removes another user of 'struct class' which we
are trying to get rid of anyway. So please, move to use a misc device.
(drivers/char/misc.c), so I guess that limits the number of misc
devices that can be generated, at least with dynamically allocated
minors. I previously mentioned "a dozen" as the number of devices,
but I've already run tests with 100+ devices, and I can also think
of a sane application for that.
So if I understood the situation correctly, it looks like using misc
devices will create a limitation which will be reached sooner or
Any suggestion what to do?
nodes, because I don't know what they all seem to be needed for, I can't
answer this question.
Again, any hints on the user/kernel api you use/need here? Does it
really have to be device nodes? What's wrong with the simple firmware
interface the kernel provides?