Re: Interface for SCSI transactions ?

[Thomas Schmitt]

Hi,

[Sorry, a wrong option with the mail sender client ate up the
 reply and subject headers. So once again hopefully in the right
 mail thread:]

i wrote months ago:
> > I plan to revisit the CD-on-Hurd topic when i'm done with CD-TEXT.
> > I could still need a tutor then, who leads me through the development
> > cycle of Hurd,

Svante Signell wrote:
> Are you finished with the CD-TEXT stuff by now? More hands would be
> appreciated. I hope the tutors would be the people helping you out
> previously, mainly Samuel and Olaf.

Yes. CD-TEXT is done. HFS+ too (contributed mainly by Vladimir
Serbinenko). My new long-term sub-project is HFS (without +) for
Debian powerpc architecture, so that Debian can give up genisoimage
for the production of its installation ISO images.

I got a motivation problem with Hurd SCSI for CD/DVD/BD:
- No user wants it.
- I have to dig deep in Mach code which is probably prone to
  getting replaced by newer device driver code for SCSI and ATAPI.
- I do not know how to get a real DVD drive attached to a virtual
  Hurd on a modern computer. (I could try to revive some computer
  scrap with half-dead IDE drives. But its noise alone ... urgh.)
  See http://libburnia-project.org/wiki/QemuXorriso for what i
  would have to achieve with Mach and Hurd on qemu.
- I do not feel apt for kernel hacking. I had to do some diagnostic
  work in a virtual Linux recently. Just a few kprintf() and
  a lot of make-and-run, until i found out why HFS+ with APM
  block size 2048 cannot be mounted. (Hardcoded size 512.)
  This was an awful development cycle with no debugger and
  with rebooting before each experiment. 
  

> How much is UDF used nowadays?

In its sequential form together with ISO 9660 (which i would
strive for): Only for old DVD video players which demand a
particular directory structure and file name layout.
I would deem it a bit more popular than Hurd, but not very much.
It is more about completeness in emulating mkisofs resp. genisoimage.

For read-write UDF on overwritable media types, one can use
on Linux mkudffs. (Random read-write and optical media do not
play well together, nevertheless.)

Debian-cd production is waiting for HFS, after HFS+ failed to
boot on qemu for PowerPC. (HFS+ is reported to work well with 
Vladimir's Power Mac. But it is impossible for me to get tests
on IBMs.)


> The network drivers are now using DDE and probably SATA soon (Samuel?).
> So maybe DDE would be a way forward also for SCSI. 

Being subscribed to bug-hurd and to debian-hurd, i am carefully
watching for success messages.

My hope is to get something like Linux ioctl(SG_IO) that way.
Or at least tutorship from somebody who has fresh knowledge about
the newly implemented driver code.

I am ready to join an effort to implement SG_IO or alike.
Preferrably not as kernel programmer but as tester and advisor
about the needs of burn programs.

In any case Hurd would need a new Mach RPC which performs the
SCSI/MMC transactions. I sketched potential layouts and they were
discussed. But such a decision is not up to me (unless i can show
a fully working implementation of a MMC transaction driver).

Further, there are other departments of SCSI, which might also
need to be served.
Linux SG_IO and FreeBSD CAM offer broader solutions than my
last sketch. But they would need a giant RPC parameter list and thus
would have to be implemented broadly enough in Mach in order to
justify that RPC.

"SCSI" here means the command model, not the bus technology.
Optical drives at SCSI, ATAPI, SATA, USB busses all have the
same commands and transaction model.
So my desired interface to "SCSI" would unify all these bus
variations at the level of Hurd and RPC. (The same happens in
Linux and FreeBSD.)
Inside Mach it would have to branch for each of the bus types,
of which i could spot last year only ATAPI and SCSI.


Have a nice day :)

Thomas