Andre DRASZIK wrote:
Hi,
Yes, and I also posted a patch for dynamic majors a while ago, where it
was thought that nobody needs dynamic majors in fusion?
Hi Andre,
yes correct, although this initial patch only allowed dynamic allocation
and would hamper people who still used fixed major/minors in their
RFSs. I now decided to change this patch accordingly, with the patch of
Timothy helping too.
Anyway - Nils, why do you initialize
fusion_major = FUSION_MAJOR;
twice in your patch, shouldn't be necessary?
uh.. I guess not..
I do like to init static variables, and am too kernel n00b to know
exactly when register_devices() is called.
If you confirm I can remove the first (static) init.
Greets
Niels
Cheers,
Andre'
On Mon, 2009-11-16 at 19:42 +0100, Niels Roest wrote:
Hi Timothy,
supporting a dynamic major was something missing indeed.
I do propose to implement it slightly different, namely first try the
static major, and attempt dynamic assignment on failure.
This makes sure that systems without udev will still work.
I attached my patch..
Regarding /dev/fusion/0, a recent change suggested by a fellow
mailing-lister now tries both variants. This did not yet manage to find
its way in a release.
Also, I believe André Draszik provided an updated Makefile which I did
not fully check yet, but you might have a look to see if it suits your
needs, then I'll check it in.
Not sure why you are having problems with FCEF_ONEWAY..
Thanks for the updates,
Greets
Niels
Strelchun, Timothy wrote:
Hi guys,
Here's a patch for linux-fusion-8.1.1 that handles dynamic major number
generation. In the interest of quickly getting this out, I have not stripped
the original unmodified code (which the compile will revert back to if
INTELCE_CHANGES is not defined).
I also attached a full patch for the changes we did as described below. Not
all, but most of the makefile changes are to custom the package work to build
as a subcomponent in a different build environment.
Files: Makefile
Modified to allow for proper building on kernel 2.6.28
Files: linux/drivers/char/fusion/Makefile-2.6
linux/drivers/char/fusion/fusiondev.c
tests/calls.c
tests/latency.c
tests/throughput.c
tests/Makefile
Makefile
Modified makefiles to not depend on the host's kernel because the
target's kernel is often different than the host's kernel and was
modifying how the compile occurred.
Modified makefile to include IntelCE_Version.o and use DFB_FUSION_NAME
environment variable in KERNEL_INCLUDE path.
Modified device registration to use a dynamically allocated major number.
Added INTELCE_CHANGES define to the Makefile.
Modified tests to use /dev/fusion0 instead of /dev/fusion/0.
Modified the 'calls' test to not use the FCEF_ONEWAY flag, which caused
failures on the FUSION_CALL_RETURN ioctl.
Regards,
Timothy
--
Timothy Strelchun
CE Software Engineering
Digital Home Group
Intel Corporation
The views expressed above are my own and not those of Intel
-----Original Message-----
From: directfb-dev-boun...@directfb.org
[mailto:directfb-dev-boun...@directfb.org] On Behalf Of Niels Roest
Sent: Tuesday, November 10, 2009 1:02 PM
To: Mark
Cc: directfb-dev@directfb.org
Subject: Re: [directfb-dev] Device ID issue in linux-fusion module
As a quick comment:
The device ID is indeed fixed, this is the "old fashioned" way
of assigning device IDs.
In recent desktop linux environments the major number is now
normally configurable, the linux-fusion driver should be
updatable to support that. Note that some embedded devices do
not support this, and embedded systems in general do not
suffer as strongly from major number clogging as desktop
systems. Open for patches though..
Greets
Niels
------------------------------------------------------------------------
_______________________________________________
directfb-dev mailing list
directfb-dev@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
snip snip
_______________________________________________
directfb-dev mailing list
directfb-dev@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
--
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
_______________________________________________
directfb-dev mailing list
directfb-dev@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
