22 Jan
2007
22 Jan
'07
11:22 a.m.
der Mouse wrote:
Yes. If you have a 2048-byte-sector disk and can convince the cd
driver to attach to it instead of the sd driver, it might work. :-)
Hmm, I'm not quite sure what you're getting at there - but I've never had any
problems whatsoever with Linux's SCSI CDROM / DVD-ROM support. I've never
poked deeply enough in the code though to see what's going on behind the scenes.
From what Brad said and what I found in sd.c, it looks like disks at least
support powers-of-2 raw sector sizes between 256 and 4096 bytes; any problems
dealing with those drives are either down to SCSI incompatibilities (SASI
devices and/or not-quite-complete device firmware support), incorrect setup
(device needs some vendor-specific voodoo to work), or in trying to impose a
filesystem on the device which is expecting a specific block size.
Last time I looked, NetBSD, at least, couldn't do
anything sensible
with a SCSI disk with other than 512-byte blocks. That was quite a
while ago, but I haven't heard anything on the lists to make me
think the status has changed.
The thing that got me wondering though - surely in
the PC world, SCSI
CDROM drives all use something like 2048-byte blocks? The suggestion of using whatever generic SCSI
facilities are available
strikes me as a good one. If I had the time and interest I'd hack
something together myself to do that.
Using Linux's sg interface to throw raw SCSI commands around is easy enough; I
wrote a userspace driver to do some data archival via a SCSI floppy controller
not so long ago.
However, the problem is that for old devices, they often not quite
SCSI-compliant which upsets the HBA drivers themselves; Linux chokes on
anything that doesn't support Inquiry, for instance - which results in the
kernel not giving you a sg device handle to work with for such a device. It
would seem that (from Al's example) the Mac is perhaps a bit better, in that
you can throw a command at any SCSI device on the bus whether the OS thinks
there's one there or not.
To get oddball SCSI devices going, what's almost needed is a way of
intercepting the kernel boot process such that the user can send a few
vendor-specific setup commands, fake Inquiry data etc. between HBA driver load
and subsequent kernel querying of attached devices. One the kernel thinks
there's a valid device there it'll give you a sg handle to it and you can do
whatever you like. As I recall that's how the Linux OMTI bridge drivers worked
(they were before the days of sg, but allowed the board to appear as a two-LUN
disk device to the HBA driver), but unfortunately the kernel's changed beyond
all recognition since those patches were current.
There is of course the additional problem that a lot of vintage equipment's
actually SASI rather than SCSI, and Linux HBA drivers probably won't cope with
that (even if there's just the HBA and SASI device on the bus). I haven't
tried though because it's a lost cause without some way of faking Inquiry data
anyway :-)
What I'd really like I suppose is a user-space driver for a widget that
provided SCSI and SASI support via a *totally* dumb HBA (i.e. polled I/O and
twiddling of bus lines "directly") - in other words, one step less intelligent
still than most "dumb" HBAs (which still use some sort of SCSI IC). It'd be
slow as molasses, but speed isn't the critical factor compared to flexibility
and ease of driving.
Unfortunately a PC parallel port doesn't quite have enough I/O lines, I
wouldn't have a clue how to make a USB solution (ick!), and building an ISA
card (say) would require kernel drivers (and all the complexity involved
there). One possibility is just to use two parallel ports, but that severely
limits the portability of the device - although I'm getting to the point where
that's preferable to not having any solution at all.
cheers
Jules