Re: [address@hidden: Interface for SCSI transactions ?]

[Thomas Schmitt]

Hi,

Thanks to all for your patience with my newbieness.

me:
> > So it looks as if we have to stop here until a better skilled person
> > appears who is interested in enabling burner drive operation.
Samuel Thibault:
> I'll let it to anybody who has time for this.

After pondering and code reading about your proposal via device_get_status()
without new RPC, it appears viable enough for a try.

A potential problem is that scsi_ioctl_send_command() is restricted
to transfer MAX_BUF = PAGE_SIZE payload bytes.
I could not spot the definition of PAGE_SIZE yet.

I'd need at least 32 kiB payload. Better for Blu-ray would be 64 kiB.
(Proper alignment matters. Older cdrecord sends 62 kB per call and
 has problems with many DVD and Blu-ray burners.)

In scsi_ioctl.c:scsi_ioctl_send_command i read:
     * We do not transfer more than MAX_BUF with this interface.
     * If the user needs to transfer more data than this, they
     * should use scsi_generics instead.

I am unable to determine whether this limit also applies to scsi_do_cmd()
in hurd/gnumach/linux/src/drivers/scsi/scsi.c  which seems to do the
transaction work.

Is there a limit for the number of integers with device_get_status() ?
(I'd need at least 32 kiB payload plus about 1 kB of other stuff.
 Better would be 65 kiB.)


-antrik- <olafBuddenhagen@gmx.net>:
> I'm certainly willing to mentor
> you on the Hurd-specific aspects as well as I can; but I won't promise
> anything more...

A sketch how to set up an own Hurd development with access to a
real CD drive and remote login via real Ethernet would be very welcome.
Just enough detail to estimate the effort.

An interested user who really wants to burn CD, DVD, or BD, would be
an extra motivation. :))


antrik:
> I'm sure you do have the necessary skills -- the question is rather
> whether you are willing to spend considerable time digging into Hurd
> internals :-)

There would be quite some learning involved.
I am a userland programmer who stumbled into libburn and its SCSI
interface only by accident.

Meanwhile this accident evolved and i have a test machine with FreeBSD,
Solaris, and Debian 5. It has a single disk where i could use partition 2
with 50 GB for a real Hurd. But from lurking here i got the impression
that you all use it on virtual machines, rather than on real amd64 + SATA
+ USB + Ethernet.

Being nearly as few of a sysadmin as i am device driver developer, i would
first have to learn about running VM on Linux. Then somebody or some
documentation would have to drag me through learning the development cycle
of Hurd.
(Plus the overdue housework to upgrade from Debian 5 to 6 which would
 affect my GRUB-legacy boot contraption that lives in Debian 5.)


me:
> > I am open for cooperation and also for doing some slave work.
antrik:
> Not sure what you mean by "slave work"?

The slave work would be to implement structures and methods on both
sides of the RPC interface. I could contribute SCSI knowledge (command
set, not hardware) and believe to have identified existing code on
the "kernel" side of RPC which already performs the needed SCSI
transaction.

Meanwhile i believe to understand Samuel's proposal for a quick hack.

If PAGE_SIZE is not a show stopper, then one could attach 
  scsi_ioctl(SCSI_IOCTL_SEND_COMMAND, ...)
from
  gnumach/linux/src/drivers/scsi/scsi_ioctl.c
to the kernel side of device_get_status().
I understand from the comments in scsi_ioctl.c that this is a predecessor
of the Linux SG_IO interface (Linux kernel >= 2.4).

I still have to explore how to beef up the userland side of
device_get_status().

And at some point i would have to get from theory to practice.
 

Have a nice day :)