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

[Thomas Schmitt]

Hi,

(Shall i stop CC'ing help-hurd ?)


> > So i would rather propose a new function with the semantics of SG_IO:
>
> A completely hurdish interface for this would probably be the best, yes.
> You'll have to learn mig, however :)

Well, the SG_IO-ish wrapper around scsi_do_cmd() would be a matter of
defining a struct resp. type and of adding a function to the device_*()
family which does transactions in the same device specific way as
device_get/set_status() does for devices status issues.
The SG_IO-ish aspect would apply to all devices which implement the SCSI
transaction model. (I have not much clue of other device models.)
The hypothetical function would have to check whether the device can be
approached by scsi_do_cmd().


I understand the recent statements about the reason behind Hurd
in a way that a hurdish interface should foremost provide a better
or at least novel approach to doing things.
So before i explore MIG in detail, we should think about why Linux
has neither a ISO 9660 filesystem write driver, nor a MMC burn driver.

-------------------------------------------------------------------

The procedure of burning sequential MMC media does not fit well into
the model of seekable and non-seekable device. It is characterized
by the concept of a session, which is a kind of super transaction:
  Preparation, stream writing, post-production.

The other family of MMC media fits well into the classical device model.
Overwriteables are just like poorly performing hard disks.
But they work best under the conditions of effectively stream writing.
Defect Management brings more problems than it solves. With DVD-RAM
and BD alike.

So it seems worthwhile to offer for both families a media model which
represents writing of a streamed session. (Despite reading of all types
and random-access writing of half of the types is already covered by
the hard disk model.)

-------------------------------------------------------------------

ISO 9660 is designed for write-once/read-many media. Nearly all such
media offer the opportunity to keep them appendable, i.e. ready for
later writing another session.
Write-once (= MMC sequential) media will prescribe the block address
for the start of the next session. Therefore the producer of an add-on
session has to inquire this start address for preparing proper
address pointer offsets.

This yields a peculiar filesystem dual usage model:
- Read-only in classical random-access.
- Write-only by base session and add-on sessions.
  This one does not fit well the virtual filesystem model.
One may not mix both usage models because of potential restrictions
imposed by the write-once media.

So it is quite inavoidable to keep the whole directory tree and
file attributes in memory while creating an ISO 9660 session.
Sounds evil, but consider that my home backup with 55,000 files needs
just 35 MB on amd64 for that. Currently the cheapest new desktop
machines come with 4 GB.

About any storage facility fits into the ISO 9660 multi-session model.
On write-many seekable media (= MMC overwriteables, disk files,
USB sticks, ...) it is possible to point reader programs (i.e. mount)
to the start of the newest appended session. One may choose an
arbitrary start block after the end of the previous session.

Use cases for ISO 9660:
- One-way data exchange with about any operating system.
- Time vault like backup system if one is able to mount ISO 9660 from a
  particular block offset. (Linux: mount -o sbsector=number).
- Hurd reproducing itself as bootable ISO images (ISOLINUX or GRUB,
  CD, DVD, BD, USB stick, ...).

-------------------------------------------------------------------

xorriso is my implementation of these generalized models of streamwriting
oriented media and filesystem.
It encapsulates most of the media peculiarities and the task of coordinating
image tree loading and session writing.

Its own usage model is command-and-reply. Like a shell script or dialog
session. Seems to fit nicely into
  http://www.gnu.org/software/hurd/microkernel/mach/mig.html
(Am i too stupid to see the links to tutorials and manuals ?)

Only that xorriso is *fat*. At least for an OS driver candidate.
I would not dare to propose it to any of the usual kernel communities.

So what is Hurd's attitude towards a driver that occupies 2.5 MB
of memory when idle and might expand much more on the job ?
Is it worth to continue thinking about xorriso-in-the-system ?


Is the concept novel enough to integrate a GNU command line dialog
application into the operatings system for acting as one or two drivers ?

(We could wait until april 1st of next year with the announcement) 


Have a nice day :)

Thomas