On Tue, 2007-05-08 at 16:22 +0530, Amit K. Arora wrote: > On Mon, May 07, 2007 at 10:24:37AM -0500, Dave Kleikamp wrote: > > On Mon, 2007-05-07 at 17:37 +0530, Amit K. Arora wrote: > > > On Thu, May 03, 2007 at 09:31:33PM -0700, Andrew Morton wrote:
> > > > So we don't implement fallocate on bitmap-based files! Well that's huge > > > > news. The changelog would be an appropriate place to communicate this, > > > > along with reasons why, or a description of the plan to fix it. > > > > > > Ok. Will add this in the function description as well. > > > > > > > Also, posix says nothing about fallocate() returning ENOTTY. > > > > > > Right. I don't seem to find any suitable error from posix description. > > > Can you please suggest an error code which might make more sense here ? > > > Will -ENOTSUPP be ok ? Since we want to say here that we don't support > > > non-extent files. > > > > Isn't the idea that libc will interpret -ENOTTY, or whatever is returned > > here, and fall back to the current library code to do preallocation? > > This way, the caller of fallocate() will never see this return code, so > > it won't violate posix. > > You are right. > > But, we still need to "standardize" (and limit) the error codes > which we should return from kernel when we want to fall back on the > library implementation. The posix_fallocate() library function will have > to look for a set of errors from fallocate() system call, upon receiving > which it will do preallocation from user level; or else, it will return > success/error-code returned by the system call to the user. > > I think we can make it fall back to library implementation of fallocate, > whenever posix_fallocate() receives any of the following errors from > fallocate() system call: > > 1. ENOSYS > 2. EOPNOTSUPP > 3. ENOTTY (?) > > Now the question is - should we limit the set of errors for this purpose > to just 1 & 2 above ? In that case I will need to change the error being > returned here to -EOPNOTSUPP (from current -ENOTTY). If you want my opinion, -EOPNOTSUPP is better than -ENOTTY. Shaggy -- David Kleikamp IBM Linux Technology Center - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
