From: Greg KH <greg@kroah.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: Hardware Abstraction Layer
Date: Thu, 18 Sep 2003 00:29:05 +0000 [thread overview]
Message-ID: <marc-linux-hotplug-106384501630178@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-106345989228476@msgid-missing>
On Wed, Sep 17, 2003 at 02:40:12AM +0200, David Zeuthen wrote:
> On Tue, 2003-09-16 at 18:39, Greg KH wrote:
> > On Sat, Sep 13, 2003 at 03:30:38PM +0200, David Zeuthen wrote:
> > > Hi,
> > >
> > > I'm currently working on a hardware abstraction layer, see
> > >
> > > http://pdx.freedesktop.org/~hal/
> > >
> > > for use in desktop environments such as GNOME or KDE. The HAL project
> > > is in it's early stages - there is a draft spec planned and I got an
> > > implementation running as well.
> >
> > How does this differ from D-BUS? Hm, in looking at your page, it says
> > you are using D-BUS messages.
>
> I use D-BUS as the IPC mechanism between hotplug agents and applications
> wanting to query a device database. In the middle there is a daemon.
>
> In a sense I want the entire HAL not to care about specific hardware
> issues at all, but build on existing software like linux-hotplug ;-)
> (see my recent post to the xdg-list for detail)
Hm, in looking over your post I think you are going to be duplicating a
lot of existing information that is dynamically available to you from
the kernel.
For example, the kernel already knows what USB devices are supported by
what drivers. It exports that info to userspace in the modules.*map
files in /lib/modules/<KERNEL_VERSION>/
The existing hotplug scripts already handle the mapping from device to
driver, so you don't need to duplicate that functionaity.
> > Oh, have you looked at udev too? It will
> > handle naming the devices for you in /dev.
> >
>
> Excellent - will look into this later. Will this help me, e.g., getting
> the information that my CF card reader is at /dev/sda1 when using the
> kernel module usb-storage? Or have I misunderstood?
Yes it will. See my OLS paper from this year for lots more information
about it.
> > Also, D-BUS messages will be
> > created for all /sbin/hotplug events too. You might want to work with
> > that if it's easier for you.
> >
>
> I'll be interested in this, definately. Are you using the service
> org.freedesktop.DBus.Broadcast for this?
I'm not using anything :)
There was a simple command line program that generated dbus messages.
Someone needs to take that and have it convert hotplug messages into
dbus messages. I think it's going to use the org.kernel namespace.
> I'll also need a unique ID of each device being hotplugged, and I have
> some problems seeing this is even possible on some busses like USB. The
> unique ID must be the same over plugs/unplugs.
What "unique ID"? In short, you are never guaranteed such a thing, but
you can get close. See my udev paper for more info on this.
> Say, that I plug two identical cameras into the system with no
> device-instance specific information. Corner case, but nasty one...
Use the bus topology to distinguish between those two devices.
> In the event this is not possible the hotplug agent must somehow convey
> this information so I can append a counter to make the ID unique in that
> way..
The kernel will tell you that this is a new device. It's up to
userspace to do something with that info. udev will determine the /dev
name for the device. It's up to other programs to do other things with
this info (which is what I'm thinking your proposal does, correct?)
thanks,
greg k-h
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
next prev parent reply other threads:[~2003-09-18 0:29 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-13 13:30 Hardware Abstraction Layer David Zeuthen
2003-09-14 22:34 ` Joerg Sommer
2003-09-16 16:39 ` Greg KH
2003-09-17 0:40 ` David Zeuthen
2003-09-18 0:29 ` Greg KH [this message]
2003-09-18 11:24 ` David Zeuthen
2003-09-18 17:36 ` Greg KH
2003-09-18 18:30 ` Havoc Pennington
2003-09-18 20:35 ` David Zeuthen
2003-09-19 20:11 ` Joerg Sommer
2003-09-19 23:12 ` Greg KH
2003-09-20 0:12 ` Greg KH
2003-09-20 0:17 ` Greg KH
2003-09-20 19:31 ` Joerg Sommer
2003-09-21 6:42 ` Greg KH
2003-09-21 20:56 ` David Zeuthen
2003-09-24 21:08 ` Greg KH
2003-09-29 20:50 ` David Zeuthen
2003-10-01 1:30 ` Havoc Pennington
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-106384501630178@msgid-missing \
--to=greg@kroah.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).