Hi, On Tue, Sep 06, 2011 at 03:56:30PM +0200, Thomas Schmitt wrote: > Samuel Thibault wrote:
> 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 ? ...) The server side is generated during Mach build; the client side is generated during libc build... Not sure which one you mean. > I now assume linux/dev/glue/block.c is executed in a translator. What makes you think so? I'm pretty sure we already said that currently the drivers are in Mach itself -- although we want this to change in the future... > (What is the model relation of server and translator ?) A translator is any (server) process accessible through a node in the filesystem tree. Almost all Hurd servers are translators. Mach also offers a number of in-kernel servers for handling various RPCs -- for example the device server (ds_) for handling device RPCs such as device_get_status(). These are obviously not translators, as Mach doesn't even know what a filesystem is :-) > 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 ? Not sure what you mean here... Are you asking about a possible situation where several requests are in flight simultaneously, i.e. set_status() is invoked again (possibly by another processes) before the corresponding get_status() call is done for the previous one? IIRC the current implementation of the device handling can't handle separate client sessions... So I fear the only way to associate possibly overlappnig set_status()/get_status() pairs would be by explicitly passing some handle... [shudder] Sounds like one more reason for adding a specialised atomic RPC instead :-) > 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.) Not sure what translators you mean here... > > 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 ? None... If you just copy the freshly built "gnumach" binary to /boot, it won't overwrite the default kernel (which uses a different file name), so you can choose which one to boot in GRUB :-) (You can even leave out the copying, and instead boot the kernel directly from the build tree... Though this might be a bit more cumbersome to request in GRUB.) -antrik-
