[PlanetCCRMA] kernel config file - building only 1394 drivers

[Mark Knecht]

> -----Original Message-----
> From: planetccrma-admin@ccrma.Stanford.EDU
> [mailto:planetccrma-admin@ccrma.Stanford.EDU]On Behalf Of Fernando Pablo
> Lopez-Lezcano
>
> Same here, I tried an ieee1394 enclosure for my old laptop drive and it
> did not work. I could get to the filesystem (fdisk, for example), I
> could even mount it, but any amount of accessing would eventually
> produce i/o errors (at the ieee1394 transport layer, I believe). I
> shelved it waiting for new drivers. So I would be interested in solving
> this as well.
>
> > You can't even talk to
> > the developers (I've been part of Linux 1394 development for 3 1/2
> > years) unless you have the latest drivers.
>
> Latest means 2.4.20? Or newer? Do you have pointers to the code?
>

No, 1394 drivers, not kernel. Sorry for my being too general.

The 1394 driver CVS (actually Subversion System, not CVS) is updated quite
often. If you were willing to make a new 'kernel RPM', then all we need to
do is:

1) Download the drivers from their Subversion server
2) Replace the driver code shipped with the 2.4.19 kernel with this
downloaded code. There is a ieee1394 directory in the source code tree. You
just erase what's in there and replace it with this stuff.
3) Build kernel and RPMs

I've done this many times, but I do not want to do it with this music stuff
since I would need to duplicate every feature you've done. Too much work!


> If new means 2.4.20 I do have some 2.4.20 kernels I've been working on.
> I have not released them because jack and friends were hanging the
> machine, but now it would seem the problem is in jack itself and also
> happens (less frequently?) in 2.4.19. You could try them out if 2.4.20
> is enough. Come to think of it, I may try them tomorrow with the
> enclosure if I can find the time.

I think we should keep 2.4.19 and 2.4.20 around until this Jack problem is
debugged. It may be important to have both kernels.

>
> >    Actually, all I'd like to compile is the drivers themselves, but the
> > guys on the 1394 developers reflector don't know how to do that, so they
> > are telling me I have to redo the whole kernel. I hate this idea as it
> > would potentially make me incompatible with what you are providing.
>
> Hmm, good question (on how to do that). If it is a driver that is _not_
> part of the kernel rpm then it is relatively easy. Just create another
> rpm that includes only the new driver and install it in addition to the
> kernel (that is what actually happens with alsa). Now, if the driver is
> already part of the kernel and/or the driver is part of other kernel
> subsystems then things are not so easy because you have to replace the
> driver. If you want to do this within the framework of rpm and keep
> everything compatible and undoable things get complicated. I've done it
> while testing some kernel drivers for a Radeon card but it is not
> pretty.

And I'm not a software guy, so guess what it looks like to me!

Actually, one of the 1394 developers says he thinks he has an idea how to do
this and wants me to get the configuration file for our kernel. That's where
this thread started. If I take you instructions for building a kernel rpm,
download everything, and get the kernel config file, then maybe his idea
will get this done for us. After all, they have a vested interest in making
it easier to put in new 1394 drivers.

Heck, all of Linux has a vested interest in making this easier.

>
> >    I _think_ where they're going to suggest this goes is that I build
> > the kernel using your config file but with new driver code, and then
> > copy just the new drivers somewhere. Even that bothers me.
>
> Yeah, that would probably the easy way out. Rebuild the kernel but do
> not install it, just copy the relevant binary driver files on top of the
> existing files that are part of the installed kernel rpm.
>
> Another option is brew your own kernel with all the patches you want and
> install it alongside the planet ccrma kernel. As you say, it is a waste
> of time and not so easy (the first time around, of course).
>
> -- Fernando
>
>
> _______________________________________________
> PlanetCCRMA mailing list
> PlanetCCRMA@ccrma.stanford.edu
> http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma
>
>