To supply a little more context, the problem specifically has to do with what behavior should happen when the user specifies an iovec to sendfilev that:
1. Uses an offset that is at or beyond the end of the file being read. Or 2. Uses a valid offset that is before the end of the file, but specifies a length that will take the read to beyond EOF. After much deliberation, the consensus is that for case 1, sendfilev should return however many bytes have been transferred prior to this iovec entry, but stop processing (i.e. not go on to the next iovec entry). And the same thing in case 2. One more key point is that if no bytes have been transferred, (this is the first iovec entry) then sendfilev then zero is returned. So, when an attempt to read past the end of the current file is detected, we want to stop and then return in such a way as to signal that we do not want to go on to the next iovec entry. The code currently does this when an error is returned from the lower level, hence the obvious solution of returning an error. Brian Utterback wrote: > I am working on what has turned out to be a long and convoluted > issue with the sendfile and sendfilev library/system calls. > > The upshot of the issue is that I need sendfile to return under > certain conditions that do not constitute an error. The problem > I have is how to go about modifying the kernel routines called > so that they terminate the processing without returning an error > to the application. > > Now from a technical standpoint, this is pretty easy. Since an > error return is propagated up the stack and terminates the processing, > all I have to do is when the conditions are detected, return an > error, and at the highest level on the stack check for the error > and eliminate it. We already do this with the EINTR error return. > > The problem I have is two fold. First, returning an error where > there isn't one doesn't seem valid to me. Something just bothers > me about recording an error when one doesn't exist. Which leads > into the second problem, which error should I choose. > > If I set an error return code, I have to be very careful about > which one I use. It has to be something that could not normally > occur, because then I would mask the problem at the top level. > But if I choose something obscure, then this just make my first > problem worse, because every error has some semantics associated > with it, and those semantics would not apply here. > > So, first, how horrible is it to use an error code return as a > signal between kernel routine layers? And second, assuming the > first isn't judged horrible, which error would be a good choice? > -- blu The #1 red flag for privacy advocates is when a law enforcement official says "If you aren't doing anything wrong, then you have nothing to worry about." ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
