From: David Zeuthen <david@fubar.dk>
To: linux-hotplug@vger.kernel.org
Subject: Re: Hardware Abstraction Layer
Date: Mon, 29 Sep 2003 20:50:31 +0000 [thread overview]
Message-ID: <marc-linux-hotplug-106486878005439@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-106345989228476@msgid-missing>
On Wed, 2003-09-24 at 23:08, Greg KH wrote:
> > > > 3. Provide some place where user-made settings are stored and persisted
> > > > for a device. For instance UI-things like device name, where to
> > > > mount a storage device and with what options (storage only readable
> > > > by the user or not etc.).
> > >
> > > Some of that will be taken care of in udev for Linux. But others (like
> > > where to mount the device) would be up to you.
> > >
> >
> > Yes. I did install 2.6.0-test5 over the weekend and played around with
> > udev 0.2, /sys and libsysfs + tools. It seems udev can't handle USB
> > storage devices yet? It didn't worked for me at least.
>
> Should work just fine. They show up as block devices, just like any
> other disk (look in /sys/block). My demo at OLS 2003 used my usb camera
> which is a usb storage device.
>
My bad. I hadn't loaded the kernel module sd_mod. Works like a charm
with this module..
> > Side question: Is it really true that the only way to obtain where the
> > SCSI subsystem mounts the usb-storage is by inspecting /var/log/messages
> > on 2.4? I couldn't find anything on 2.5/2.6 through googling either...
> > It's very frustrating
>
> Don't remember, sorry. There are a bunch of different scsi programs for
> doing this. Search the linux-scsi archives for links to them.
>
Hmm yes.. I searched for a long time, but found this message
http://www.dragoninc.on.ca/mail-archives/linux-usb/2002-06/0122.html
where you say this is not possible in 2.4.
> > More on udev: how will it fit with the linux-hotplug project?
>
> It uses the hotplug-base package, that's all.
>
Ah, I see.. You symlink udev to /etc/hotplug.d/default/udev.hotplug and
on hotplug ACTIONd, $1=block invocations query the sys/$DEVPATH/dev
file and do a mknod.
I can see that it's a clever thing to have a (pluggable) naming database
and strategy, especially for those sites you mention with thousands of
disks.
Do you intend udev to send a hotplug message to notify that a new device
file have been created? Or is it only for kernel messages? The thinking
is that one could make a generic script that broadcast each and every
hotplug event. It could be as simple as
dbus-send --dest=org.freedesktop.DBus.Broadcast org.kernel.Hotplug
string:$1 string:"`env`"
to broadcast the hotplug event on the dbus system bus. Of course, in a
proper script one would test for /usr/bin/dbus-send and
/var/run/messagebus.pid.
This way, I wouldn't need my hal_hotplug program, but just listen for
org.kernel.Hotplug messages on the dbus system bus and still enjoy the
functionality of udev.
> > Maybe it's already there, but it could be nice to have a set of
> > prioritized hotplug scripts that is invoked a'la /etc/init.d.. So one
> > for loading a kernel module, udev for naming the device and one for
> > sending a D-BUS message, notifying, among others, the HAL. In the chain
> > of invoking these, the environment would grow.
>
> Heh, we already have that. See the latest release of the linux-hotplug
> package :)
>
OK. One thing though.. When I plug in my USB storage device I get a
number hotplug invocations on 2.6 (instead of only one on 2.4):
o usb, DEVPATH=/devices/pci0000:00/0000:00:10.0/0000:02:07.0/usb2/
2-1/2-1.3
o usb, DEVPATH=/devices/pci0000:00/0000:00:10.0/0000:02:07.0/
usb2/2-1/2-1.3/2-1.3:0
o scsi_host, DEVPATH=/class/scsi_host/host2
o scsi, DEVPATH=/devices/pci0000:00/0000:00:10.0/0000:02:07.0/
usb2/2-1/2-1.3/2-1.3:0/host2/2:0:0:0
o block, DEVPATH=/block/sda
o block, DEVPATH=/block/sda/sda1
o scsi_device, DEVPATH=/class/scsi_device/2:0:0:0
These are all handled by stuff loading modules and creating device files
(udev) which is all good. But when do I know when all messages for a
device is sent?
My understanding is that is doesn't make send to talk about hotplug
start and hotplug end messages (though it would be nice), so I guess
when receiving the second usb hotplug message I wait for a sec or two to
received the first block message (since $DEVPATH/device points to the
USB device). Or even better, a message from udev! (otherwise I would
have to create my own device file with mknod?)
Thanks,
David
-------------------------------------------------------
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-29 20:50 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
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 [this message]
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-106486878005439@msgid-missing \
--to=david@fubar.dk \
--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).