From: "J . A . Magallon" <jamagallon@able.es>
To: Doug McNaught <doug@wireboard.com>
Cc: "J . A . Magallon" <jamagallon@able.es>,
Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil>,
tim@tjansen.de, linux-kernel@vger.kernel.org
Subject: Re: /proc format (was Device Registry (DevReg) Patch 0.2.0)
Date: Thu, 26 Apr 2001 00:03:25 +0200 [thread overview]
Message-ID: <20010426000325.A6621@werewolf.able.es> (raw)
In-Reply-To: <01042522404901.00954@cookie> <200104252116.QAA46520@tomcat.admin.navo.hpc.mil> <20010425235000.A3432@werewolf.able.es> <m34rvcy73o.fsf@belphigor.mcnaught.org>
In-Reply-To: <m34rvcy73o.fsf@belphigor.mcnaught.org>; from doug@wireboard.com on Wed, Apr 25, 2001 at 23:58:35 +0200
On 04.25 Doug McNaught wrote:
> "J . A . Magallon" <jamagallon@able.es> writes:
>
> > Question: it is possible to redirect the same fs call (say read) to
> different
> > implementations, based on the open mode of the file descriptor ? So, if
> > you open the entry in binary, you just get the number chunk, if you open
> > it in ascii you get a pretty printed version, or a format description like
>
> There is no distinction between "text" and "binary" modes on a file
> descriptor. The distinction exists in the C stdio layer, but is a
> no-op on Unix systems.
>
Yep, realized after the post, fopen() is a wrapper for open(). The idea
is to (someway) set the proc entry in verbose vs fast-binary mode for
reads. Perhaps an ioctl() or an fcntl() or something similar.
So the verbose mode gives the field names, and the binary mode just
gives the numbers. Applications that know what are reading can just
read binary data, and fast.
--
J.A. Magallon # Let the source
mailto:jamagallon@able.es # be with you, Luke...
Linux werewolf 2.4.3-ac14 #1 SMP Wed Apr 25 02:07:45 CEST 2001 i686
next prev parent reply other threads:[~2001-04-25 22:03 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-25 17:10 Device Registry (DevReg) Patch 0.2.0 Dan Kegel
2001-04-25 18:09 ` H. Peter Anvin
2001-04-25 18:55 ` /proc format (was Device Registry (DevReg) Patch 0.2.0) Tim Jansen
2001-04-25 19:19 ` Dan Kegel
2001-04-25 23:09 ` Tim Jansen
2001-04-25 19:37 ` Jesse Pollard
2001-04-25 20:08 ` Dan Kegel
2001-04-25 20:40 ` Tim Jansen
2001-04-25 21:16 ` Jesse Pollard
2001-04-25 21:50 ` J . A . Magallon
2001-04-25 21:58 ` Doug McNaught
2001-04-25 22:03 ` J . A . Magallon [this message]
2001-04-25 22:24 ` Marko Kreen
2001-04-25 22:42 ` Alexander Viro
2001-04-25 22:24 ` Mark Hahn
2001-04-26 14:06 ` Tim Jansen
2001-04-25 22:46 ` Tim Jansen
[not found] <200104252056.PAA44995@tomcat.admin.navo.hpc.mil>
2001-04-25 21:10 ` Dan Kegel
-- strict thread matches above, loose matches on Subject: below --
2001-04-26 1:09 Dan Kegel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010426000325.A6621@werewolf.able.es \
--to=jamagallon@able.es \
--cc=doug@wireboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pollard@tomcat.admin.navo.hpc.mil \
--cc=tim@tjansen.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox