Michal, has been there any progress? Olga
On Thu, Dec 13, 2012 at 12:22 PM, Michal Hlavinka <[email protected]> wrote: > On 12/12/2012 01:35 PM, ольга крыжановская wrote: >> >> Michal, has been any one working on the Linux kernel fifo/pipe >> implementation to implement I_PEEK? Is there a Bugzilla entry for >> this? >> >> Olga > > > Hi Olga, > > unfortunately, it's still in kernel team's todo list. > There is bugzilla for this, but it is internal only, so not public. > > Michal > > >> On Wed, Jun 13, 2012 at 5:54 PM, Michal Hlavinka <[email protected]> >> wrote: >>> >>> On 06/05/2012 03:03 PM, Cedric Blancher 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> >>> >>> >>> >>> I'm not aware about anything related, so I can't answer your >>> ran^W^W^Wquestion. >>> >>> >>>> 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 /> >>> >>> >>> >>> Cedric was somewhat right in his reply. There are a lot of processes >>> which >>> are quite resource demanding even for one line change. Also, there is >>> always >>> more work than what can be done (especially on kernel side. afaik, we're >>> still hiring ;-) ). If someone does X, it means he won't be able to do Y. >>> So, we do what product management tell us to do. >>> >>> Also, please don't forget that Red Hat is only Linux, but Linux is not >>> only >>> Red Hat. (Well, nowadays even the first part is no longer completely >>> true.) >>> I wanted to add I_PEEK feature request to upstream bugzilla, but I've >>> been >>> told that it does not work that way. It'd rot there for ages until >>> someone >>> would close that a few years later during some bugzilla clean up. >>> >>> Anyway, I found up a few colleagues willing to code it. I need a feature >>> request to be filed now. I'm going to ask a few customers who complained >>> about 'connection reset by peer' messages if they are willing to do it. >>> If I >>> fail, I'll try to convince them to code it in their spare time. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> ast-developers mailing list >>> [email protected] >>> https://mailman.research.att.com/mailman/listinfo/ast-developers >> >> >> >> > -- , _ _ , { \/`o;====- Olga Kryzhanovska -====;o`\/ } .----'-/`-/ [email protected] \-`\-'----. `'-..-| / http://twitter.com/fleyta \ |-..-'` /\/\ Solaris/BSD//C/C++ programmer /\/\ `--` `--` _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
