Hi, me: > > [...] my favorite candidate among the files in my CVS copy. Samuel Thibault: > CVS Copy? The CVS repository is outdated. Which documentation advised > you to check it out?
I have to guess a bit. But it looks like http://www.gnu.org/software/hurd/users-guide/using_gnuhurd.html#Helping-Out in its node http://www.gnu.org/software/hurd/users-guide/using_gnuhurd.html#Basic-CVS-Usage shows an example that brought me to "Hurd Hacking Guide" http://www.gnu.org/software/hurd/hacking-guide/hhg.html where http://www.gnu.org/software/hurd/hacking-guide/hhg.html#Requirements says " 4. The sources of Hurd and GNU Mach are also useful: mkdir ~/hurd-cvs cd ~/hurd-cvs/ cvs -d:pserver:anonym...@cvs.savannah.gnu.org:/sources/hurd \ co hurd cvs -d:pserver:anonym...@cvs.savannah.gnu.org:/sources/hurd \ co -r gnumach-1-branch gnumach " > git clone git.savannah.gnu.org:/srv/git/hurd/gnumach.git Will get a new copy. ---------------------------------------------------------------------------- > > [my description of buffer needs of a pair of device_set_status() and > > device_get_status() for a SCSI transaction.] > That advises into defining another RPC. > [...] it looks a bit ugly to me. The idea about device_get_status() was mainly based on the assumption of an existing RPC transport between userspace and kernel. This assumption is not valid any more. Would it be a problem to transport MAX_BUF + 252 bytes through a RPC ? Actually, Blu-Ray works best if fed with 64 kB per WRITE command. The drives i know do not enable full speed streaming mode if the chunks are smaller. Old cdrecord has problems with some DVD drives which it tries to feed with 62 kB per write. So alignment to 32 kB is very desirable for DVD. growisofs and my own stuff do it so. So a large transaction size should be a design goal, although it might work with smaller sizes on many DVD drives and on BD. Even if the kernel is restricted to smaller sizes now, the interface should allow larger ones. Olaf Buddenhagen: > Well, if we need to go for a multi-RPC approach, I'd suggest doing it > *properly*, i.e. using get_status/set_status only for actual control > information, and pass the data with read/write calls. Samuel Thibault: > It'll probably be hard to express the SCSI commands he needs that way. I could imagine a five-step transaction if there is no other way to get a large payload through RPC: 1: Userspace would open the transaction by sending the SCSI command through device_set_status(), 2: pass possible payload data by write(), 3: trigger the actual transaction by another device_set_status(), 4: wait for the end of the transaction in device_get_status() which would return the SCSI Sense Data and the number of reply payload bytes, 5: finally fetch the reply bytes by read() if there are any. A single system call as in Linux, FreeBSD, or Solaris would be preferrable from the userspace programmer's view: ioctl(d->fd, SG_IO, &s); cam_send_ccb(d->cam, ccb); ioctl(d->fd, USCSICMD, &cgc); On the other hand, there is a lot of ugly code surrounding these calls in the libburn system adapters. A five-step would not make it much worse. So the main argument against the five-step is the complexity in the kernel, where fat transaction states would have to be implemented. > > Currently it seems appealing to have one [RPC] that calls quite directly > > scsi_ioctl_send_command() . > That's probably the most correct way. But looks quite out of my personal reach for now. ---------------------------------------------------------------------------- > > [...] i could not spot a function device_get_status() outside > > toplevel directory gnumach. (Where is the RPC stub of the function ? > It's generated from the Mach headers during libc build. Oh. That explains a lot. > > What files in the Hurd image should i backup and be ready to re-install > > after i made it unbootable ? > Just the kernel, since it's only the kernel that you will have to > replace. Now that i know, it seems obvious. :)) To my excuse i can only state that all info about Hurd emphasizes servers and translators. SCSI itself matches this model well. So it did not come to me that the situation is not much different from a Linux kernel (except the quite invisible RPC'ing). I rather expected something like one translator per SCSI bus. ---------------------------------------------------------------------------- Have a nice day :) Thomas
