> So you want to write a xif network driver that use the SCSI interface as > transport medium. > exactly. > At the moment the scsidrv functions are not available through the > kernel interface. But as fallback you can directly call GEMDOS 0x15f > (sys_emulation) with the first argument set to 2 (just take a look into > sys_emu.c [which is GEMDOS 0x15f] and scsidrv.c). It's maybe also a good > idea to add the scsidrv functions to the kernel interface. > hm, this is something new to me, I'll try it someday, for sure. anyway, i attach that driver + diff for some more or less important changes in the source tree. it should be compilable, just replace freemint-mikro with freemint, copy to existing source tree + apply patch. about that device, it's SCSI adapter for ethernet connection made originally for Macs but thanks to Roger Burrows we've a chance to use it, too. Roger was so kind he gaves me a permission to include it to freemint under GPL so anyone can use/improve it. Originally it was written in LatticeC + MagiCNet so I remade it under freemint as close as possible. in this way i take a chance to ask some questions: - in bootmenu.c there's commented out storing current debug level into ini file. is there some reason for it? - in the driver code I check some cookies. for some strange reason I couldn't use get_toscookie from kernel but s_system (GET_COOKIE blah blah). I've got a feeling that get_toscookie even isn't called and returns 1 (cookie not found) everytime (I tested it with MiNT cookie which is present for sure in freemint boot :). Is this normal? (i.e. is there some reason why I shouldn't call kernel api function in XIF? But as far as I know kmalloc is called in the same way and it works..) - how to make/send patches in so called 'offline way'? That means I'm at PC, cvs checkout freemint source, copy to falcon, make some changes, I'm back at PC and -- can I safely made diff -r -u freemint freemint-mikro and send an output? With all that garbage left? (.dep, CVSROOT, ...) I noticed make distclean from ./freemint doesn't erase everything and there are still that cvs-dependent files. - how to enable DEBUG, TRACE in xfs/xdd/xif modules? In kernel it works via -DDEBUG_INFO but with this config I still see nothing via XIF's DEBUG(). - this isn't a question, just an idea: what do you say for adding functionality for multiple sysdirs? I mean, now we have 1-16-3, 1-17-cur, etc, cool. Now, everytime I change something, I need to copy new XIF module (maybe even new kernel), then reboot, activate debug output + step-by-step tracing, bang, crash, something went wrong, so I have to reboot, disable debug output + tracing (or opposite -- everytime I have to enable it and choose not to save ini file), disable that bad XIF, load system, change some source, copy new kernel/module, reboot, activate tracing and XIF etc... it's very frustrating and boring. My idea is mint.prg will scan current sysdir -- let's say 1-17-cur. But instead of using this it will look also for 1-17-cur.1, 1-17-cur.2, ... and then shows some menu (similar like bootmenu.c) and user can choose desired config. One config could be with debug info and tracing, another just normal boot with working kernel modules. So user could just replace bad XIF then and choose the new configuration from menu after reboot. This could go even further and we could use some loader -- let's say mintboot.prg which will scan current sysdir and give us a possibility to load even independent kernels -- normal GEM bootmanager will just select the main version of kernel/loader then and user will have a possibility to add any configurations he likes with the present kernel. There's a lot of options how/what to do but all at all I think it could help everyone. -- MiKRO / Mystic Bytes http://mikro.atari.org
Attachment:
daynaport.tar.gz
Description: application/tgz
Attachment:
diff.gz
Description: GNU Zip compressed data