Hi, 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
