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- <olafbuddenha...@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 :)