linux-kernel - Re: Linux 2.6.20-rc1

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]

Date:	Thu, 14 Dec 2006 15:05:52 -0500
From:	Jeff Garzik <jeff@...zik.org>
To:	Linus Torvalds <torvalds@...l.org>
CC:	Alistair John Strachan <s0348365@....ed.ac.uk>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jens Axboe <jens.axboe@...cle.com>
Subject: Re: Linux 2.6.20-rc1

Linus Torvalds wrote:
> 
> On Thu, 14 Dec 2006, Alistair John Strachan wrote:
>> `hddtemp' has stopped working on 2.6.20-rc1:
> 
> Hmm. Can you do the strace on a working kernel too? For example, is it 
> that the 0x30d ioctl (which is HDIO_GET_IDENTITY) used to work? If it's a 
> SATA device, and you _used_ to use the PATA drivers, some of the old 
> IDE-only ioctl's simply don't work when used in native SATA 
> configurations.
> 
> [ Side note: I consider that to be a mis-feature, but it's not a new 
>   regression, it's always been that way: different block subsystems have 
>   had their own "private" ioctl spaces.
> 
>   We've been moving more and more towards a unified space, and we could 
>   probably make scsi_ioctl.c emulate at least _some_ of the HDIO_xxx calls 
>   too, and try to support all the block ioctl's on all block devices 
>   rather than have some that work only on some certain class of hardware. 

FWIW, libata generally follows a "implement it, if enough people care 
about it" policy for the old HDIO_xxx ioctls.

There are plenty of HDIO_xxx ioctl should that have died back in the 
days when people using the 'hd' driver rather than the newfangled IDE 
driver.

So this change sorta filters out a lot of those older ioctls.

hddtemp is open source and reasonably well known, so I would certainly 
like to support it, if its reasonable.  For ATA disks, obtaining the 
temperature sometimes requires vendor-specific or firmware-specific 
knowledge.  hddtemp centralizes all that info in a database.

	Jeff


-
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/