Discussion:
[ast-developers] I_PEEK on Linux pipes and fifos? (Fwd: [ast-users]
Irek Szczesniak
2012-06-01 12:32:44 UTC
Permalink
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.

Just Linux does not.

Irek

---------- Forwarded message ----------
From: Lionel Cons <lionelcons1972 at googlemail.com>
Date: Thu, May 31, 2012 at 10:38 PM
Subject: Re: [ast-users] ksh: command pipe -- connection reset
To: "Nemeth, Michael Kenneth (Mike)" <Mike.Nemeth at lsi.com>
Cc: "ast-users at research.att.com" <ast-users at research.att.com>


On 31 May 2012 21:48, Nemeth, Michael Kenneth (Mike)
Hello,
We are using ksh93u (2011-02-08) source compiled on rhel5.0 and we are
experiencing intermittent connect reset errors with typical unix command
pipelines.
min=`grep -v "^#" $infile | head -1 | nawk '{printf("%.3f\n",$3)}'`
grep: writing output: Connection reset by peer
I reviewed all ast-user, ast-developers archives, and other forums I have
bug#9089: [1003.1(2008)/Issue 7 0000205]: Shell pipeline connection
requirement too vague
http://lists.gnu.org/archive/html/bug-coreutils/2011-07/msg00090.html
http://lists.gnu.org/archive/html/bug-coreutils/2011-07/msg00089.html
Is there a solution to this issue?
Yes, get the Linux kernel to support I_PEEK on pipes and fifos like
Solaris does. AFAIK sockets are used because pipes on Linux do not
support I_PEEK, and without I_PEEK the shell would have to read the
streams byte by byte, i.e. one syscall per byte. Solaris allows I_PEEK
on pipes, fifos and sockets and gets a huge performance benefit from
that.

Lionel
_______________________________________________
ast-users mailing list
ast-users at research.att.com
https://mailman.research.att.com/mailman/listinfo/ast-users
--
Irek
Michal Hlavinka
2012-06-05 07:11:45 UTC
Permalink
Post by Irek Szczesniak
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.
Post by Irek Szczesniak
Just Linux does not.
Irek
---------- Forwarded message ----------
From: Lionel Cons<lionelcons1972 at googlemail.com>
Date: Thu, May 31, 2012 at 10:38 PM
Subject: Re: [ast-users] ksh: command pipe -- connection reset
To: "Nemeth, Michael Kenneth (Mike)"<Mike.Nemeth at lsi.com>
Cc: "ast-users at research.att.com"<ast-users at research.att.com>
On 31 May 2012 21:48, Nemeth, Michael Kenneth (Mike)
Hello,
We are using ksh93u (2011-02-08) source compiled on rhel5.0 and we are
experiencing intermittent connect reset errors with typical unix command
pipelines.
min=`grep -v "^#" $infile | head -1 | nawk '{printf("%.3f\n",$3)}'`
grep: writing output: Connection reset by peer
I reviewed all ast-user, ast-developers archives, and other forums I have
bug#9089: [1003.1(2008)/Issue 7 0000205]: Shell pipeline connection
requirement too vague
http://lists.gnu.org/archive/html/bug-coreutils/2011-07/msg00090.html
http://lists.gnu.org/archive/html/bug-coreutils/2011-07/msg00089.html
Is there a solution to this issue?
Yes, get the Linux kernel to support I_PEEK on pipes and fifos like
Solaris does. AFAIK sockets are used because pipes on Linux do not
support I_PEEK, and without I_PEEK the shell would have to read the
streams byte by byte, i.e. one syscall per byte. Solaris allows I_PEEK
on pipes, fifos and sockets and gets a huge performance benefit from
that.
Lionel
_______________________________________________
ast-users mailing list
ast-users at research.att.com
https://mailman.research.att.com/mailman/listinfo/ast-users
Cedric Blancher
2012-06-05 13:03:41 UTC
Permalink
Post by Michal Hlavinka
Post by Irek Szczesniak
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 />

Ced
--
Cedric Blancher <cedric.blancher at googlemail.com>
Institute Pasteur
Irek Szczesniak
2012-06-06 11:11:20 UTC
Permalink
On Tue, Jun 5, 2012 at 3:03 PM, Cedric Blancher
Post by Cedric Blancher
Post by Michal Hlavinka
Post by Irek Szczesniak
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
Michal Hlavinka
2012-06-13 15:54:19 UTC
Permalink
Post by Cedric Blancher
Post by Michal Hlavinka
Post by Irek Szczesniak
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.
Post by Cedric Blancher
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.
ольга крыжановская
2012-12-12 12:35:09 UTC
Permalink
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
Post by Michal Hlavinka
Post by Cedric Blancher
Post by Michal Hlavinka
Post by Irek Szczesniak
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.
Post by Cedric Blancher
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
ast-developers at research.att.com
https://mailman.research.att.com/mailman/listinfo/ast-developers
--
, _ _ ,
{ \/`o;====- Olga Kryzhanovska -====;o`\/ }
.----'-/`-/ olga.kryzhanovska at gmail.com \-`\-'----.
`'-..-| / http://twitter.com/fleyta \ |-..-'`
/\/\ Solaris/BSD//C/C++ programmer /\/\
`--` `--`
Michal Hlavinka
2012-12-13 11:22:20 UTC
Permalink
Post by ольга крыжановская
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
Post by ольга крыжановская
Post by Michal Hlavinka
Post by Cedric Blancher
Post by Michal Hlavinka
Post by Irek Szczesniak
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.
Post by Cedric Blancher
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
ast-developers at research.att.com
https://mailman.research.att.com/mailman/listinfo/ast-developers
ольга крыжановская
2013-05-12 21:47:18 UTC
Permalink
Michal, has been there any progress?

Olga
Post by Michal Hlavinka
Post by ольга крыжановская
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
Post by ольга крыжановская
Post by Michal Hlavinka
Post by Cedric Blancher
Post by Michal Hlavinka
Post by Irek Szczesniak
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.
Post by Cedric Blancher
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
ast-developers at research.att.com
https://mailman.research.att.com/mailman/listinfo/ast-developers
--
, _ _ ,
{ \/`o;====- Olga Kryzhanovska -====;o`\/ }
.----'-/`-/ olga.kryzhanovska at gmail.com \-`\-'----.
`'-..-| / http://twitter.com/fleyta \ |-..-'`
/\/\ Solaris/BSD//C/C++ programmer /\/\
`--` `--`
Joshuah Hurst
2013-05-16 20:57:14 UTC
Permalink
On Sun, May 12, 2013 at 11:47 PM, ????? ????????????
Post by ольга крыжановская
Michal, has been there any progress?
Did Redhat file a bug in kernel.org's bugzilla?

Josh
Michal Hlavinka
2013-05-27 14:18:34 UTC
Permalink
Hi Olga,

I'm still trying to push it through kernel team todo list. I talked with
a few people without success yet. I'm waiting on status information from
kernel team leader, but he's unreachable now (I guess he's on vacation now).

