On Tue, Jun 5, 2012 at 3:03 PM, Cedric Blancher <[email protected]> wrote: > On 5 June 2012 09:11, Michal Hlavinka <[email protected]> wrote: >> On 06/01/2012 02:32 PM, Irek Szczesniak wrote: >>> >>> Michal, did anyone ever filed a bug against Linux's FIFO/PIPE >>> implementations to support I_PEEK? As far as I can check all SystemV >>> derivatives (including Solaris), AIX and HP/UX support I_PEEK on pipes >>> and fifos. >> >> >> I don't know if there was any official attempt. I asked a few kernel >> developers in person and they told me that no one will bother with this. > > <rant> > Michal, I recall that Redhat staff once ridiculed and mocked a patch > (...why add extra performance support for a dead OS [Solaris] ...) > which added support for I_PEEK to bash2 and finally convinced the > maintainers NOT to take it. So basically this issue is blocked from > both sides, kernel and bash, by Redhat. > Why? > </rant> > > As for an implementation in the Linux fifo kernel module, the I_PEEK > ioctl() can be implemented along the lines of a read() syscall but > without disposing the data which have been read. An implementation > should therefore be very easy and should give the shells in Linux a > SERIOUS performance advantage. I'm wondering why Redhat isn't > interested in performance. Oh yes, see <rant />
Well, you have to see that from the management point of view: 1. bash does not use I_PEEK and therefore there is no business reason to implement it. Performance advantage != business advantage 2. It costs two or three mandays to implement I_PEEK and another manweek to push it to kernel.org. Who is gonna pay for that? As long no customer pays for it and no competitor has I_PEEK and thus gains an advantage over Redhat they won't move their butt. This is business. Irek _______________________________________________ ast-developers mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/ast-developers
