Discussion:
read() on relayfs channel returns premature 0
(too old to reply)
Jan Engelhardt
2005-03-24 06:59:06 UTC
Permalink
1>http://www.opersys.com/ftp/pub/relayfs/patch-relayfs-2.6.10-050113
2>ftp://oss.sgi.com/projects/pagg/download/linux-2.6.10-pagg.patch-4

I guess (2) is already in 2.6.11, because I do not get any compile and load
errors (good so!), is it?

Jan Engelhardt
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Tom Zanussi
2005-03-24 19:17:18 UTC
Permalink
Now I understand that this is not the latest release of relayfs (there
are the redux patches, which I have yet to try). Nonetheless I'd like
[...]
I've tested it on 2.6.10 with the pagg and relayfs patches from
http://www.opersys.com/ftp/pub/relayfs/patch-relayfs-2.6.10-050113
and
ftp://oss.sgi.com/projects/pagg/download/linux-2.6.10-pagg.patch-4
read() gives me a zero still once about a page of data has been read.
Thanks - I've tried it out and haven't immediately been able to
reproduce the problem yet - I'll do some more pounding on it though
when I get the chance.

BTW, I just want to point out that there aren't any problems with
read() in the version of relayfs included in the -mm tree (i.e. the
'redux' version), since of course it doesn't support read().

I went ahead and did a quick port of your stuff to the new version of
relayfs, which you can find here:

http://prdownloads.sourceforge.net/dprobes/RelayfsModule-new.tar.bz2?download

There's a README in the tarball with some notes on building and
running it. It includes both the kernel and user-side code, which makes
use of the relay-apps code and documentation found here (I've included
the necessary files in the RelayfsModule-new tarball so you don't have
to actually get this):

http://prdownloads.sourceforge.net/dprobes/relay-apps-0.2.tar.gz?download

Hopefully the new version will still be useful for what you're trying
to do, but it does differ in a couple important ways from the old
version, and points up the fact that the new relayfs really is now
much more specialized for high-volume applications -

- your old version used 'packet' mode with read(). The new relayfs
only supports 'bulk' mode with mmap(), which means it's not really
useful for notification of single events. I'm not sure how important
that is for your application - if you're mainly interested in
collecting data, you can certainly use it even for low-volume
applications, but the events will be sent to user space in 'blocks'.
You can modify the user space app to process blocks of events as they
come in, and play around with buffer sizes to get them more often, but
it's not quite the same thing.

- your old version used a single buffer, while the new relayfs only
supports per-cpu buffers, which means you'd have to sort out the
events in user space and impose some ordering using timestamps for
instance if your data doesn't already have a natural ordering (BTW,
the new relayfs doesn't have an option any longer to do automatic
timestamping either).

I'll continue maintaining the old relayfs for existing users (so
thanks for the patch and the test code) so if the new version doesn't
fit your needs, you'll still have the old version to fall back on.

Thanks,

Tom

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Jan Engelhardt
2005-03-24 19:53:51 UTC
Permalink
Post by Tom Zanussi
BTW, I just want to point out that there aren't any problems with
read() in the version of relayfs included in the -mm tree (i.e. the
'redux' version), since of course it doesn't support read().
Hm? Relayfs does not support a `cat /dev/relay/AChannelName` anymore?
Post by Tom Zanussi
I'll continue maintaining the old relayfs for existing users (so
thanks for the patch and the test code) so if the new version doesn't
fit your needs, you'll still have the old version to fall back on.
Do you have the "new relayfs" as a "normal" file (outside any revision
control system), e.g. a diff patch?
Post by Tom Zanussi
Hopefully the new version will still be useful for what you're trying to do
- your old version used 'packet' mode with read(). The new relayfs
only supports 'bulk' mode with mmap()
- your old version used a single buffer, while the new relayfs only
supports per-cpu buffers
(BTW, the new relayfs doesn't have an option any longer to do automatic
timestamping either).
I wanted to port the kernel side of my keylogger over to relayfs, but given
that API and functionality have now changed I am somewhat reluctant to do it.

Jan Engelhardt
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Karim Yaghmour
2005-03-25 12:18:38 UTC
Permalink
Post by Jan Engelhardt
Hm? Relayfs does not support a `cat /dev/relay/AChannelName` anymore?
This was a requirement for it to be included.

Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || ***@opersys.com || 1-866-677-4546
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Kingsley Cheung
2005-03-28 23:57:30 UTC
Permalink
Post by Tom Zanussi
Now I understand that this is not the latest release of relayfs (there
are the redux patches, which I have yet to try). Nonetheless I'd like
[...]
I've tested it on 2.6.10 with the pagg and relayfs patches from
http://www.opersys.com/ftp/pub/relayfs/patch-relayfs-2.6.10-050113
and
ftp://oss.sgi.com/projects/pagg/download/linux-2.6.10-pagg.patch-4
read() gives me a zero still once about a page of data has been read.
Thanks - I've tried it out and haven't immediately been able to
reproduce the problem yet - I'll do some more pounding on it though
when I get the chance.
Ok. It should be fairly easy to reproduce. On a dual 400MHz PII I've
been able to get the zero by running one reader of the channel in
parallel with a simple shell script like "while :; do ps -ef >
/dev/null; done".
Post by Tom Zanussi
BTW, I just want to point out that there aren't any problems with
read() in the version of relayfs included in the -mm tree (i.e. the
'redux' version), since of course it doesn't support read().
Ok.
Post by Tom Zanussi
I went ahead and did a quick port of your stuff to the new version of
http://prdownloads.sourceforge.net/dprobes/RelayfsModule-new.tar.bz2?download
There's a README in the tarball with some notes on building and
running it. It includes both the kernel and user-side code, which makes
use of the relay-apps code and documentation found here (I've included
the necessary files in the RelayfsModule-new tarball so you don't have
http://prdownloads.sourceforge.net/dprobes/relay-apps-0.2.tar.gz?download
Hopefully the new version will still be useful for what you're trying
to do, but it does differ in a couple important ways from the old
version, and points up the fact that the new relayfs really is now
much more specialized for high-volume applications -
- your old version used 'packet' mode with read(). The new relayfs
only supports 'bulk' mode with mmap(), which means it's not really
useful for notification of single events. I'm not sure how important
that is for your application - if you're mainly interested in
collecting data, you can certainly use it even for low-volume
applications, but the events will be sent to user space in 'blocks'.
You can modify the user space app to process blocks of events as they
come in, and play around with buffer sizes to get them more often, but
it's not quite the same thing.
- your old version used a single buffer, while the new relayfs only
supports per-cpu buffers, which means you'd have to sort out the
events in user space and impose some ordering using timestamps for
instance if your data doesn't already have a natural ordering (BTW,
the new relayfs doesn't have an option any longer to do automatic
timestamping either).
Right. Thanks for all your work on it Tom . I really appreciate it.
I have been considering a move over to the redux version recently.
Your port will make it easier for me to test both versions out. I'll
keep your pointers in mind.
Post by Tom Zanussi
I'll continue maintaining the old relayfs for existing users (so
thanks for the patch and the test code) so if the new version doesn't
fit your needs, you'll still have the old version to fall back on.
Thanks,
Tom
Ok. Thanks again!
--
Kingsley
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------
Loading...