Hi,
I'm trying to build FUSD [1] against current kernels [2.6.22]. I get errors
[2]:
I tried looking into it but not being a kernel hacker i must admit i didn't
even find out where sysfs_dentry is defined (so i can make the type
complete). Or whether this would even be the correct way to fix it..
My goal is to hack up oss2jack [3] to use ALSA pcm devices.. And a later goal
is to create a virtual ALSA soundcard [which would multiplex access to a real
non hw-mixing capable soundcard] to finally end the dmix software mixing woes
linux users have to endure for the last years :)
I don't expect you to fix it for me. I would just be glad about infos on where
to get more infos enabling me to fix this :) Of course the more concise and
practical the advice the better :)
Regards,
Flo
[1] http://svn.xiph.org/trunk/fusd
[2] ~/source/build_stuff/fusd$ make
make -C libfusd
make[1]: Entering directory `/home/tapas/source/build_stuff/fusd/libfusd'
make[1]: Nothing to be done for `default'.
make[1]: Leaving directory `/home/tapas/source/build_stuff/fusd/libfusd'
make -C kfusd
make[1]: Entering directory `/home/tapas/source/build_stuff/fusd/kfusd'
make -C /lib/modules/2.6.22-11-generic/build
SUBDIRS=/home/tapas/source/build_st
uff/fusd/kfusd
EXTRA_CFLAGS=-I/home/tapas/source/build_stuff/fusd/kfusd/../inclu
de modules
make[2]: Entering directory `/usr/src/linux-headers-2.6.22-11-generic'
CC [M] /home/tapas/source/build_stuff/fusd/kfusd/kfusd.o
/home/tapas/source/build_stuff/fusd/kfusd/kfusd.c: In function ‘to_kobj’:
/home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:135: error: dereferencing
poin
ter to incomplete type
/home/tapas/source/build_stuff/fusd/kfusd/kfusd.c: In
function ‘fusd_register_de
vice’:
/home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2049: error: ‘struct kset’
has
no member named ‘kset’
/home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2049: warning: type defaults
t
o ‘int’ in declaration of ‘__mptr’
/home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2049: warning:
initialization
from incompatible pointer type
/home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2049: error: ‘struct kset’
has
no member named ‘kset’
/home/tapas/source/build_stuff/fusd/kfusd/kfusd.c: At top level:
/home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2603: error: unknown
field ‘wr
itev’ specified in initializer
/home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2603: warning:
initialization
from incompatible pointer type
make[3]: *** [/home/tapas/source/build_stuff/fusd/kfusd/kfusd.o] Error 1
make[2]: *** [_module_/home/tapas/source/build_stuff/fusd/kfusd] Error 2
make[2]: Leaving directory `/usr/src/linux-headers-2.6.22-11-generic'
make[1]: *** [default] Error 2
make[1]: Leaving directory `/home/tapas/source/build_stuff/fusd/kfusd'
make: *** [default] Error 2
[3] http://fort.xdas.com/~kor/oss2jack/
--
Palimm Palimm!
http://tapas.affenbande.org
On Saturday 29 September 2007, Florian Schmidt wrote:
> Hi,
>
> I'm trying to build FUSD [1] against current kernels [2.6.22]. I get errors
> [2]:
Oh i forgot to show the code snippets in question. I put them to the
crresponding error below [matching line number is marked with [*]]:
>
> [2] ~/source/build_stuff/fusd$ make
> make -C libfusd
> make[1]: Entering directory `/home/tapas/source/build_stuff/fusd/libfusd'
> make[1]: Nothing to be done for `default'.
> make[1]: Leaving directory `/home/tapas/source/build_stuff/fusd/libfusd'
> make -C kfusd
> make[1]: Entering directory `/home/tapas/source/build_stuff/fusd/kfusd'
> make -C /lib/modules/2.6.22-11-generic/build
> SUBDIRS=/home/tapas/source/build_st
> uff/fusd/kfusd
> EXTRA_CFLAGS=-I/home/tapas/source/build_stuff/fusd/kfusd/../inclu
> de modules
> make[2]: Entering directory `/usr/src/linux-headers-2.6.22-11-generic'
> CC [M] /home/tapas/source/build_stuff/fusd/kfusd/kfusd.o
> /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c: In function ‘to_kobj’:
> /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:135: error: dereferencing
> poin
> ter to incomplete type
static inline struct kobject * to_kobj(struct dentry * dentry)
{
struct sysfs_dirent * sd = dentry->d_fsdata;
if(sd)
return ((struct kobject *) sd->s_element); [*]
else
return NULL;
}
> /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c: In
> function ‘fusd_register_de
> vice’:
> /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2049: error: ‘struct
> kset’ has
> no member named ‘kset’
[...]
if(classdir2){
// jackpot. extract the class.
struct kobject *ko = to_kobj(classdir2);
sys_class = (ko?to_class(ko):NULL); [*]
if(!sys_class)
RDEBUG(2, "WARNING: sysfs entry for %s has no kobject!
\n",register_msg.clazz);
}
[...]
> /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2049: warning: type
> defaults t
> o ‘int’ in declaration of ‘__mptr’
> /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2049: warning:
> initialization
>
> >from incompatible pointer type
>
> /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2049: error: ‘struct
> kset’ has
> no member named ‘kset’
> /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c: At top level:
> /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2603: error: unknown
> field ‘wr
> itev’ specified in initializer
STATIC struct file_operations fusd_fops = {
owner: THIS_MODULE,
open: fusd_open,
read: fusd_read,
write: fusd_write,
writev: fusd_writev, [*]
release: fusd_release,
poll: fusd_poll,
};
> /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2603: warning:
> initialization
>
> >from incompatible pointer type
>
> make[3]: *** [/home/tapas/source/build_stuff/fusd/kfusd/kfusd.o] Error 1
> make[2]: *** [_module_/home/tapas/source/build_stuff/fusd/kfusd] Error 2
> make[2]: Leaving directory `/usr/src/linux-headers-2.6.22-11-generic'
> make[1]: *** [default] Error 2
> make[1]: Leaving directory `/home/tapas/source/build_stuff/fusd/kfusd'
> make: *** [default] Error 2
>
> [3] http://fort.xdas.com/~kor/oss2jack/
--
Palimm Palimm!
http://tapas.affenbande.org
On Saturday 29 September 2007, Florian Schmidt wrote:
> On Saturday 29 September 2007, Florian Schmidt wrote:
> > Hi,
> >
> > I'm trying to build FUSD [1] against current kernels [2.6.22]. I get
> > errors [2]:
>
> Oh i forgot to show the code snippets in question. I put them to the
Oh and i also forget to mention that i get the same errors when using:
KDIR=/usr/src/linux-source-2.6.22/ make
[Where the ubuntu kernel package put the source. I configured it with the
default ubuntu .config and make oldconfig]. I get one more message though:
~/source/build_stuff/fusd/kfusd$ KDIR=/usr/src/linux-source-2.6.22/ make
make -C /usr/src/linux-source-2.6.22/
SUBDIRS=/home/tapas/source/build_stuff/fusd/kfusd
EXTRA_CFLAGS=-I/home/tapas/source/build_stuff/fusd/kfusd/../include modules
make[1]: Entering directory `/usr/src/linux-source-2.6.22'
WARNING: Symbol version dump /usr/src/linux-source-2.6.22/Module.symvers
is missing; modules will have no dependencies and modversions.
CC [M] /home/tapas/source/build_stuff/fusd/kfusd/kfusd.o
/home/tapas/source/build_stuff/fusd/kfusd/kfusd.c: In function ‘to_kobj’:
/home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:135: error: dereferencing
pointer to incomplete type
[...]
Regards,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
On Sat, Sep 29, 2007 at 06:37:51PM +0200, Florian Schmidt wrote:
> On Saturday 29 September 2007, Florian Schmidt wrote:
> > On Saturday 29 September 2007, Florian Schmidt wrote:
> > > Hi,
> > >
> > > I'm trying to build FUSD [1] against current kernels [2.6.22]. I get
> > > errors [2]:
> >
> > Oh i forgot to show the code snippets in question. I put them to the
>
> Oh and i also forget to mention that i get the same errors when using:
>
> KDIR=/usr/src/linux-source-2.6.22/ make
>
> [Where the ubuntu kernel package put the source. I configured it with the
> default ubuntu .config and make oldconfig]. I get one more message though:
>
> ~/source/build_stuff/fusd/kfusd$ KDIR=/usr/src/linux-source-2.6.22/ make
> make -C /usr/src/linux-source-2.6.22/
> SUBDIRS=/home/tapas/source/build_stuff/fusd/kfusd
> EXTRA_CFLAGS=-I/home/tapas/source/build_stuff/fusd/kfusd/../include modules
> make[1]: Entering directory `/usr/src/linux-source-2.6.22'
>
> WARNING: Symbol version dump /usr/src/linux-source-2.6.22/Module.symvers
> is missing; modules will have no dependencies and modversions.
This is because you build using a kernel with a non-complete build.
Maybe ubuntu locate output files somewhere else?
If thats the case use:
export KBUILD_OUTPUT=dir
make
to tell kbuild where to find the output files for the kernel source.
Sam
On 9/29/07, Florian Schmidt <[email protected]> wrote:
> My goal is to hack up oss2jack [3] to use ALSA pcm devices.. And a later goal
> is to create a virtual ALSA soundcard [which would multiplex access to a real
> non hw-mixing capable soundcard] to finally end the dmix software mixing woes
> linux users have to endure for the last years :)
What problems with ALSA's userspace mixing are you trying to solve?
Lee
On Sunday 30 September 2007, Lee Revell wrote:
> On 9/29/07, Florian Schmidt <[email protected]> wrote:
> > My goal is to hack up oss2jack [3] to use ALSA pcm devices.. And a later
> > goal is to create a virtual ALSA soundcard [which would multiplex access
> > to a real non hw-mixing capable soundcard] to finally end the dmix
> > software mixing woes linux users have to endure for the last years :)
>
> What problems with ALSA's userspace mixing are you trying to solve?
I think that for example the aoss approach to providing software mixing to OSS
apps is fundamentally flawed. The LD_PRELOAD_LIBRARY mechanism does not work
for all applications. The OSS emultion in ALSA that does work for pretty much
all OSS apps is the kernel level OSS emulation [which directly provides the
OSS conform device files] sitting directly on an ALSA device driver module.
Having a virtual ALSA soundcard which would route back to userspace one could
make the OSS emu use this device instead providing to-userspace routing of
all OSS apps..
The same argument, though in a weaker form holds for badly coded ALSA apps
which open soundcards "directly" via "hw:0" pcm device names. It would be
cool, if these could be made to play nice trivially. Here again, a virtual
ALSA device which routes back to userspace would be great..
Simply make the virtual device card 0 in the system..
Dmix wouldn't be obsoleted by this at all. I'm not sure on the details (still
learning), but the virtual ALSA device routing the signal back to user space
could then in turn use dmix on a real alsa device to provide the sw mixing
(it would indeed be a very thin userspace driver as it basically directly
uses an ALSA pcm as "slave")..
This is not thought of as a replacement for ALSA userspace libasound2.. Not at
all. It's just a cool thing to have (tm) in many situations, solving these
cases which drive some ALSA users (me included) nuts :)
Regards,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
On Sunday 30 September 2007, Florian Schmidt wrote:
> On Sunday 30 September 2007, Lee Revell wrote:
> > On 9/29/07, Florian Schmidt <[email protected]> wrote:
> > > My goal is to hack up oss2jack [3] to use ALSA pcm devices.. And a
> > > later goal is to create a virtual ALSA soundcard [which would multiplex
> > > access to a real non hw-mixing capable soundcard] to finally end the
> > > dmix software mixing woes linux users have to endure for the last years
> > > :)
> >
> > What problems with ALSA's userspace mixing are you trying to solve?
[snip]
Thinking about it some more i think the plan isn't quite as simple to
implement as i thought..
Some more work would have to be done than to simply provide the device file
infrastructure of an ALSA device driver.. Well, right now, i'm happy enough
to have oss2jack and kfusd built and running..
Regards,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org