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 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 u
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 supp
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 tha
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'
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 f
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 i
The following patch extends the proc fs api as discussed in the thread "/proc
format" last month (http://marc.theaimsgroup.com/?t=9882254507&w=2&r=1).
It adds the following features:
- dynamic directories. Enables you to use directories for enumerations,
similar to the per-process director
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 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 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
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
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
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 postsc
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
On Tue, Mar 27, 2001 at 10:48:13AM -0800, Linus Torvalds wrote:
> So in /dev, there are two problems: we are getting painfully close to
> major numbers with 8 bits, and we've run out of minors several times. In
> fact, a lot of the reason for the dearthness of major numbers is the fact
> that we u
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 infor
21 matches
Mail list logo