Josh:
No, it's in our bugzilla our kernel developers use, bug itself is not
publicly visible. I was discouraged by kernel developers from filing
this to upstream bugzilla, because it's extremely difficult to get any
attention to bug reports and almost impossible in case of feature
requests. The usual process is to bribe^Wconvince any kernel developer
you know to do the work.

Michal
Post by ольга крыжановская
Michal, has been there any progress?
Olga
Post by Michal Hlavinka
Post by ольга крыжановская
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
Post by ольга крыжановская
Post by Michal Hlavinka
Post by Cedric Blancher
Post by Michal Hlavinka
Post by Irek Szczesniak
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.
Post by Cedric Blancher
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
ast-developers at research.att.com
https://mailman.research.att.com/mailman/listinfo/ast-developers
ольга крыжановская
2013-05-27 15:10:16 UTC
Permalink
Michal, I think this is getting promoted the wrong way, to the kernel
developers.

A patch to implement I_PEEK on pipes, is a generic 'shell accelerator'
because shells no longer have to read byte by byte from pipes where
the dominant locale is the multibyte en_US.UTF-8.
In that light, any shell, including bash and dash, would benefit from
using I_PEEK. Just no one can use it because it does not work with the
default pipes.

Olga
Post by Michal Hlavinka
Hi Olga,
I'm still trying to push it through kernel team todo list. I talked with a
few people without success yet. I'm waiting on status information from
kernel team leader, but he's unreachable now (I guess he's on vacation now).
No, it's in our bugzilla our kernel developers use, bug itself is not
publicly visible. I was discouraged by kernel developers from filing this to
upstream bugzilla, because it's extremely difficult to get any attention to
bug reports and almost impossible in case of feature requests. The usual
process is to bribe^Wconvince any kernel developer you know to do the work.
Michal
Post by ольга крыжановская
Michal, has been there any progress?
Olga
Post by Michal Hlavinka
Post by ольга крыжановская
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
Post by ольга крыжановская
Post by Michal Hlavinka
Post by Cedric Blancher
Post by Michal Hlavinka
Post by Irek Szczesniak
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.
Post by Cedric Blancher
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
ast-developers at research.att.com
https://mailman.research.att.com/mailman/listinfo/ast-developers
--
, _ _ ,
{ \/`o;====- Olga Kryzhanovska -====;o`\/ }
.----'-/`-/ olga.kryzhanovska at gmail.com \-`\-'----.
`'-..-| / http://twitter.com/fleyta \ |-..-'`
/\/\ Solaris/BSD//C/C++ programmer /\/\
`--` `--`
Irek Szczesniak
2014-01-27 12:23:39 UTC
Permalink
Post by Michal Hlavinka
Hi Olga,
I'm still trying to push it through kernel team todo list. I talked with a
few people without success yet. I'm waiting on status information from
kernel team leader, but he's unreachable now (I guess he's on vacation now).
No, it's in our bugzilla our kernel developers use, bug itself is not
publicly visible. I was discouraged by kernel developers from filing this to
upstream bugzilla, because it's extremely difficult to get any attention to
bug reports and almost impossible in case of feature requests. The usual
process is to bribe^Wconvince any kernel developer you know to do the work.
Michal
MIchal, are there any updates for this bug?

