On (20/03/13 08:02), Bruno Meneguele wrote: > Ok, I poorly expressed the notion of "documentantion". The userspace > doesn't tell about returning -ESPIPE, but to the functions work properly > they watch for -ESPIPE returning from the syscall. For instance, gblic > dprintf() implementation: > > dprintf: > __vdprintf_internal: > _IO_new_file_attach: > > if (_IO_SEEKOFF (fp, (off64_t)0, _IO_seek_cur, _IOS_INPUT|_IOS_OUTPUT) > == _IO_pos_BAD && errno != ESPIPE) > return NULL; > > With that, if the seek fails, but return anything other than ESPIPE the > dprintf() will also fail returning -EINVAL to dprintf() caller. While if > ESPIPE is returned, it's "ignored" and the call still works. The way we > have today make kmsg an exception case among the rest of the system > files where you can open with dprintf. > > One of the things I could agree with is removing the SEEK call from > dprintf, since fprintf basically follows the same steps, but doesn't > seek anything. But at the same time, IMO it makes sense to make kmsg > interface complaint with the errno return values. The code in questions is very old. So let's add the missing bit to the kernel. At the same time, we probably can have a slightly more detailed documentation / code comment. -ss
