On Thu, 04 Jan 2007 11:51:10 -0600 Eric Sandeen <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote: > > > Al is correct, of course. But the patch takes bad_inode.o from 280 up to > > 703 > > bytes, which is a bit sad for some cosmetic thing which nobody ever looks > > at or modifies. > > > > Perhaps you can do > > > > static int return_EIO_int(void) > > { > > return -EIO; > > } > > > > static int bad_file_release(struct inode * inode, struct file * filp) > > __attribute__((alias("return_EIO_int"))); > > static int bad_file_fsync(struct inode * inode, struct file * filp) > > __attribute__((alias("return_EIO_int"))); > > > > etcetera? > Ok, try this on for size. Even though the gcc manual says alias doesn't work > on all target machines, I assume linux arches are ok since alias is used > in the core module init & exit code... > > Also - is it ok to alias a function with one signature to a function with > another signature? Ordinarily I'd say no wucking fay, but that's effectively what we've been doing in there for ages, and it seems to work. I'd be a bit worried if any of these functions were returning pointers, because one could certainly conceive of an arch+compiler combo which returns pointers in a different register from integers (680x0?) but that's not happening here. > Note... I also realized that there are a couple of file ops which expect > unsigned > returns... poll and get_unmapped_area. The latter seems to be handled just > fine by > the caller, which does IS_ERR gyrations to check for errnos. > > I'm not so sure about poll; some callers put the return in a signed int, > others > unsigned, not sure anyone is really checking for -EIO... I think this op > should > probably be returning POLLERR, so that's what I've got in this version. Yeah, that should all be OK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/