Irek
Michal Hlavinka
2014-02-10 13:48:43 UTC
Permalink
Post by Irek Szczesniak
Post by Michal Hlavinka
Hi Olga,
I'm still trying to push it through kernel team todo list. I talked with a
few people without success yet. I'm waiting on status information from
kernel team leader, but he's unreachable now (I guess he's on vacation now).
No, it's in our bugzilla our kernel developers use, bug itself is not
publicly visible. I was discouraged by kernel developers from filing this to
upstream bugzilla, because it's extremely difficult to get any attention to
bug reports and almost impossible in case of feature requests. The usual
process is to bribe^Wconvince any kernel developer you know to do the work.
Michal
MIchal, are there any updates for this bug?
Irek
Hi,
I poked the person that can poke the right person. (still) waiting for
response.

Michal
Irek Szczesniak
2014-05-25 13:57:18 UTC
Permalink
Post by Michal Hlavinka
Post by Irek Szczesniak
Post by Michal Hlavinka
Hi Olga,
I'm still trying to push it through kernel team todo list. I talked with a
few people without success yet. I'm waiting on status information from
kernel team leader, but he's unreachable now (I guess he's on vacation now).
No, it's in our bugzilla our kernel developers use, bug itself is not
publicly visible. I was discouraged by kernel developers from filing this to
upstream bugzilla, because it's extremely difficult to get any attention to
bug reports and almost impossible in case of feature requests. The usual
process is to bribe^Wconvince any kernel developer you know to do the work.
Michal
MIchal, are there any updates for this bug?
Irek
Hi,
I poked the person that can poke the right person. (still) waiting for
response.
Michal, are there any updates for this bug?

Irek

Loading...