On Thursday 26 April 2001 00:24, Mark Hahn wrote:
> I have a sense that all of these could be collapsed into a single
> api where kernel systems would register hierarchies of tuples of
> , where callback would be passed the tag,
You also need to know the parent of the tuple to build a hierarchy.
On Thursday 26 April 2001 00:24, Mark Hahn wrote:
I have a sense that all of these could be collapsed into a single
api where kernel systems would register hierarchies of tuples of
type,tag,callback, where callback would be passed the tag,
You also need to know the parent of the tuple to
Mark Hahn wrote:
> the main goal at this point is to make kernel proc-related
> code more efficient, easy-to-use, etc. a purely secondary goal
> is to make user-space tools more robust, efficient, and simpler.
>
> there are three things that need to be communicated through the proc
>
On Wednesday 25 April 2001 21:19, you wrote:
> The corresponding one-value-per-file approach can probably be made to
> be a single call per value.
Yes, the real problem is writing a callback-based filesystem (unless you want
to hold everything in memory). After thinking about it for the last
On Wednesday 25 April 2001 23:16, you wrote:
> Not necessarily. If the "extended data" is put following the current data
> (since the data is currently record oriented) just making the output
> format longer will not/should not casue problems in reading the data.
> Alternatively, you can always
On Thu, 26 Apr 2001, J . A . Magallon wrote:
>
> On 04.25 Doug McNaught wrote:
> > "J . A . Magallon" <[EMAIL PROTECTED]> 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 ?
> > 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
On Thu, Apr 26, 2001 at 12:03:25AM +0200, J . A . Magallon wrote:
>
> On 04.25 Doug McNaught wrote:
> > "J . A . Magallon" <[EMAIL PROTECTED]> writes:
> >
> > > Question: it is possible to redirect the same fs call (say read) to
> > different
> > > implementations, based on the open mode of the
On 04.25 Doug McNaught wrote:
> "J . A . Magallon" <[EMAIL PROTECTED]> 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
"J . A . Magallon" <[EMAIL PROTECTED]> 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
On 04.25 Jesse Pollard wrote:
>
> Alternatively, you can always put one value per record:
> tag:value
> tag2:value2...
>
> This is still simpler than XML to read, and to generate.
>
Just my two cents.
It looks clear that /proc is for programs, not for humans. So the best format
Tim Jansen <[EMAIL PROTECTED]>:
> On Wednesday 25 April 2001 21:37, you wrote:
> > Personally, I think
> >>proc_printf(fragment, "%d %d",get_portnum(usbdev), usbdev->maxchild);
> > is shorter (and faster) to parse with
> > fscanf(input,"%d %d",,);
>
> Right, but what happens if you need
Jesse Pollard wrote:
> > But one thing XML provides (potentially) is a DTD that defines meanings and
>formats.
> > IMHO the kernel needs something like this for /proc (though not in DTD format!).
> >
> > Has anyone ever tried to write a formal syntax for all the entries
> > in /proc? We have
On Wednesday 25 April 2001 21:37, you wrote:
> Personally, I think
>> proc_printf(fragment, "%d %d",get_portnum(usbdev), usbdev->maxchild);
> is shorter (and faster) to parse with
> fscanf(input,"%d %d",,);
Right, but what happens if you need to extend the format? For example
Jesse Pollard wrote:
> Personally, I think
> proc_printf(fragment, "%d %d",get_portnum(usbdev), usbdev->maxchild);
> (or the string " ddd" with d representing a digit)
>
> is shorter (and faster) to parse with
> fscanf(input,"%d %d",,);
>
> Than it would be to try parsing
>
- Received message begins Here -
>
> On Wednesday 25 April 2001 19:10, you wrote:
> > The command
> > more foo/* foo/*/*
> > will display the values in the foo subtree nicely, I think.
>
> Unfortunately it displays only the values. Dumping numbers and strings
> without
Tim Jansen wrote:
>
> On Wednesday 25 April 2001 19:10, you wrote:
> > The command
> > more foo/* foo/*/*
> > will display the values in the foo subtree nicely, I think.
>
> Unfortunately it displays only the values. Dumping numbers and strings
> without knowing their meaning (and probably
On Wednesday 25 April 2001 19:10, you wrote:
> The command
> more foo/* foo/*/*
> will display the values in the foo subtree nicely, I think.
Unfortunately it displays only the values. Dumping numbers and strings
without knowing their meaning (and probably not even the order) is not very
Followup to: <[EMAIL PROTECTED]>
By author:Dan Kegel <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> The only problem with /proc as it stands is that there is no formal
> syntax for its entries. Some of them are hard to parse.
>
/proc/sys is probably the method to follow. Every
Tim Jansen wrote:
> On Tuesday 24 April 2001 18:39, Martin Dalecki wrote:
> >> Are there alternatives to get complex and extendable information out to
> >> user space?
> > Yes filesystem structures.
>
> How exactly can this work? A single value per file is not very helpful if you
> have a
Tim Jansen wrote:
On Tuesday 24 April 2001 18:39, Martin Dalecki wrote:
Are there alternatives to get complex and extendable information out to
user space?
Yes filesystem structures.
How exactly can this work? A single value per file is not very helpful if you
have a thousand
Followup to: [EMAIL PROTECTED]
By author:Dan Kegel [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
The only problem with /proc as it stands is that there is no formal
syntax for its entries. Some of them are hard to parse.
/proc/sys is probably the method to follow. Every item is a
On Wednesday 25 April 2001 19:10, you wrote:
The command
more foo/* foo/*/*
will display the values in the foo subtree nicely, I think.
Unfortunately it displays only the values. Dumping numbers and strings
without knowing their meaning (and probably not even the order) is not very
Tim Jansen wrote:
On Wednesday 25 April 2001 19:10, you wrote:
The command
more foo/* foo/*/*
will display the values in the foo subtree nicely, I think.
Unfortunately it displays only the values. Dumping numbers and strings
without knowing their meaning (and probably not even the
- Received message begins Here -
On Wednesday 25 April 2001 19:10, you wrote:
The command
more foo/* foo/*/*
will display the values in the foo subtree nicely, I think.
Unfortunately it displays only the values. Dumping numbers and strings
without knowing their
Jesse Pollard wrote:
Personally, I think
proc_printf(fragment, %d %d,get_portnum(usbdev), usbdev-maxchild);
(or the string ddd with d representing a digit)
is shorter (and faster) to parse with
fscanf(input,%d %d,usbdev,maxchild);
Than it would be to try parsing
On Wednesday 25 April 2001 21:37, you wrote:
Personally, I think
proc_printf(fragment, %d %d,get_portnum(usbdev), usbdev-maxchild);
is shorter (and faster) to parse with
fscanf(input,%d %d,usbdev,maxchild);
Right, but what happens if you need to extend the format? For example
Tim Jansen [EMAIL PROTECTED]:
On Wednesday 25 April 2001 21:37, you wrote:
Personally, I think
proc_printf(fragment, %d %d,get_portnum(usbdev), usbdev-maxchild);
is shorter (and faster) to parse with
fscanf(input,%d %d,usbdev,maxchild);
Right, but what happens if you need to
On 04.25 Jesse Pollard wrote:
Alternatively, you can always put one value per record:
tag:value
tag2:value2...
This is still simpler than XML to read, and to generate.
Just my two cents.
It looks clear that /proc is for programs, not for humans. So the best format
for
J . A . Magallon [EMAIL PROTECTED] 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
On 04.25 Doug McNaught wrote:
J . A . Magallon [EMAIL PROTECTED] 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
On Thu, 26 Apr 2001, J . A . Magallon wrote:
On 04.25 Doug McNaught wrote:
J . A . Magallon [EMAIL PROTECTED] 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
On Wednesday 25 April 2001 23:16, you wrote:
Not necessarily. If the extended data is put following the current data
(since the data is currently record oriented) just making the output
format longer will not/should not casue problems in reading the data.
Alternatively, you can always put one
On Wednesday 25 April 2001 21:19, you wrote:
The corresponding one-value-per-file approach can probably be made to
be a single call per value.
Yes, the real problem is writing a callback-based filesystem (unless you want
to hold everything in memory). After thinking about it for the last
Mark Hahn wrote:
the main goal at this point is to make kernel proc-related
code more efficient, easy-to-use, etc. a purely secondary goal
is to make user-space tools more robust, efficient, and simpler.
there are three things that need to be communicated through the proc
interface,
On Tuesday 24 April 2001 18:43, mirabilos wrote:
> What about indenting? I think of 0 spaces before the device name,
> 1 space before properties which belong to the device.
> Structure per entry:
>[Space] Name colon property
But what is the advantage? Its not less work in the kernel, and in
On Tuesday 24 April 2001 18:39, Martin Dalecki wrote:
> Are there alternatives to get complex and extendable information out to
> user space?
> Yes filesystem structures.
How exactly can this work? A single value per file is not very helpful if you
have a thousand values. You could cluster
Tim Jansen wrote:
>
> On Tuesday 24 April 2001 11:40, Martin Dalecki wrote:
> > Tim Jansen wrote:
> > > The Linux Device Registry (devreg) is a kernel patch that adds a device
> > > database in XML format to the /proc filesystem. It collects all
> > OH SHIT!! ^^^
> > Why don't you just add
> > > The Linux Device Registry (devreg) is a kernel patch that adds a
device
> > > database in XML format to the /proc filesystem. It collects all
> > OH SHIT!! ^^^
> > Why don't you just add postscript output to /proc?
>
> XML wasn't my first choice. The 0.1.x versions used simple
On Tuesday 24 April 2001 11:40, Martin Dalecki wrote:
> Tim Jansen wrote:
> > The Linux Device Registry (devreg) is a kernel patch that adds a device
> > database in XML format to the /proc filesystem. It collects all
> OH SHIT!! ^^^
> Why don't you just add postscript output to /proc?
XML
Tim Jansen wrote:
>
> The Linux Device Registry (devreg) is a kernel patch that adds a device
> database in XML format to the /proc filesystem. It collects all information
OH SHIT!! ^^^
Why don't you just add postscript output to /proc?
> about the system's physical devices, creates
Tim Jansen wrote:
The Linux Device Registry (devreg) is a kernel patch that adds a device
database in XML format to the /proc filesystem. It collects all information
OH SHIT!! ^^^
IRONY
Why don't you just add postscript output to /proc?
/IRONY
about the system's physical devices,
On Tuesday 24 April 2001 11:40, Martin Dalecki wrote:
Tim Jansen wrote:
The Linux Device Registry (devreg) is a kernel patch that adds a device
database in XML format to the /proc filesystem. It collects all
OH SHIT!! ^^^
Why don't you just add postscript output to /proc?
XML wasn't
The Linux Device Registry (devreg) is a kernel patch that adds a
device
database in XML format to the /proc filesystem. It collects all
OH SHIT!! ^^^
Why don't you just add postscript output to /proc?
XML wasn't my first choice. The 0.1.x versions used simple name/value
pairs,
I
Tim Jansen wrote:
On Tuesday 24 April 2001 11:40, Martin Dalecki wrote:
Tim Jansen wrote:
The Linux Device Registry (devreg) is a kernel patch that adds a device
database in XML format to the /proc filesystem. It collects all
OH SHIT!! ^^^
Why don't you just add postscript
On Tuesday 24 April 2001 18:43, mirabilos wrote:
What about indenting? I think of 0 spaces before the device name,
1 space before properties which belong to the device.
Structure per entry:
[Space] Name colon property
But what is the advantage? Its not less work in the kernel, and in
The Linux Device Registry (devreg) is a kernel patch that adds a device
database in XML format to the /proc filesystem. It collects all information
about the system's physical devices, creates persistent device ids and
provides them in the file /proc/devreg.
Devreg has three purposes:
-
The Linux Device Registry (devreg) is a kernel patch that adds a device
database in XML format to the /proc filesystem. It collects all information
about the system's physical devices, creates persistent device ids and
provides them in the file /proc/devreg.
Devreg has three purposes:
-
48 matches
Mail list logo
