From: Tim Jansen <tim@tjansen.de>
To: linux-hotplug@vger.kernel.org
Subject: Re: [RFC/Patch] Device Registry
Date: Sun, 01 Apr 2001 23:07:14 +0000 [thread overview]
Message-ID: <marc-linux-hotplug-98616728118704@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-98614762103643@msgid-missing>
On Sunday 01 April 2001 19:47, you wrote:
> I like the notion of modeling through attributes, but the flat
> namespace bothers me a lot. Except maybe as a way to
> finesse the namespace structure arguments! I'd rather see
> separate naming contexts (directories) grouping different
> types of devices.
I am very interested in ideas how to do this better (especially to have one
file per device), but there were three reasons for the current implementation:
- it is easier to implement in kernel and user-space
- i dont know how to name the devices. I looked at the way sun did it with
their device tree and didnt like it, even though I like the
everything-is-a-file notion, too
- as you said, it is important to be able to find all devices in the system.
Actually this was my orginal intent, I wanted to get all possible information
about all devices and display them to the user.
> - The "Device IDs", if they're unique enough,
> remove need for a "common/number" attribute.
Agreed.
> - Physical topology is a much better way to derive
> the device ids ... in fact, likely the only way that
> can work in general. Vendor/product IDs don't
> belong there, or even device type/class codes.
The reason for vendor/product ID and serial number is that you should not be
forced to reconfigure your system when you plug your device in another slot
or hub. I think this is a desirable goal.
> - For PCI, "device" isn't the right focus, it's the
> "function" -- devices can have many functions,
> not necessarily related. /proc/bus/pci/* has
> per-function files.
Yes, this is why there are sub-devices. Each function should be displayed as
a sub-device. I just haven't implemented this yet.
BTW: don't try the patch version 0.0.1 unless have CONFIG_SMP turned off and
compile USB support into the kernel, otherwise it will not work. I hope to
make the next release tomorrow...
bye...
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
next prev parent reply other threads:[~2001-04-01 23:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-01 17:47 [RFC/Patch] Device Registry David Brownell
2001-04-01 23:07 ` Tim Jansen [this message]
2001-04-07 10:56 ` Tim Jansen
-- strict thread matches above, loose matches on Subject: below --
2001-03-17 2:10 Tim Jansen
2001-03-17 2:18 ` David Lang
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=marc-linux-hotplug-98616728118704@msgid-missing \
--to=tim@tjansen.de \
--cc=linux-hotplug@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.