From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin Schlemmer Date: Wed, 24 Dec 2003 22:25:22 +0000 Subject: Possible udev bug and some questions MIME-Version: 1 Content-Type: multipart/mixed; boundary="=-gcYkon5qlEgwC59I7mex" Message-Id: List-Id: To: linux-hotplug@vger.kernel.org --=-gcYkon5qlEgwC59I7mex Content-Type: multipart/mixed; boundary="=-sP96xg+tFdTlvGN9cxQ0" --=-sP96xg+tFdTlvGN9cxQ0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi I know its not good form to post so many issues in one, but I am currently on dialup, and not for more than a few hours. Also please CC me, as I am not on this list. 1) if you look at the following code in namedev.c (in function do_callout()): -- if (sysfs_device) { dbg("dev->bus=3D'%s' sysfs_device->bus=3D'%s'", dev->bus, sysfs_device->bus); if (strcasecmp(dev->bus, sysfs_device->bus) !=3D 0) continue; } -- there is a slight problem - if sysfs_device =3D NULL, then the 'strcasecmp(dev->bus, sysfs_device->bus) !=3D 0' test will never be evaluated, and result in the callout to run for all non-phisical (?) devices. Attached is a possible patch, and this also brings me to second question: 2) If I understand the udev manual correct, all 'methods' should have a suitable 'key'. If I now look again at namedev.c, then whenever we work with a non-phisical (?) (or not attached to a phisical bus?) device, then non of the 'keys' used with 'methods' are available, as get_sysfs_device() fails. Should any of the 'methods' then be run? Or more to the code, should any of the do_* (do_callout, etc) functions then be called for a device for which get_sysfs_device() failed? Reference code for above (function namedev_name_device()): -- /* find the sysfs_device associated with this class device */ sysfs_device =3D get_sysfs_device(class_dev); if (sysfs_device) { dbg("sysfs_device->path=3D'%s'", sysfs_device->path); dbg("sysfs_device->bus_id=3D'%s'", sysfs_device->bus_id); dbg("sysfs_device->bus=3D'%s'", sysfs_device->bus); strfieldcpy(udev->bus_id, sysfs_device->bus_id); wait_for_device_to_initialize(sysfs_device); } else { dbg("class_dev->name =3D '%s'", class_dev->name); } -- 3) After looking at ide-devfs.sh, I converted it to create the 'compat' symlinks (/dev/{cdroms,discs}/* stuff) if anybody is interested (as ide-devfs-compat.sh). Also, it would be nice if somebody could have a look for holes - I am not sure what will happen with modular ide setups ... I would however like to extend it to scsi disks, but not sure what is the most generic and easy way to try and figure out how many disks there is ... any ideas? This sorda brings me to point four: 4) Is there any reason why only one 'method' (meaning only one of the callouts I may have for ide devices - I may want to use both the ide-devfs.sh and ide-devfs-compat.sh to have multiple symlinks for on device ...) is done for each device and/or hotplug event (beside lack of time to implement) ? Same for why only 'type' of 'method' is done for each (if a CALLOUT is done, the rest is skipped) ? If no other reason that time, is anybody working on it, and if not, any pointers to not clash with future plans (meaning I might want to take a shot at implementing it)? 5) I use a devfs-less setup with udev, 2.6.0 kernel with most of the sysfs patches from Greg, if not all, and a pre 2.3.3 glibc. Also have devpts compiled in, and mounted to /dev/pts. I now have the following 'w' output: -- $ w 00:22:22 up 1:15, 13 users, load average: 0.98, 0.28, 0.14 USER TTY LOGIN@ IDLE JCPU PCPU WHAT azarah tty4 23:07 1:14m 1.19s 0.00s /bin/sh /usr/X11R6/bin/startx azarah ttyp0 23:08 ? 0.00s 0.00s -bash azarah ttyp1 23:08 ? 0.00s 0.00s -bash ... -- where I would rather expect something like this (devfs box): -- $ w 00:35:38 up 32 days, 8:01, 1 user, load average: 0.19, 0.26, 0.20 USER TTY LOGIN@ IDLE JCPU PCPU WHAT azarah pts/0 00:35 1.00s 0.04s 0.02s w -- Just me, or somebody else have this as well? I know this could be a few things (glibc, etc), but I want to try and get a 'starting point' for debugging (if it should list 'pts/*' as TTY in the first place ...). Thanks, --=20 Martin Schlemmer --=-sP96xg+tFdTlvGN9cxQ0 Content-Disposition: attachment; filename=udev-010-valid-bus-for-CALLOUT.patch Content-Type: text/x-patch; name=udev-010-valid-bus-for-CALLOUT.patch; charset=ISO-8859-1 Content-Transfer-Encoding: base64 LS0tIHVkZXYtMDEwL25hbWVkZXYuYy5vcmlnCTIwMDMtMTItMjQgMTc6MTk6NTIuOTkyNzM0NzIw ICswMjAwDQorKysgdWRldi0wMTAvbmFtZWRldi5jCTIwMDMtMTItMjQgMTc6NDE6NTcuNDY5Mzgz NjY0ICswMjAwDQpAQCAtNDAyLDYgKzQwMiw5IEBADQogCQkJZGJnKCJkZXYtPmJ1cz0nJXMnIHN5 c2ZzX2RldmljZS0+YnVzPSclcyciLCBkZXYtPmJ1cywgc3lzZnNfZGV2aWNlLT5idXMpOw0KIAkJ CWlmIChzdHJjYXNlY21wKGRldi0+YnVzLCBzeXNmc19kZXZpY2UtPmJ1cykgIT0gMCkNCiAJCQkJ Y29udGludWU7DQorCQkvKiBmb3IgdGhpcyBDQUxMT1VUIHdlIG5lZWQgYSB2YWxpZCBzeXNmc19k ZXZpY2UgKi8NCisJCX0gZWxzZSBpZiAoKGRldi0+YnVzICE9IE5VTEwpIHx8IChzdHJsZW4oZGV2 LT5idXMpICE9IDApKSB7DQorCQkJY29udGludWU7DQogCQl9DQogDQogCQkvKiBzdWJzdGl0dXRl IGFueXRoaW5nIHRoYXQgbmVlZHMgdG8gYmUgaW4gdGhlIHByb2dyYW0gbmFtZSAqLw0K --=-sP96xg+tFdTlvGN9cxQ0 Content-Disposition: attachment; filename=ide-devfs-compat.sh Content-Type: text/x-sh; name=ide-devfs-compat.sh; charset=ISO-8859-1 Content-Transfer-Encoding: base64 IyEvYmluL3NoDQoNCiMgdWRldiBDQUxMT1VUIHNjcmlwdA0KIyByZXR1cm4gY29tcGF0IGRldmZz LW5hbWVzIGZvciBpZGUtZGV2aWNlcw0KIyBDQUxMT1VULCBCVVM9ImlkZSIsIFBST0dSQU09Ii9l dGMvdWRldi9pZGUtZGV2ZnMtY29tcGF0LnNoICVrICViICVuIiwgSUQ9ImhkKiIsIE5BTUU9IiUx YyIsIFNZTUxJTks9IiUyYyINCg0KSE9TVD0kezIlXC5bMC05XX0NClRBUkdFVD0kezIjWzAtOV1c Ln0NCg0KaWYgWyAteiAke0hPU1QjWzEzNTc5XX0gXTsgdGhlbg0KCUhPU1Q9YGV4cHIgJEhPU1Qg LSAxYA0KCUJVUz0iMSINCmVsc2UNCglCVVM9IjAiDQpmaQ0KDQpnZXRfZGV2X251bWJlcigpIHsN Cglsb2NhbCB4PQ0KCWxvY2FsIG51bT0wDQoJbG9jYWwgTUVESUE9DQoJDQoJZm9yIHggaW4gL3By b2MvaWRlLyovbWVkaWE7IGRvDQoJCWlmIFsgLWUgIiR4IiBdOyB0aGVuDQoJCQlNRURJQT1gY2F0 ICR4YA0KCQkJaWYgWyAiJE1FRElBIiA9ICIkMiIgXTsgdGhlbg0KCQkJCW51bT1gZXhwciAkbnVt ICsgMWANCgkJCWZpDQoJCQlpZiBbICIkeCIgPSAiL3Byb2MvaWRlLyQxL21lZGlhIiBdOyB0aGVu DQoJCQkJYnJlYWsNCgkJCWZpDQoJCWZpDQoJZG9uZQ0KCQ0KCWVjaG8gYGV4cHIgJG51bSAtIDFg DQp9DQoNCmlmIFsgLXogIiQzIiBdOyB0aGVuDQoJTUVESUE9YGNhdCAvcHJvYy9pZGUvJDEvbWVk aWFgDQoJaWYgWyAiJE1FRElBIiA9ICJjZHJvbSIgXTsgdGhlbg0KCQllY2hvICQxIGNkcm9tcy9j ZHJvbWBnZXRfZGV2X251bWJlciAkMSBjZHJvbWANCgllbGlmIFsgIiRNRURJQSIgPSAiZGlzayIg XTsgdGhlbg0KCQllY2hvICQxIGRpc2NzL2Rpc2NgZ2V0X2Rldl9udW1iZXIgJDEgZGlza2AvZGlz Yw0KCWZpDQplbHNlDQoJZWNobyAkMSBkaXNjcy9kaXNjYGdldF9kZXZfbnVtYmVyICQxIGRpc2tg L3BhcnQkMw0KZmkNCg0K --=-sP96xg+tFdTlvGN9cxQ0-- --=-gcYkon5qlEgwC59I7mex Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQA/6hJSqburzKaJYLYRAg3JAJ9RiR7J2la7axiiKYvWjc9LEiDfVwCdG8e+ ZuzPIaykLgCC3DUFP/YaE6A= =wk2e -----END PGP SIGNATURE----- --=-gcYkon5qlEgwC59I7mex-- ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ 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