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.
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
> interfac
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 t
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 pu
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 d
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 numb
"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
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
f
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 happe
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 bi
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 e
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
- 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 know
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
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
usef
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 it
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 th
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 th
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 p
> > > 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/valu
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 w
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 pers
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:
- collec
26 matches
Mail list logo
