On Sun, Feb 24, 2002 at 11:26:55AM -0500, B. Douglas Hilton wrote: > Hi thanks for the informative reply. I worked on it most of the > day yesterday but didn't make any noticable progress other than > learning what doesn't work. No problem, the mailinglists are for asking quesitions. It's now documented however. :) > I'm thinking about ripping a bunch of the drivers out of oskit just > so I can compile it faster for development purposes. Make like a > lean & mean version of oskit which is more suited to Hurd in > particular, and my pc to be specific, than all os's in general. I don't know if it's possible to include only specific drivers. I know Roland wrote some code for that, but the last time I tried it didn't work. You should really look at the init-%.c target and related things in the Makefile. > Jeroen Dekkers wrote: > > >Okay, cross-compiling isn't only not needed, it's also prone to > >mistakes. Just use your general i386 compiler (probably > >i386-pc-linux-gnu) etc. That should work. > > > Ok, then I guess just install in /usr/local like the default. Can do. Yes, that would be fine. > >The problem is your cross-compile setup doesn't have glibc. The string > >functions come from glibc, as those are better optimized than the one > >from OSKit. The string functions are OS-independent anyway, just like > >the OSKit and OSKit-Mach. They also don't depend on being build by a > >specific system. (However, OSKit-Mach could depend on glibc, gcc, > >etc.) > > > Ah. That sounds reasonable as well. I have done this before; i.e. not > cross-compiling oskit, and then using this to make oskit-mach, but > with the cross compiler. Still didn't work for me, but it got further > along before it crashed. The only problem you could have is that on Debian mig is called i386-gnu-mig. You've to do "MIG=i386-gnu-mig ./configure" then, without cross-compiling. It's all in the guide. > >To say it another time: Just don't cross-compile! Read > >http://www.etherhogz.org/doc/oskit-mach.html for more information > >regarding building those things. The fact that you should not > >cross-compile should have been added to it by the time you read > >this. :) > > > >>How difficult would it be to backport the 2.4.17 driver > >>to OSKit? > >> > >Yes. Linux doesn't have something like a stable interface. It's sad > >the Hurd doesn't have its own drivers. > > > Actually I ripped out oskit's aic7xxx code and replaced it with files > from 2.2.20. Then I cut and pasted a bunch of stuff and moved aic7xxx.h > back into linux/src/drivers/scsi and it in fact compiled, but didn't work > any better than the original oskit driver did. This driver is like 400KB > and appears to be extremely compilicated. It doesn't look good, but I > will keep trying. Hmm, it's easy to make mistakes with the changing Linux interfaces. You could try to debug it using remote gdb, Igor has written something about that, try searching the mailinglist archive and/or google. > You know, I was just looking throught the oskit source right now, and > I happened to notice that there are two implementations of the aic7xxx > driver, one in freebsd/3.x/src/sys/dev/aic7xxx and one in > linux/src/drivers/scsi > > I wonder... You could try the example kernels using the FreeBSD drivers and Linux drivers. If the freebsd one works, we might include that driver in OSKit-Mach. Please CC: the list next time, especially if you are talking about things you are planning to do. We want to avoid double work. Jeroen Dekkers -- Jabber supporter - http://www.jabber.org Jabber ID: jdekkers@jabber.org Debian GNU supporter - http://www.debian.org http://www.gnu.org IRC: jeroen@openprojects
Attachment:
pgphmtydmiBab.pgp
Description: PGP signature