Re: Linux 1394 somewhat unfriendly during boot?
Brought to you by:
aeb,
bencollins
From: Manfred W. <e95...@st...> - 2000-05-20 16:11:23
|
Mark Knecht wrote: > I think one important point you make is the compile option - kernel vs. > modules. I am compiled into the kernel and that means the loading of the > driver stack is earlier. I could certainly take it out, but I think in the > end it is not practical to have end-user types doing insmod's. I know, > 'cause I'm an in user type and I don't know how to do it!! I think you misunderstood me. I wrote that I also compiled it into the kernel and _not_ into modules. I did this, because I did not want to bother around with that insmod's. But because of the mentioned stablity problems I consider to put it into models and only load them, when I really need them (or to plug off the 1394 cable and only plug in on demand...). But I think, that that makes not much difference, it only affects the timing, when the driver is loaded. > I may make a version of the kernel with module based loading this > weekend. Could you send back the instructions for doing the insmod steps so > that I get it right? I think, you will get two modules, one for the low-level-driver (pciylynx.o or ohci.o or something like that) and one for the higher-level (hardware-independent) subsystem functionality (maybe it's called ieee1394.o?, look into /lib/modules) and you will have to insmod both (I think first the lowlevel-driver, try it!). > I agree that some of the stability problem seems more apparent when I > build larger topologies. I intend to look into this more later. And we also see, that we are still far away from putting it into stable kernel releases (2.2 or 2.4). But as cold comfort: That is also true for the windows drivers; the only difference is, that here (on linux) it is explicitly marked as experimental code, whereas MS claims that they have stable code and sells beta-software as final releases... Manfred |