On 02/03/2014 10:58 PM, Jeremy Linton wrote:
On 2/3/2014 2:51 PM, Kay Sievers wrote:
This is not simple and not going to happen. Sibling devices in /sys cannot
have a relationship in udev, there are only parent/child dependencies.
Ok.. so if we can't ignore all the spare device nodes
Hannes == Hannes Reinecke h...@suse.de writes:
Hannes Moving EVPD page 0x83 (and maybe 0x80, too) into sysfs will save
Hannes quite a lot of headache we have currently; udev won't have to
Hannes call 'sg_inq', information will be present even though the
Hannes device itself might be temporarily
On 02/06/2014 02:21 PM, Martin K. Petersen wrote:
Hannes == Hannes Reinecke h...@suse.de writes:
Hannes Moving EVPD page 0x83 (and maybe 0x80, too) into sysfs will save
Hannes quite a lot of headache we have currently; udev won't have to
Hannes call 'sg_inq', information will be present even
Hannes == Hannes Reinecke h...@suse.de writes:
My patch provides both the original VPD 0x83 and 0x80 bits as well as
a handle identical to /sbin/scsi_id.
Hannes Bah, don't do that. That should better be handled by udev
Hannes rules. I've got a set of patches moving from scsi_id to sg_inq,
On Thu, 2014-02-06 at 08:50 -0500, Martin K. Petersen wrote:
Hannes == Hannes Reinecke h...@suse.de writes:
My patch provides both the original VPD 0x83 and 0x80 bits as well as
a handle identical to /sbin/scsi_id.
Hannes Bah, don't do that. That should better be handled by udev
On 02/06/2014 03:38 PM, James Bottomley wrote:
On Thu, 2014-02-06 at 08:50 -0500, Martin K. Petersen wrote:
Hannes == Hannes Reinecke h...@suse.de writes:
My patch provides both the original VPD 0x83 and 0x80 bits as well as
a handle identical to /sbin/scsi_id.
Hannes Bah, don't do that.
On 14-02-06 10:13 AM, Hannes Reinecke wrote:
On 02/06/2014 03:38 PM, James Bottomley wrote:
On Thu, 2014-02-06 at 08:50 -0500, Martin K. Petersen wrote:
Hannes == Hannes Reinecke h...@suse.de writes:
My patch provides both the original VPD 0x83 and 0x80 bits as well as
a handle identical to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/2/2014 5:42 AM, Hannes Reinecke wrote:
This is due to the strictly sequential design udev has. Essentially udev
spawns a worker for every device which gets created (= udev receives a
uevent for).
The part I fail to see in this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/03/2014 03:50 PM, Jeremy Linton wrote:
On 2/2/2014 5:42 AM, Hannes Reinecke wrote:
This is due to the strictly sequential design udev has.
Essentially udev spawns a worker for every device which gets
created (= udev receives a uevent for).
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/3/2014 9:06 AM, Hannes Reinecke wrote:
That's due to udev. Udev is getting events for each device it should create
a device node for. So for 'st' it'll get a series of events for 'stX', and
another series of events for 'nstX'. Udev will treat
On Mon, Feb 3, 2014 at 4:08 PM, Jeremy Linton jlin...@tributary.com wrote:
On 2/3/2014 9:06 AM, Hannes Reinecke wrote:
That's due to udev. Udev is getting events for each device it should create
a device node for. So for 'st' it'll get a series of events for 'stX', and
another series of
On Mon, 2014-02-03 at 21:51 +0100, Kay Sievers wrote:
On Mon, Feb 3, 2014 at 4:08 PM, Jeremy Linton jlin...@tributary.com wrote:
On 2/3/2014 9:06 AM, Hannes Reinecke wrote:
That's due to udev. Udev is getting events for each device it should create
a device node for. So for 'st' it'll get
On 14-02-03 10:08 AM, Jeremy Linton wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/3/2014 9:06 AM, Hannes Reinecke wrote:
That's due to udev. Udev is getting events for each device it should create
a device node for. So for 'st' it'll get a series of events for 'stX', and
another
On Mon, Feb 3, 2014 at 10:16 PM, Douglas Gilbert dgilb...@interlog.com wrote:
On 14-02-03 10:08 AM, Jeremy Linton wrote:
So whats wrong with the simple solution? You throw the ones for st
away, and
create the st handles from the nst worker.
Doesn't seem to be any good solutions to
On 2/3/2014 2:51 PM, Kay Sievers wrote:
This is not simple and not going to happen. Sibling devices in /sys cannot
have a relationship in udev, there are only parent/child dependencies.
Ok.. so if we can't ignore all the spare device nodes in a given /sys
entry
for a given device. Why
On Mon, Feb 3, 2014 at 10:58 PM, Jeremy Linton jlin...@tributary.com wrote:
On 2/3/2014 2:51 PM, Kay Sievers wrote:
This is not simple and not going to happen. Sibling devices in /sys cannot
have a relationship in udev, there are only parent/child dependencies.
Ok.. so if we can't
On 2.2.2014, at 13.42, Hannes Reinecke h...@suse.de wrote:
[part of explanation snipped from reply]
But we're now trying to deprecate the original (and unmaintained)
scsi_id program and replace it with the standard 'sg_inq' program.
Which is a standard program which just issues the
On 02/02/2014 08:15 PM, Kai Mäkisara (Kolumbus) wrote:
On 2.2.2014, at 13.42, Hannes Reinecke h...@suse.de wrote:
[part of explanation snipped from reply]
But we're now trying to deprecate the original (and unmaintained)
scsi_id program and replace it with the standard 'sg_inq' program.
On 01/31/2014 05:43 PM, Jeremy Linton wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/31/2014 2:46 AM, Hannes Reinecke wrote:
This patch make the tape always non-rewinding when SG_IO is used, thus
allowing udev to get a proper device id for tapes.
Maybe instead of silently
On 1.2.2014, at 16.06, Hannes Reinecke h...@suse.de wrote:
On 01/31/2014 05:43 PM, Jeremy Linton wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/31/2014 2:46 AM, Hannes Reinecke wrote:
This patch make the tape always non-rewinding when SG_IO is used, thus
allowing udev to get
Plain 'st' devices are defined to do a rewind on close.
This causes quite some issues when trying to read the
VPD pages to figure out the WWN of the device.
Especially for udev this means we either have to use
another (non-rewinding) device node for this
(and thereby introducing race conditions)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/31/2014 2:46 AM, Hannes Reinecke wrote:
This patch make the tape always non-rewinding when SG_IO is used, thus
allowing udev to get a proper device id for tapes.
This is wholly bad. Just because someone fires a SG ioctl at the device
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/31/2014 2:46 AM, Hannes Reinecke wrote:
This patch make the tape always non-rewinding when SG_IO is used, thus
allowing udev to get a proper device id for tapes.
Maybe instead of silently changing the behavior, if you just _HAVE_ to
23 matches
Mail list logo
