On Friday 29 June 2001 19:27, Jordan Breeding wrote:
> noticed my real problem with the keyboard. The kernel apparently
> expects a PS/2 (AT) keyboard to be plugged in because if there isn't one
> the kernel reports timeouts and seems slower than when there is a PS/2
> keyboard present, my guess
On Friday 29 June 2001 19:27, Jordan Breeding wrote:
noticed my real problem with the keyboard. The kernel apparently
expects a PS/2 (AT) keyboard to be plugged in because if there isn't one
the kernel reports timeouts and seems slower than when there is a PS/2
keyboard present, my guess is
On Sunday 20 May 2001 15:40, Alexander Viro wrote:
> > ctlfd = open_device_control_fd(fd);
> > If fd is something that doesn't have a control interface (say, it already
> > is a control filehandle), this returns an appropriate error code.
> It may have several. Which one?
That's why I proposed
On Sunday 20 May 2001 15:40, Alexander Viro wrote:
ctlfd = open_device_control_fd(fd);
If fd is something that doesn't have a control interface (say, it already
is a control filehandle), this returns an appropriate error code.
It may have several. Which one?
That's why I proposed using
On Saturday 19 May 2001 21:43, Pavel Machek wrote:
> I think that plan9 uses something different -- they have ttyS0 and
> ttyS0ctl. This would leave us with problem "how do I get handle to
> ttyS0ctl when I only have handle to ttyS0"?
One possibility is to add multiforked (multi-stream) file
On Saturday 19 May 2001 21:43, Pavel Machek wrote:
I think that plan9 uses something different -- they have ttyS0 and
ttyS0ctl. This would leave us with problem how do I get handle to
ttyS0ctl when I only have handle to ttyS0?
One possibility is to add multiforked (multi-stream) file support
On Thursday 17 May 2001 22:00, Brian Wheeler wrote:
> Consider an ID consisting of:
> * vendor
> * model
Vendor and model ids are available for PCI and USB devices, but I think you
can not assume that all busses have them and you dont gain anything if you
keep them separate (unless
On Thursday 17 May 2001 22:00, Brian Wheeler wrote:
Consider an ID consisting of:
* vendor
* model
Vendor and model ids are available for PCI and USB devices, but I think you
can not assume that all busses have them and you dont gain anything if you
keep them separate (unless
On Thursday 17 May 2001 19:18, you wrote:
> I wouldn't make that assumpation. I have two PS/2 keybaords attached to my
> system and they don't have serial ids nor do they have vendor or product
> ids.
Yes, PS/2 is a system where you must use the location. That's why a device id
must contain the
On Thursday 17 May 2001 08:43, Thomas Sailer wrote:
> Cheap USB devices (and sometimes even expensive ones)
> do not have serial numbers or other unique identifiers.
> Therefore some sort of topology based addressing scheme
> has to be used in that case.
No, there is another addressing scheme
On Thursday 17 May 2001 14:07, you wrote:
> For identifying this is probably the right approach. However identifying is
> not enough, as the ioctl discussion has shown. Capabilities are needed. How
> can the device registry provide that information ?
The device registry provides you with
On Thursday 17 May 2001 14:07, you wrote:
For identifying this is probably the right approach. However identifying is
not enough, as the ioctl discussion has shown. Capabilities are needed. How
can the device registry provide that information ?
The device registry provides you with device's
On Thursday 17 May 2001 08:43, Thomas Sailer wrote:
Cheap USB devices (and sometimes even expensive ones)
do not have serial numbers or other unique identifiers.
Therefore some sort of topology based addressing scheme
has to be used in that case.
No, there is another addressing scheme that
On Thursday 17 May 2001 19:18, you wrote:
I wouldn't make that assumpation. I have two PS/2 keybaords attached to my
system and they don't have serial ids nor do they have vendor or product
ids.
Yes, PS/2 is a system where you must use the location. That's why a device id
must contain the
Miles Lane <[EMAIL PROTECTED]> wrote on 15/5/01 17:41:
>Does your approach solve
>the problem of USB devices,
>like mice, that
>don't have device ID's of any
>sort, where topology is the
>only way to
>distinguish them?
yes, that's what the location part is for.
Bye...
-
To unsubscribe
On Wednesday 16 May 2001 01:16, David Brownell wrote:
>Only if it's augmented by additional device IDs, such as the
>"what 's the physical connection for this interface" sort of
>primitive that's been mentioned.
>[...]
> I suppose that for network interface names, some convention for
> interface
On Wednesday 16 May 2001 01:16, David Brownell wrote:
Only if it's augmented by additional device IDs, such as the
what 's the physical connection for this interface sort of
primitive that's been mentioned.
[...]
I suppose that for network interface names, some convention for
interface ioctls
Miles Lane [EMAIL PROTECTED] wrote on 15/5/01 17:41:
Does your approach solve
the problem of USB devices,
like mice, that
don't have device ID's of any
sort, where topology is the
only way to
distinguish them?
yes, that's what the location part is for.
Bye...
-
To unsubscribe from this
The following patch extends the proc fs api as discussed in the thread "/proc
format" last month (http://marc.theaimsgroup.com/?t=9882254507=2=1).
It adds the following features:
- dynamic directories. Enables you to use directories for enumerations,
similar to the per-process directories
The following patch extends the proc fs api as discussed in the thread /proc
format last month (http://marc.theaimsgroup.com/?t=9882254507w=2r=1).
It adds the following features:
- dynamic directories. Enables you to use directories for enumerations,
similar to the per-process directories
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
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 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
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
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
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
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
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
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 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
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:
-
RFC: Linux Device Registry
==
Summary
---
The device registry provides a /proc file in text format that contains
a list of all connected physical devices. Each list entry
includes (as far as available) the name and vendor of the device, its
location/topological
RFC: Linux Device Registry
==
Summary
---
The device registry provides a /proc file in text format that contains
a list of all connected physical devices. Each list entry
includes (as far as available) the name and vendor of the device, its
location/topological
39 matches
Mail list logo
