lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0710171401170.10276@asgard.lang.hm>
Date:	Wed, 17 Oct 2007 14:04:33 -0700 (PDT)
From:	david@...g.hm
To:	Gabor Gombas <gombasg@...aki.hu>
cc:	Matthew Wilcox <matthew@....cx>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Stefan Richter <stefanr@...6.in-berlin.de>,
	Rob Landley <rob@...dley.net>,
	David Newall <david@...idnewall.com>,
	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org,
	Suparna Bhattacharya <suparna@...ibm.com>,
	Nick Piggin <piggin@...erone.com.au>
Subject: Re: What still uses the block layer?

On Wed, 17 Oct 2007, Gabor Gombas wrote:

> On Tue, Oct 16, 2007 at 01:55:07PM -0700, david@...g.hm wrote:
>
>> why is this any different from the external enclosures? they have always
>> appeared as the type of device that connects them to the motherboard, (and
>> even with SCSI, there are some controllers that don't generate sdX devices)
>
> In the past enclosures supported only one kind of connector so this
> assumption was fine. But nowadays an external disk may have several
> connectors (like USB, Firewire and eSata). Why should the disk's name
> depend on what type of cable did I manage to grab first? It is the
> _same_ disk regardless of the cable type.

the right type for the type of cable you choose to use. yes it's the same 
disk, but by choosing to hook it up in a different way you get different 
results from it (different performance, different predictability)

again, if you want to have a udev rule that then maps these different name 
onto the same name, more power to you, but why do you insist on makeing 
_everyone_ work that way (or go to significant extra effort to find the 
info in the changing directory structure of sysfs to track down the info 
that you throw away)

> There is one thing however that could be improved: renaming a disk in an
> udev rule should propagate the new name back to the kernel, just like
> renaming an ethernet interface does. That way mapping error messages to
> physical disk locations could be made much easier.

definantly.

David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