[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] scsilib

> So you want to write a xif network driver that use the SCSI interface as
> transport medium.

> 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 

MiKRO / Mystic Bytes

Attachment: daynaport.tar.gz
Description: application/tgz

Attachment: diff.gz
Description: GNU Zip compressed data