Hi, Samuel Thibault wrote: > AIUI it's device_get_status() in linux/dev/glue/block.c for the linux > IDE & SCSI devices.
Yeah. That is my favorite candidate among the files in my CVS copy. But i was uncertain to which side of the RPC gap this belongs, because i could not spot a function device_get_status() outside toplevel directory gnumach. (Where is the RPC stub of the function ? Where does dev_status_t get transmitted ? ...) My next planned topic to learn is to get an overview about the relation of libburn's userspace, kernel and servers: I now assume linux/dev/glue/block.c is executed in a translator. But which one ? (What is the model relation of server and translator ?) > However, I realize that the status parameter of the device_get_status > RPC is out only, not inout, so device_get_status alone can not provide > complete support. Ouch. > One way would be to use a set/get pair. This would mean to send the SCSI command and possible payload data by device_set_status() and to buffer the reply until device_get_status() is called to fetch it. The reply would consist of 18 to 252 bytes of Sense Data (e.g. error reply) and as much payload as gnumach/linux/src/drivers/scsi/scsi_ioctl.c:scsi_ioctl_send_command() would be willing to transact in its parameter "buffer". (MAX_BUF ? Wasn't there some bad news with MAX_BUF being smaller than 32 kB, the natural transaction size for DVD ?) This reply buffering would have to happen individually for each struct block_data that may be handed to scsi_ioctl_send_command() as parameter "void *d".i Is there a suitably persistent relation between instances of struct block_data and the instance of device_t device in userspace ? > Another way > would be to define a new device_command RPC, and extend the > device_emulation_ops structure with it. Currently it seems appealing to have one that calls quite directly scsi_ioctl_send_command() . (I hope that would fulfill my wishes. Assuming that the appropriate translators use this call for their SCSI transactions, too.) ------------------------------------------------------------------------- (About development cycle:) > > Even if i had a detailed plan of what to code where, i still lack of > > an idea how the development cycle for a kernel change would look like. > Simply rebuild gnumach and reboot with it. What files in the Hurd image should i backup and be ready to re-install after i made it unbootable ? ------------------------------------------------------------------------- (My ssh botching:) > > Except i cannot find out why logging in from the hosting system by > > ssh -p5555 localhost > > demands a password. > Maybe check the permissions on $HOME, > $HOME/.ssh and $HOME/.ssh/authorized_keys. Indeed i forgot to apply chmod go-rwx to ~/.ssh after creating it. Now it works. ------------------------------------------------------------------------- Have a nice day :) Thomas
