Re: [PATCH gnumach] Do not take unused strpbrk() from libc
Guillem Jover, le Fri 09 Sep 2011 03:44:09 +0200, a écrit : > * Makefile.am (clib_routines): Remove strpbrk. Applied, thanks. Samuel
Re: Interface for SCSI transactions ?
Hi, > It's actually very simple to define an RPC, it essentially looks > like a C function declaration, see ./include/device/device.defs > for the device_set_status RPC declaration for instance. Ahum ... i will have to design such a prototype. > routine device_set_status( > device : device_t; > in flavor : dev_flavor_t; > in status : dev_status_t > ); This gives me new questions. Language: Why no "in" or "out" before parameter "device" ? How to say "in and out" ? Can you give me an URL where the language is documented ? Wiring: I still need to find out how to get the Scsi_Device parameter of gnumach/linux/src/drivers/scsi/scsi_ioctl.c: int scsi_ioctl_send_command(Scsi_Device *dev, void *buffer) from device_t Naming conventions: How to name the function ? device_transact_scsi() ? > What is > a bit more involved will be to add the method to the > device_emulation_ops structure, and the ds_device_foo routine in > device/ds_routines.c just like the ds_device_set_status() one. I found the struct definition in gnumach/device/device_emul.h . There i read /* Each emulation layer provides these operations. */ Does that mean, that all instances of struct device_emulation_ops have to be augmented by a function pointer ? I see 7 of them by grep -r 'struct device_emulation_ops .* =' gnumach | less (ignoring gnumach/device/ds_routines.c:emulation_list) Have a nice day :) Thomas
Re: ChangeLog/commit messages
Hi, On Wed, Sep 07, 2011 at 05:06:09PM +0200, Thomas Schwinge wrote: > On the other hand, comments such as Olaf's quoted above (``Instead of > [...]'') should in fact not be put into the ChangeLog/commit message, > but should be put (in a slightly altered form, of course) into the > code itself: to describe the logic/where the 1 constant is coming > from. Well, that's what the GCS says... But it's one of the portions of GCS I do not entirely agree this. Of course code should come with comments explaining it -- but I don't think the particular line I changed here needs much explanation. (Though the formatting code could do with a bit more explanation in general I guess...) Note that my explanation in the commit message is mostly about why I found the *previous* code not to be optimal... It would be rather inappropriate to put it next to the new code IMHO. The commit message on the other hand is where people generally look when they want to understand *why* things changed. That's where such explanations are useful. Note that with the exception of a few old GNU programs, pretty much *every* project I ever looked at follows this approach -- including huge ones such as Linux or X.Org. > (Olaf, as you've already seen, this does give me the power to assign > Savannah tasks to you.) ;-P And as I'm a volunteer, I retain the power to ignore this ;-P -antrik-
