![]() | |||||||||||||
Messages in this thread |
On Sun, 9 May 2004 00:48:35 +0200, Pavel Machek wrote: > > > Couldn't sleep last night and finished a first complete version of > > cowlinks, code-named MAD COW. It is still based on the stupid old > > design with a flag to distinguish between regular hard links and > > cowlinks. Please don't comment on that design, it's just a proof of > > concept. > > > Patches are against 2.6.5 but most things should apply to other 2.6 > > kernel without too much trouble. > > > > 1 generic_sendpage - allow sendfile with ext[23] files as target > > 2 sendfile - introduce vfs_sendfile for in-kernel use > > 3 copyfile - new copyfile() system call > > Well, up to "3" it seems usefull on its own. You might attempt to > merge that. True. Right now I'm just lazy and prefer to keep them under my control. Maybe if 2.7 was already opened. > namei.c: you realy don't want to #include in the middle of .c file. Actually, I do. I'm still not convinced that all the low-level read/write functions need a struct file* as an argument, that looks like a really ugly hack to help nfs and some others. And if those can go, the #include will go as well. So the ugly line serves as a reminder for a different problem. :) On the other hand, if you can convince me that there is no way to avoid passing the struct file*, then I agree and the #include will move up. > vfs_unlink followed by BUG_ON(error)... that's definitely wrong. In > case of disk error, you might get error on unlink; but you should not > BUG() on that. Perhaps copyfile() should be specified as "may leave > part of copy of target on disk in case of error"? Yes, makes sense. I will keep the BUG_ON for a while as a reminder to really think through all the consequences, but most likely, I will just follow your suggestion. A real problem is that copyfile() has all errno's from create(), sendfile() and unlink() combined, which doesn't make error handling in userspace easy. "It could be this, that or another error" is the kind of mess I always hated about Windows, so I should try to do a little better. Jörn -- It's not whether you win or lose, it's how you place the blame. -- unknown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-03-22 13:03 [from the cache] ©2003-2008 | |||||||||||||