SCSISoftUSB and device access sharing

Hi,

I am still working (quite successfully, after finding a bug qhich would qualify as “most stupid bug ever” last night after staring 3 hours at a short piece of code and compiling hundreds of variants) on USB support for CD/DVD devices. Now I am wondering about “philosophical” details I have encountered during my efforts.

The current version of SCSISoftUSB “claims” all mass storage devices it thinks it supports, no matter if this is true or not. I.E. it opens the available USB endpoints via DeviceFS as “files”. This means that it blocks everyone else from direct access.

Usually, in RISC OS SCSI and ATAPI world, the devices are “shared” between all interested parties (SCSI has a reservation system in theory, but AFAIK this is not really used), so everyone can send commands to devices.

If you have something like a mounted harddisc, i.e. something under control of a piece of software that not only needs to worry about the physical layer, but also keeping its logical workings in order, it is obvious that you don’t like the idea of concurrent access, at least write access. But what about a CD-ROM?

Do we need a proper “device claim protocol”? Or do we need a central “device manager” that coordinates read/write accesses? But what is the short-term solution? Change SCSISoftUSB to not claim devices it does not really understand? Use the already existing filehandles that SCSISoftUSB has created? Seems extremely nasty to me…

Does anyone know how this is handled on other OSes?

Steffen

Steffen, I can’t see what any ordinary user would gain by accessing a CD-ROM device directly. It would be accessed via a filing system. The only people who would need direct access are… well, you, really:-) Someone who is developing the access method.

A “device claim” protocol would be a formally neat way of doing it, but you could look at it from the opposite direction: who or what would attempt to access the device directly? The only thing I can see under normal conditions is the filing system for the device concerned.

As for claiming things it doesn’t really understand: yes, this is a problem that needs solving. We already see it in RISC OS where HIDs are claimed by some component of the OS, even though it can’t understand them or do anything with them. It’s a real pain, and it prevents most of the USB toys that I developed drivers for from working on the A9home. So the next layer must be really sure that it can handle a device before grabbing it.

I think that fixing SCSISoftUSB so that it doesn’t claim devices which it doesn’t understand is a good idea.

Can you give an example of where/how the SCSI/ATAPI sharing system is used? I’m not too sure what you’re talking about there.

Hi Dave,

no, the ordinary user will certainly not start developing software sending low-level stuff to arbitrary devices ;-)

However, there are many situations where simple, user-run applications would need such direct access. Think about software that samples audio tracks from CD. Software that retrieves SMART information from harddiscs. Software that manipulates harddisc speed and sound settings. And of course software that understands Fat32 structures like ROFS ;-)

As for claiming exclusive device use: I think Windows uses a system where there is a “driver hierarchy” that is trying to match devices to drivers. You can register specific drivers for specific devices (e.g. via device/vendor ID) which are used in preference to generic drivers. I think it would be nice if the user would have control over which device is controlled by which driver software.

On the other hand, RISC OS never had any kind of security concept, so access free to whoever wants it is probably still the way to go.

Hi Jeffrey,

I guess my post was a bit confusing. Sorry for that. The “sharing” system I referred to is just the “free access for all” access model. An exception are SCSI harddiscs which (sometimes – I think Acorns SCSIDriver enforces it, but 3rd party SCSI podules usually do not) must be reserved via the SCSI_Reserve Claim/ForceClaim calls.

In the tradition of the old “everyone can send commands to devices” method, I have now implemented a “steal the filehandle” scheme that just scans for the open devices# “files” and reuses this filehandle in CDVDBurn. Seems to work, and SCSIFS seems to be able to cope – after all, it does not touch those CD-like devices anyway.

In the long run, I am still intending to fix SCSISoftUSB to just correctly support those devices.