which devices will be displayed in hal-device-manager

WMWu at Winbond.com.tw WMWu at Winbond.com.tw
Wed Sep 7 18:38:25 PDT 2005


Thanks! But I still do not known how to resolve my problem.
I am writing a storage driver for the chip of our company for Fedora =
Core3. The chip can access the SD card, it is a ISA device. Our driver =
look our chip as a SCSI host controller ,just as the USB storage driver =
does. To support automount of the SD card, the device object must be =
displayed in hal-device-manager just as the USB storage.
I have written another storage driver for another chip of our company =
for Fedora Core3, the chip is almost as same as the above chip, but it =
is a PCI chip. The device can be displayed in the hal-device-manager =
just as the USB storage.
I do not known what I must do so the HAL can list the device in =
hal-device-manager.
Best regards
wmwu

-----Original Message-----
From: Kay Sievers [mailto:kay.sievers at vrfy.org]=20
Sent: 2005=C4=EA9=D4=C27=C8=D5 20:32
To: Dan Williams
Cc: PI14 WMWU; hal at lists.freedesktop.org
Subject: Re: which devices will be displayed in hal-device-manager

On Wed, Sep 07, 2005 at 07:21:32AM -0400, Dan Williams wrote:
> On Wed, 7 Sep 2005 WMWu at Winbond.com.tw wrote:
> > Which device will be displayed in hal-device-manager? My OS is =
Fedora
> > Core 3, version of hal-device-manager is 0.4.0
>=20
> hal-device-manager will display any device that HAL itself knows =
about.  Another=20
> way to see all the devices HAL knows about is the 'lshal' command, =
which is=20
> similar to the standard 'lspci' command.
>=20
> HAL finds devices (and information about those devices) in a number of =
ways:
>=20
> 1) Reading various entries in /proc, for example mountpoints and other =
things. =20
> Some device information is found here, but this is historical and most =

> everything for hardware devices should be in /sys already.

This is mostly additional information or a specific device state that is =
not
available in /sys. All devices are created by searching /sys.

> 2) Reading stuff in /sys.  This is _really_ important, and is highly=20
> device-driver dependent.  If a device driver doesn't expose its =
information via=20
> the sysfs filesystem in /sys, then the driver is considered broken and =
buggy=20
> anyway.  For example, network device drivers MUST use the =
SET_NETDEV_DEV() call=20
> to make the link from /sys/class/net/eth[x]/device to their device's =
entry in=20
> /sys/bus/pci or /sys/bus/pcmcia.  If you're writing a driver, make =
sure that it=20
> follows the correct rules for exposing its details via sysfs.  HAL =
will then be=20
> able to see all its details.  The Intel ipw2200 driver is a great =
example here.

Right, almost all directories in /sys/block/, /sys/class/ and =
/sys/devices
are kernel devices and also present in HAL as "device objects". HAL =
searches /sys at
startup for the initial list and listens to events from udev to keep =
this
list up-to-date.

> 3) .fdi files.  When HAL can't determine details about a particular =
device from=20
> the information in /proc, /sys, or other places, it looks at .fdi =
files and=20
> merges the properties listed in those files onto the device node in =
the HAL=20
> device list.  This allows for detection of certain digital cameras and =
other=20
> devices for which there is not enough identifying information.

These are informations that can be merged into already existing devices =
from user
supplied information. (The kernel may know that a device is a "hard =
disk", but
in reality it's a digital camara. A fdi file can mach on USB =
vendor/product id's
and provide that information to HAL.)

> 4) Reading information from the device (?)  I'm not sure if this is =
still done=20
> for things like file systems, but HAL used to try to read some =
information from=20
> various devices, like disks, to figure out what filesystem type they =
had, or=20
> whether they were encrypted, etc.

Yes, on device discovery, we open the device itself and probe for =
filesystem labels
or query serial numbers of hard drives...

