All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.