about probing a device
Hi,
I found these routines in the kernel, does this means only one driver
can be matched to a device? What if two drivers both can drive the
device, like sd & sg in scsi subsystem?
static int device_attach(struct device * dev)
{
struct bus_type * bus = dev->bus;
struct list_head * entry;
int error;
if (dev->driver) {
device_bind_driver(dev);
return 1;
}
if (bus->match) {
list_for_each(entry, &bus->drivers.list) {
struct device_driver * drv = to_drv(entry);
error = bus_match(dev, drv);
if (!error)
/* success, driver matched */
return 1;
if (error != -ENODEV && error != -ENXIO)
/* driver matched but the probe failed */
printk(KERN_WARNING
"%s: probe of %s failed with error %d\n",
drv->name, dev->bus_id, error);
}
}
return 0;
}
void driver_attach(struct device_driver * drv)
{
struct bus_type * bus = drv->bus;
struct list_head * entry;
int error;
if (!bus->match)
return;
list_for_each(entry, &bus->devices.list) {
struct device * dev = container_of(entry, struct device,
bus_list);
if (!dev->driver) {
error = bus_match(dev, drv);
if (error && (error != -ENODEV))
/* driver matched but the probe failed */
printk(KERN_WARNING
"%s: probe of %s failed with error %d\n",
drv->name, dev->bus_id, error);
}
}
}
Thanks
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: about probing a device
Thanks very much. > The first one which matches and successfully attaches "wins". Seems that calling the bind routine can bind a driver to a device. Is there any bad side effect of doing such thing? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: about probing a device
thanks all.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
about mounting the sysfs
Hi,
I found the initialization code of the sysfs in version 2.6.22:
int __init sysfs_init(void)
{
int err = -ENOMEM;
sysfs_dir_cachep = kmem_cache_create("sysfs_dir_cache",
sizeof(struct sysfs_dirent),
0, 0, NULL, NULL);
if (!sysfs_dir_cachep)
goto out;
err = register_filesystem(&sysfs_fs_type);
if (!err) {
sysfs_mount = kern_mount(&sysfs_fs_type);
my questions are:
1. Is some initializing script responsible for mounting the sysfs? If
so, why do we call kern_mount.
2. I looked into the kern_mount code, the routine seems to get the
super block and the inode object for the sysfs, but when setting the
root, I got:
root = d_alloc_root(inode);
if (!root) {
pr_debug("%s: could not get root dentry!\n",__FUNCTION__);
iput(inode);
return -ENOMEM;
}
root->d_fsdata = &sysfs_root;
sb->s_root = root;
and the s_root is then passed to the mnt_root and the mnt_mountpoint:
int simple_set_mnt(struct vfsmount *mnt, struct super_block *sb)
{
mnt->mnt_sb = sb;
mnt->mnt_root = dget(sb->s_root);
return 0;
}
in vfs_kern_mount:
...
mnt->mnt_mountpoint = mnt->mnt_root;
mnt->mnt_parent = mnt;
up_write(&mnt->mnt_sb->s_umount);
...
So, does this means we get the mount point from d_alloc_root(inode),
but this doesn't look like the truth. d_alloc_root seems to allocate a
dentry for the root, is that true? If so, why for the root?
Does the s_root stand for the root of the file system, so it should
always be "/", but this is different from root file system? But what
about the mnt_moountpoint, how does the kernel store the path (rooted
from the root file system)?
Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
About mounting the sysfs
Hi all,
Currently, I'm studying the code of the sysfs. But I got the
following questions:
1. What is the d_alloc_root used for? Actually, the question should
be: why we have to call d_alloc_root. I think the root already has its
dentry, why we have to allocate another while we mounting a file
system?
2. Why we call d_alloc_root to allocate a dentry for the mount point
while the usual mount point of sysfs is defined by the user (something
like /sysfs but not /). See below:
root = d_alloc_root(inode);
if (!root) {
pr_debug("%s: could not get root dentry!\n",__FUNCTION__);
iput(inode);
return -ENOMEM;
}
root->d_fsdata = &sysfs_root;
sb->s_root = root;
does this means settting the sysfs' mount point to "/" but not "/sysfs".
Thanks.
--Zhanhua
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