> If you're wondering why a device doesn't show up in HAL, first make =
sure that it=20
> is listed in sysfs (/sys).  Each device will usually have at least two =
entries,=20
> for example /sys/class/net/eth0 (which is the capability of the =
device, and is=20
> driver-created) and /sys/devices/pci0000:00/0000:00:1e.0/0000:02:00.0 =
(which is=20
> from the Linux kernel PCI drivers).  The driver-created entries, ie=20
> /sys/class/net/eth0 needs to have a device link pointing to the second =
entry=20
> here, the PCI one.  That's created in the driver by SET_NETDEV_DEV() =
for=20
> example.  Other types of devices, like USB, IDE devices, etc, have =
similar=20
> mechanisms for populating their sysfs directories.

HAL depends on udev to provide the device node and the event for the
device. To be recognized by HAL, udev passes that information to the HAL
daemon. If the devices you are looking for is expected to have a device =
node,
make sure udev has handled the device properly too.

> In general, the earlier the kernel is in the 2.6 series, the worse the =
driver=20
> support for HAL is.  You should really only use HAL with 2.6.8 and =
later=20
> kernels, and each kernel release after 2.6.8 gets better driver =
support for=20
> sysfs, and therefore also for HAL.

Very true. HAL and modern hardware integration is very young on Linux
and we change a lot in that area from version to version. So older =
kernels, udev
and HAL versions may not always work as expected.

Kay

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DThe privileged confidential=
 information contained in this email is intended for use only by the addres=
sees as indicated by the original sender of this email. If you are not the =
addressee indicated in this email or are not responsible for delivery of th=
e email to such  a person, please kindly reply to the sender indicating thi=
s fact and delete all copies of it from your computer and network server im=
mediately. Your cooperation is highly appreciated. It is advised that any u=
nauthorized use of confidential information of Winbond is strictly prohibit=
ed; and any information in this email irrelevant to the official business o=
f Winbond shall be deemed as neither given nor endorsed by Winbond.=0D
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DIf your computer is unable =
to decode Chinese font, please ignore the following message.It essentially =
repeats the statement in English given above.=A5=BB=ABH=A5=F3=A4=BA=A9=D2=
=A7t=B5=D8=A8=B9=B9q=A4l=AA=BA=B0]=B2=A3=A9=CA=BE=F7=B1K=A9=CA=B8=EA=B0T, =
=B6=C8=B1=C2=C5v=AD=EC=B5o=ABH=A4H=AB=FC=A9w=A4=A7=A6=AC=ABH=A4H=A8=FA=BE\\=
=A4=A7=A5=CE. =B0=B2=A8=CF=B1z=A8=C3=ABD=B3Q=AB=FC=A9w=A4=A7=A6=AC=ABH=A4H=
=A9=CE=A6]=A5=F4=A6=F3=AD=EC=A6]=A6b=A5=BC=B8g=B1=C2=C5v=AA=BA=B1=A1=A7=CE=
=A4=A7=A4U=A6=AC=A8=EC=A5=BB=ABH=A5=F3, =BD=D0=B1z=A7i=AA=BE=AD=EC=B5o=ABH=
=A4H=A8=C3=A5=DF=A7Y=B1N=ABH=A5=F3=B1q=B9q=B8=A3=BBP=BA=F4=B8=F4=A6=F8=AAA=
=BE=B9=A4=A4=A4=A9=A5H=AE=F8=B0=A3. =B9=EF=A9=F3=B1z=AA=BA=A6X=A7@, =A7=DA=
=AD=CC=A5=FD=A6=B9=ADP=C1=C2. =AFS=A6=B9=B4=A3=BF=F4, =A5=F4=A6=F3=A5=BC=B8=
g=B1=C2=C5v=BE=D5=A6=DB=A8=CF=A5=CE=B5=D8=A8=B9=B9q=A4l=AA=BA=BE=F7=B1K=B8=
=EA=B0T=AA=BA=A6=E6=AC=B0=ACO=B3Q=C4Y=AE=E6=B8T=A4=EE=AA=BA. =ABH=A5=F3=BBP=
=B5=D8=A8=B9=B9q=A4l=C0=E7=B7~=B5L=C3=F6=A4=A7=A4=BA=AEe,=A4=A3=B1o=B5=F8=
=AC=B0=B5=D8=A8=B9=B9q=A4l=A4=A7=A5=DF=B3=F5=A9=CE=B7N=A8=A3.=0D


More information about the hal mailing list